Migrer Symfony en production : changer le moteur sans faire crasher l'avion

Migrer une application Symfony legacy en production, c'est l'un des défis les plus redoutés — et pourtant les plus fréquents — dans la vie d'une équipe de développement. Pas de filet de sécurité, peu de documentation, des dépendances obsolètes et un système qui doit continuer à tourner coûte que coûte. C'est précisément ce que va aborder Arnaud Oltra, Tech Lead chez Alesco, lors du SymfonyDay Montréal 2026 le 4 juin prochain.

Son retour d'expérience promet d'être sans concession : pas une présentation idéale sur comment devrait se passer une migration, mais un compte-rendu honnête de ce qui se passe vraiment quand on hérite d'un legacy non maintenu et qu'on doit le faire évoluer sans interruption de service.

Le vrai problème : pas "comment migrer", mais "par où commencer"

La question que pose Arnaud Oltra est révélatrice d'une réalité terrain souvent ignorée dans les articles théoriques : avant même de penser à une stratégie de migration, il faut comprendre l'état réel du système.

Une application legacy Symfony cumule généralement plusieurs handicaps :

• Des versions de composants Symfony (ou de bundles tiers) depuis longtemps dépréciées
• Une couverture de tests quasi inexistante, rendant tout refactoring risqué
• Une documentation lacunaire ou obsolète, fruit d'années de turnover
• Des couplages forts entre des parties du code qui semblent indépendantes

Dans ce contexte, le premier réflexe — réécrire proprement depuis zéro — est souvent une fausse bonne idée. La réécriture complète sous-estime systématiquement la complexité métier accumulée dans le legacy. Ce savoir implicite, encodé dans des milliers de lignes de code parfois obscures, a une valeur réelle. Le supprimer d'un coup, c'est prendre le risque de perdre des comportements critiques que personne ne sait plus documenter.

Les pièges classiques des migrations Symfony

Arnaud Oltra annonce vouloir partager les fausses bonnes idées rencontrées sur le terrain. Sans anticiper l'intégralité de son talk, on peut identifier plusieurs patterns d'échec récurrents dans ce type de projet.

Migrer version par version de façon séquentielle sans objectif fonctionnel est tentant car cela semble méthodique. En pratique, chaque saut de version (Symfony 3 → 4 → 5 → 6 → 7) introduit des breaking changes qui s'accumulent si on ne teste pas en conditions réelles. Le risque est de passer des mois en migration technique pure, sans valeur livrée, et de perdre le soutien des équipes métier.

Ignorer les tests au profit de la vitesse est une autre erreur classique. Sur un legacy sans tests, l'ajout de tests avant la migration est perçu comme une perte de temps. C'est pourtant le seul filet capable de détecter les régressions silencieuses — celles qui ne cassent pas directement mais qui altèrent subtilement un comportement métier.

Sous-estimer les dépendances indirectes est également fréquent. Un bundle abandonné peut dépendre d'une API interne Symfony qui a changé. La mise à jour d'un composant peut avoir des effets en cascade sur des parties du code qu'on pensait isolées.

Stratégies pour migrer sans casser la production

La bonne nouvelle, c'est que des approches éprouvées existent pour avancer de façon progressive et sécurisée.

Le strangler fig pattern consiste à faire cohabiter l'ancien et le nouveau système, en reroutant progressivement le trafic vers les nouvelles parties migrées. Appliqué à Symfony, cela peut signifier introduire un nouveau kernel ou de nouveaux contrôleurs modernisés qui coexistent temporairement avec l'ancien code, jusqu'à ce que la migration soit complète.

Les feature flags permettent de déployer du nouveau code en production sans l'activer pour tous les utilisateurs. On peut ainsi tester les parties migrées sur un sous-ensemble du trafic réel, détecter les anomalies et revenir en arrière sans déploiement d'urgence.

L'instrumentation avant la migration est souvent négligée. Avant de toucher au code, il est précieux d'ajouter des métriques et du logging sur les chemins critiques. Cela permet d'établir une baseline de comportement, et de comparer après chaque changement. Des outils comme Blackfire peuvent ici jouer un rôle important pour détecter les régressions de performance.

La priorisation par le risque métier plutôt que par la dette technique est un changement de paradigme important. Migrer en priorité les parties du code les plus risquées pour le business (paiement, authentification, calculs critiques) assure que l'effort technique produit une réduction réelle du risque, et non une amélioration cosmétique de la base de code.

Ce que le SymfonyDay Montréal 2026 nous réserve

Le talk d'Arnaud Oltra s'inscrit dans ce que le SymfonyDay Montréal a de meilleur à offrir : des retours d'expérience concrets, sans filtre marketing, sur des problèmes que toutes les équipes Symfony rencontrent tôt ou tard.

L'événement se tient le 4 juin 2026 à L'Espace Quartier Latin (UQAM) à Montréal, et s'annonce comme une journée dense d'échanges techniques de haut niveau.

Chez MulerTech, ce type de sujet résonne particulièrement. Accompagner des projets PHP/Symfony sur le long terme implique régulièrement de faire face à des bases de code vieillissantes, et de trouver le bon équilibre entre la stabilité opérationnelle et la modernisation technique. Il n'existe pas de recette universelle — mais partager les cicatrices des projets réels est probablement la meilleure façon de progresser collectivement.

Source originale : SymfonyDay Montreal 2026: Migrating Legacy Symfony in Production — Symfony Blog

Si vous travaillez sur un projet Symfony legacy et que vous vous posez les mêmes questions, la conférence du 4 juin est clairement une date à bloquer dans votre agenda.