Aller au contenu principal

Migration Symfony · 5.4 → 6.4 → 7.4 → 8.1

Migrer de Symfony 5 à Symfony 8

Symfony 5.4 reste couvert par les correctifs de sécurité jusqu’en février 2029 ; Symfony 8.1 reste couvert par les correctifs de sécurité jusqu’en janvier 2027. Le chemin sûr traverse 3 versions majeures en s’arrêtant sur chaque LTS : 5.4 → 6.4 → 7.4 → 8.1. PHP passe de 7.2.5 minimum à 8.4 minimum. Première rupture à traiter : iS_AUTHENTICATED_ANONYMOUSLY et IS_ANONYMOUS sont dépréciés : utiliser PUBLIC_ACCESS dans access_control.

Où en est le support de Symfony 5.4 et 8.1 ?

Support de Symfony 5.4 et 8.1
CritèreSymfony 5.4Symfony 8.1
Sortienovembre 2021mai 2026
Fin des correctifs de bugsnovembre 2024janvier 2027
Fin des correctifs de sécuritéfévrier 2029janvier 2027
PHP minimum7.2.58.4

Statuts vérifiés le 08/11/2026 sur les pages officielles de version.

Les ruptures à traiter en premier

  1. Bloquant · 5.4IS_AUTHENTICATED_ANONYMOUSLY et IS_ANONYMOUS sont dépréciés : utiliser PUBLIC_ACCESS dans access_control.source
  2. Bloquant · 5.4isAnonymous() et is_anonymous() sont dépréciés, l'état anonyme disparaît en 6.0 : utiliser isAuthenticated() ou isFullFledged().source
  3. Bloquant · 7.0L'intégration de doctrine/annotations est supprimée : routes, validation et serializer n'acceptent plus que les attributs PHP natifs.source

Le chemin de migration, étape par étape

Chaque étape se termine sur une version sans dépréciation avant la majeure suivante : c’est la seule montée que la promesse de rétrocompatibilité de Symfony couvre. Avant de lancer le chantier, mesurer la dette avec un Bear Scan chiffre la dette qui ralentira chaque étape.

Côté outillage, Rector 2 ne s’appuie plus sur un set par version : withComposerBased(symfony: true) applique les règles de la version de Symfony installée, et withAttributesSets(symfony: true) convertit les annotations en attributs. On relance Rector après chaque montée de composer.json (configuration testée sur un passage vers Symfony 8).

Avant de quitter Symfony 5.4

PHP minimum : 7.2.5

  • BloquantIS_AUTHENTICATED_ANONYMOUSLY et IS_ANONYMOUS sont dépréciés : utiliser PUBLIC_ACCESS dans access_control.source
  • BloquantisAnonymous() et is_anonymous() sont dépréciés, l'état anonyme disparaît en 6.0 : utiliser isAuthenticated() ou isFullFledged().source
  • À traiterSecurityFactoryInterface est déprécié au profit de AuthenticatorFactoryInterface pour les factories de pare-feu personnalisées.source
  • À traiterAuthenticatorInterface::createAuthenticatedToken() est déprécié au profit de createToken().source
  • À traiterAuthenticationEvents::AUTHENTICATION_FAILURE est déprécié : écouter LoginFailureEvent.source
  • À traiterLes tokens ne doivent plus contenir de credentials : Token::getCredentials() est déprécié.source

Pièges rencontrés en migration

  • AbstractController::get(), has(), getDoctrine() et dispatchMessage() sont dépréciés : passer à l'injection de méthode ou de constructeur avant la 6.0.source
  • Dernier palier LTS avant 6.0 (qui partage les mêmes nouveautés que la 5.4) : support de sécurité jusqu'en février 2029, mais plus de correctifs de bugs depuis novembre 2024.source

Symfony 6 (6.0, 6.1, 6.2, 6.3 et 6.4)

PHP minimum : 8.1

  • Bloquant · 6.0Le composant Guard est supprimé : les authenticators doivent passer au système d'authentification (Passport, createToken() à la place de createAuthenticatedToken()).source
  • Bloquant · 6.0UserInterface perd getPassword() et getSalt() : il faut implémenter PasswordAuthenticatedUserInterface (et la variante Legacy pour un sel utilisateur).source
  • Bloquant · 6.0Les rôles IS_AUTHENTICATED_ANONYMOUSLY et IS_ANONYMOUS disparaissent : les règles access_control doivent utiliser PUBLIC_ACCESS.source
  • Bloquant · 6.0AbstractController n'expose plus get(), has(), getDoctrine() ni dispatchMessage() : l'injection par constructeur ou par méthode devient obligatoire.source
  • Bloquant · 6.2La classe et le service Symfony\Component\Security\Core\Security sont dépréciés : utiliser Symfony\Bundle\SecurityBundle\Security.source
  • Bloquant · 6.4L'intégration de doctrine/annotations est dépréciée : migrer routes, validation et serializer vers les attributs natifs, avant la suppression en 7.0.source

