Migration Sylius 2.0 : les 10 erreurs à éviter absolument
Migrer une boutique Sylius de la version 1.x vers la 2.0 est un chantier à part entière. Après avoir accompagné plusieurs équipes dans cette transition, Pierre-Arthur Demengel a recensé sur dev.to les dix erreurs les plus fréquentes. On reprend ici les points clés avec un regard pratique orienté planification et budgétisation.
🚧 Erreur n°1 : traiter ça comme un simple composer update
C'est l'illusion la plus dangereuse. Sylius 2.0 n'est pas une mise à jour mineure : c'est une migration de plateforme qui touche les templates, les state machines, le mailer, les paiements et l'ensemble du stack frontend.
Ce qu'il faut faire : ouvrir une branche dédiée, allouer un budget projet réaliste, rédiger un plan de tests. Ce n'est pas une tâche d'une après-midi.
🔍 Les points de vigilance techniques
Inventaire des overrides de templates
Les surcharges dans templates/bundles/SyliusShopBundle/ représentent la plus grande source de travail. Chaque fichier override doit être converti en Twig Hook — le nouveau système de personnalisation de Sylius 2.0. Beaucoup d'équipes repoussent cet inventaire et se retrouvent submergées en fin de projet.
Action concrète : avant même d'estimer la charge de migration, listez exhaustivement tous vos overrides de templates. Mappez chacun vers son équivalent Twig Hook. C'est ce listing qui déterminera en grande partie votre budget.
Compatibilité des plugins : ne supposez rien
Un plugin qui fonctionne sur Sylius 1.x n'est pas forcément compatible avec la 2.0. Les auteurs doivent adapter leur code à la nouvelle architecture, et beaucoup ne l'ont pas encore fait.
Action concrète : parcourez chaque plugin Sylius dans votre composer.json. Vérifiez sa compatibilité sur le Sylius Addons Marketplace et sur GitHub. Si aucune version 2.0 n'existe et qu'aucune annonce n'est faite, anticipez soit une réécriture interne, soit une solution alternative. Ce point peut bloquer tout le projet.
Les tests automatisés : votre filet de sécurité
Migrer sans suite de tests, c'est avancer les yeux bandés. Les régressions fonctionnelles — tunnel d'achat cassé, calcul de taxes erroné, emails qui ne partent plus — sont difficiles à détecter manuellement sur une boutique complexe.
Action concrète : avant de démarrer la migration, assurez-vous d'avoir une couverture minimale des parcours critiques (ajout au panier, checkout, paiement, confirmation de commande). Des tests Behat ou Playwright sur les scénarios métier clés permettront de valider chaque étape de la migration.
⚙️ Infrastructure, CI/CD et stratégie de rollback
Staging identique à la production
Tester la migration uniquement en local est insuffisant. Les différences d'environnement (PHP version, extensions, configuration serveur) peuvent masquer des problèmes qui n'apparaîtront qu'en production.
Action concrète : provisionnez un environnement de staging via Docker Compose ou votre pipeline CI/CD, aussi proche que possible de la production. Jouez la migration complète sur cet environnement avant toute mise en ligne.
Planifier le rollback avant d'en avoir besoin
Même avec une préparation soignée, des imprévus peuvent survenir lors du passage en production. Ne pas avoir de plan de retour arrière, c'est prendre un risque commercial majeur — surtout pour une boutique en activité.
Action concrète : définissez à l'avance votre stratégie de rollback : snapshot de base de données, tag Git de la version stable, procédure de restauration documentée et testée. La fenêtre de migration doit être planifiée pendant une période de faible trafic.
Release management : communiquer avec le métier
La migration Sylius 2.0 impacte potentiellement l'expérience acheteur (nouveau frontend), les workflows back-office et les intégrations tierces (ERP, logistique, paiement). Les équipes métier doivent être impliquées tôt.
Action concrète : préparez une matrice d'impact par domaine fonctionnel. Identifiez les parties prenantes concernées et planifiez des recettes métier avant le go-live. Une migration technique réussie qui surprend les équipes opérationnelles reste une migration ratée.
✅ Checklist de départ
Avant de lancer votre migration Sylius 2.0, validez ces points :
Conclusion
Sylius 2.0 est une refonte architecturale significative, pas une mise à jour de routine. Les équipes qui réussissent cette migration sont celles qui la traitent comme un projet à part entière : avec une estimation sérieuse, une préparation technique rigoureuse et une coordination claire entre les équipes techniques et métier.
Si vous préparez cette migration pour un projet PHP/Symfony, n'hésitez pas à nous contacter chez MulerTech pour un audit préalable ou un accompagnement.
📖 Article source : Top 10 Mistakes When Migrating Sylius to 2.0 — Pierre-Arthur Demengel, dev.to
