Migrer de Symfony 6.4 à 7.4 LTS

Le calendrier des versions

Symfony publie une version LTS (support à long terme) tous les deux ans, en novembre. Une LTS reçoit des corrections de bugs pendant trois ans et des correctifs de sécurité pendant quatre ans. Les versions intermédiaires ne sont maintenues que huit mois.

Dates issues du calendrier officiel publié sur symfony.com/releases. Vérifiez-y la version exacte de votre projet.

Concrètement, si votre application tourne en 6.4, elle ne recevra plus de corrections de bugs à partir de novembre 2026, et plus de correctifs de sécurité un an plus tard. C'est le bon moment pour planifier la migration : assez tôt pour la mener sans urgence, et sur une base encore maintenue.

7.4 LTS ou Symfony 8 ?

Symfony 7.4 et 8.0 sont sorties en même temps, avec les mêmes fonctionnalités. La différence : la 8.0 retire tout ce que la 7.4 déclare obsolète, et elle exige PHP 8.4.

• Symfony 7.4 LTS convient à une application métier qui doit rester stable : une migration maintenant, puis plus de changement de version majeure avant 2029.
• Symfony 8.x convient à une équipe qui met à jour ses dépendances en continu et veut les dernières fonctionnalités. Il faut alors suivre une nouvelle version tous les six mois.

Dans la plupart des cas, je recommande la 7.4. Et une application propre en 7.4, sans dépréciation, sera ensuite simple à passer en 8.

La méthode en cinq étapes

1. Faire l'état des lieux

   Lister les dépendances et leur compatibilité avec Symfony 7, vérifier la version de PHP (Symfony 7 demande au moins PHP 8.2), et mesurer la couverture de tests. Deux commandes donnent une première vue :

   composer outdated "symfony/*"
   composer why-not symfony/framework-bundle 7.4

   La seconde liste chaque paquet qui bloque le passage en 7.4.

2. Poser des tests sur ce qui marche

   Avant de toucher au code, il faut un filet. Pas besoin d'une couverture complète : des tests fonctionnels sur les parcours critiques (connexion, paiement, API exposées) suffisent à détecter une régression.

3. Supprimer les dépréciations en 6.4

   C'est le cœur du travail. Toutes les fonctionnalités retirées en 7.0 sont déjà signalées comme dépréciées en 6.4. On les corrige une par une, en restant sur la version actuelle, avec la barre de débogage et le rapport de dépréciations de PHPUnit. Rector automatise une partie des changements, par exemple le passage des annotations aux attributs PHP.

4. Changer de version majeure

   Une fois le journal des dépréciations vide, on passe les contraintes Composer en 7.4.*, on met à jour les recettes Flex avec composer recipes:update, puis on relance toute la suite de tests.

5. Livrer par étapes

   Déploiement sur un environnement de recette, vérification des journaux et des parcours critiques, puis mise en production. Chaque lot est livré séparément, ce qui permet de revenir en arrière facilement.

Ce qui bloque le plus souvent

Les bundles tiers

Un bundle abandonné, qui ne déclare pas la compatibilité avec Symfony 7, bloque toute la migration. Il faut alors trouver une version maintenue, un équivalent, ou remplacer le bundle par du code maison. C'est souvent ce point qui fait varier le plus l'estimation.

Les annotations

Symfony 7 ne lit plus les annotations (@Route, contraintes de validation, groupes de sérialisation), et Doctrine ORM 3 les abandonne aussi pour le mapping des entités. Il faut les convertir en attributs PHP 8. Rector le fait en grande partie, mais la configuration des routes et du mapping doit suivre.

Les tests qui dépendent des détails internes

Des tests qui simulent le client HTTP ou le conteneur de services en s'appuyant sur des classes internes cassent à chaque version. Mieux vaut les réécrire une fois pour qu'ils passent par les interfaces publiques.

La version de PHP

Passer de PHP 8.1 à 8.2 ou plus impose parfois de mettre à jour l'image Docker, la configuration de l'hébergement et la CI en même temps. À prévoir dans le plan, pas à découvrir le jour du déploiement.

Retour d'expérience : un service de paiement

Ce que je propose

Deux temps, chacun au forfait :

1. Un audit de votre application : dépendances bloquantes, volume de dépréciations, couverture de tests, version de PHP. Vous recevez un plan de migration découpé en lots, avec un prix et une durée pour chacun. Ce plan reste utilisable même si vous menez la migration en interne.
2. La migration, lot par lot, avec les tests qui la sécurisent et une documentation des changements pour votre équipe.

Je travaille à distance, partout en France, en direct ou en sous-traitance pour une agence ou une ESN.

Questions fréquentes

Source du calendrier : symfony.com/releases. Page mise à jour le 2 octobre 2026.