Sylius 1.9 à 1.12 : migrer vers Sylius 2 ou reconstruire

Depuis Sylius 1.9, 1.10, 1.11 ou 1.12, migrer reste le bon choix quand le code sur mesure est raisonnable, testé et compris, parce que vos données, vos URL et vos règles métier restent en place. Reconstruire sur Sylius 2.3, puis reprendre les données, devient souvent plus court quand la version est très ancienne, que le code est hérité d'un prestataire parti et que le front doit de toute façon être refait. La décision se prend sur des critères mesurables, pas sur l'âge de la boutique.

Où en est votre version de Sylius aujourd'hui ?

Toutes ces versions sont sorties du support de sécurité depuis longtemps. Les dates ci-dessous viennent d'endoflife.date, qui reprend le cycle de publication officiel, et les versions de PHP et de Symfony des fichiers composer de chaque branche.

Deux conséquences. D'abord, la question n'est plus « faut-il bouger ? » : une boutique en 1.9 tourne sans correctif de sécurité depuis 2022, souvent sur une version de PHP elle-même abandonnée. Ensuite, quel que soit le chemin, l'écart à combler est énorme : de PHP 7.3 et Symfony 4.4 à PHP 8.3 et Symfony 7.4, plus toutes les ruptures de Sylius 2.

Que veut dire « migrer » depuis une version aussi ancienne ?

Le chemin officiel ne permet pas de sauter d'étape. On monte de version mineure en version mineure jusqu'à la 1.14, en appliquant chaque fichier UPGRADE (1.10, 1.11 et son guide API dédié, 1.12, 1.13, 1.14). On supprime ensuite les dépréciations signalées par la 1.14, puis on passe en 2.0 avec le guide UPGRADE-2.0, et on enchaîne les fichiers suivants jusqu'à la version cible. Il n'existe pas de set Rector officiel pour migrer automatiquement le cœur de 1.14 vers 2.0.

À chaque marche, il faut monter PHP et Symfony si la version l'exige, mettre à jour les plugins, jouer les migrations Doctrine sur une copie de la base de production et faire passer les tests. La 1.14 n'est qu'un palier : son support de sécurité s'arrête le 31 décembre 2026, on ne s'y arrête donc pas.

Le saut vers 2.0 est le plus lourd. Semantic UI et jQuery laissent la place à Bootstrap 5 et Symfony UX, les template events disparaissent au profit des Twig Hooks, winzou laisse la place à Symfony Workflow par défaut, API Platform passe de 2.7 à 4 et plusieurs bibliothèques sont retirées (FOSRest, JMS Serializer, SwiftMailer). Je détaille ces ruptures dans le guide complet de la migration Sylius 1.x vers 2.

Le point que l'on oublie : le front est refait dans les deux cas

Que vous migriez ou que vous reconstruisiez, les gabarits de la boutique 1.x ne fonctionnent pas tels quels en Sylius 2. Le LegacyShopBridgePlugin officiel permet de garder le front 1.x sur Sylius 2, mais il est encore expérimental et seul le cœur est garanti, les plugins tiers se vérifient au cas par cas. Le coût du front pèse donc presque autant dans les deux scénarios. La vraie différence se joue sur le code métier côté serveur.

Comment décider entre migrer et reconstruire ?

Voici la grille que j'utilise. Elle ne donne pas de score magique : elle oblige à répondre honnêtement à chaque ligne avant de choisir.

Si la majorité de vos réponses tombe à gauche, migrez. Si elle tombe à droite, reconstruire sur Sylius 2.3 sera probablement plus court et plus sûr, parce que chaque marche de migration exigerait de comprendre, réparer puis jeter du code qui ne sert plus. Entre les deux, le facteur décisif est presque toujours la combinaison « pas de tests et personne ne connaît le code » : sans filet, chaque marche devient une recherche archéologique.

Reconstruire ne veut pas dire repartir de zéro. On installe un Sylius 2.3 propre, on reprend uniquement le code métier encore utile en le réécrivant sur les nouvelles briques, et on reprend les données. Le modèle de données de Sylius a évolué entre ces versions, mais ses grandes notions (produits, variantes, catégories, clients, commandes) sont restées les mêmes, ce qui rend la reprise réaliste.

Comment reprendre les données sans rien perdre ?

Deux méthodes existent. La première consiste à faire monter la base elle-même : on la passe dans les migrations Doctrine de chaque version, sur une copie, jusqu'au schéma de la 2.x. En 2.0, les migrations ont été regroupées en un seul fichier, ce qui demande une étape de recalage documentée dans le guide officiel. La seconde consiste à exporter puis importer par scripts : plus de travail, mais l'occasion de nettoyer les données mortes.

Quel que soit le choix, quatre points se vérifient à part. Les mots de passe clients : Sylius 2 retire le champ salt et s'appuie sur les hashers de Symfony, et les anciens comptes peuvent demander l'option migrate_from pour éviter d'imposer une réinitialisation à tous vos clients. Les commandes et leur numérotation, avec leurs états de paiement et d'expédition. Les factures, dont la numérotation ne doit pas être rompue. Et les slugs, qui portent votre référencement : un slug régénéré, c'est une URL nouvelle, comme je l'explique dans l'article sur le SEO d'une migration Sylius 2.

Je fais toujours une répétition complète de la reprise sur une copie de la production, puis un contrôle par comptage et par échantillon : nombre de clients, de commandes, de produits, et quelques commandes ouvertes une à une. Sur la boutique Coucouroucoucou, la reprise d'environ 15 000 commandes est vérifiée ainsi en recette, avant la mise en production. La méthode de bascule elle-même est décrite dans l'article sur la mise en production sans coupure.

Par où commencer cette semaine ?

Commencez par mesurer, pas par choisir. Sylius Upgrade Analyzer analyse les projets Sylius de 1.0 à 1.14 et liste ce qui casse en Sylius 2 : gabarits, dépréciations, plugins, grilles, API. Il exige lui-même PHP 8.2 ou plus ; sur une boutique encore en PHP 7, on l'installe dans un environnement de travail récent et on lui passe le chemin du projet. Il mesure l'écart avec Sylius 2, il ne remplace ni la lecture des fichiers UPGRADE intermédiaires, ni les tests, ni la connaissance de votre métier.

J'ai déjà mené des montées de version Sylius 1.x vers 2.x de boutiques en production pour mes clients, et je dis aussi quand reconstruire est plus raisonnable. Si votre boutique est en 1.9, 1.10, 1.11 ou 1.12, demandez le diagnostic offert de migration Sylius 2 : je passe votre code à l'analyseur, je remplis la grille avec vous et je vous donne une estimation en jours pour chacun des deux chemins.