Pièges rencontrés en migration

  • PHP 8.0.2 minimum : la migration depuis 5.4 impose de monter PHP avant tout ; corriger d'abord toutes les dépréciations 5.4, car la 6.0 supprime ce que la 5.4 déprécie.source
  • Request::getMasterRequest() et MASTER_REQUEST sont renommés en getMainRequest() et MAIN_REQUEST : un simple rechercher-remplacer évite des erreurs fatales dans les listeners.source
  • Les propriétés publiques et protégées sont désormais considérées finales : surcharger une propriété d'une classe Symfony casse ; affecter sa valeur dans le constructeur.source

Symfony 7 (7.0, 7.1, 7.2, 7.3 et 7.4)

PHP minimum : 8.2

  • Bloquant · 7.0L'intégration de doctrine/annotations est supprimée : routes, validation et serializer n'acceptent plus que les attributs PHP natifs.source
  • Bloquant · 7.0Les options framework.validation.enable_annotations et serializer.enable_annotations disparaissent, remplacées par enable_attributes.source

Étape intermédiaire, détaillée sur sa propre page : migration Symfony 6 → 7

À lire sur le blog : De Symfony 7.4 LTS à la branche 8.x : éliminer les dépréciations proprement · Symfony 7.4 LTS : ce qu'il faut savoir avant de migrer

Symfony 8 (8.0 et 8.1)

PHP minimum : 8.4

  • Bloquant · 8.0Le format XML est abandonné : ExtensionInterface::getXsdValidationBasePath() et getNamespace() disparaissent, tout XML doit passer en YAML, PHP ou attributs.source
  • Bloquant · 8.0Le format PHP fluide de configuration sémantique est supprimé : instancier le builder avec le tableau de config et le retourner.source
  • Bloquant · 8.0Request::get() est supprimé : lire attributes, query ou request directement ; setFormat() n'accepte plus null.source
  • Bloquant · 8.0UserInterface::eraseCredentials() et TokenInterface::eraseCredentials() sont supprimés : effacer les secrets via __serialize().source
  • Bloquant · 8.1Les attributs de contrôleur (#[IsGranted], #[IsCsrfTokenValid], #[Cache]) sont traités à la priorité -10000 sur kernel.controller_arguments au lieu de 30-10.source
  • À traiter · 8.0L'option hide_user_not_found est supprimée : seul expose_security_errors (enum ExposeSecurityLevel) est accepté.source

Pièges rencontrés en migration

  • PHP 8.4 minimum : le saut PHP 8.2 vers 8.4 (voire 8.3) est le principal bloqueur ; mettre à jour image Docker, extensions et CI avant Symfony.source
  • Le XML n'étant plus pris en charge, chaque bundle tiers doit publier une version compatible 8.0 : vérifier les dépendances avant la montée.source
  • Version non-LTS arrêtée (fin 2026-07 selon symfony.com) : cible de passage vers la 8.1 ou rester sur 7.4 LTS.source

À lire sur le blog : De Symfony 7.4 LTS à la branche 8.x : éliminer les dépréciations proprement · Claude Craft #4 : Symfony 8.1, 126 commandes et 3 agents dédiés

Ce que Symfony 8.1 vous apporte

  • 8.0 : 8.0 offre les mêmes fonctionnalités que la 7.4 sans aucun code déprécié : base de code plus légère et plus stricte.source
  • 8.1 : Applications Symfony sans HTTP : conteneur d'injection complet sans dépendre de HttpKernel, utile pour workers et outils CLI.source

Combien coûte cette migration ?

  • Petite application

    100 fichiers PHP, 15 entités, 2 bundles maison

    7 320 € HT

  • Application métier

    400 fichiers PHP, 60 entités, 6 bundles maison

    28 920 € HT

  • Plateforme

    1 200 fichiers PHP, 150 entités, 15 bundles maison

    101 360 € HT

Exemples de la grille Bear Upgrade pour Symfony 5 → 8 (tests à 20 %, sans PHPStan ni CI), pas des devis : le prix ferme est fixé au cadrage.

Pour une migration Bear Upgrade livrée en Merge Requests, Rector tourne d’abord en dry-run sur les transformations mécaniques, Claude Code traite les cas que Rector ne couvre pas, puis un développeur senior relit chaque Merge Request. Votre équipe veut reprendre la main ensuite ? Pensez à apprendre à piloter Claude Code sur votre code. Exemple concret : la migration Symfony d’un e-commerce bordelais, et après la migration, la maintenance des versions garde le socle à jour.

Questions fréquentes

Pour aller plus loin

Sources

Votre migration Symfony 5 → 8, livrée en Merge Requests

CI au vert garantie 7 jours après le merge. Un appel de cadrage suffit pour fixer le périmètre, le prix et le délai.