Migrer de Sylius 1.12 ou 1.13 directement vers Sylius 2 ?

Non, pas directement : le chemin prévu par Sylius passe par la version 1.14. Le guide officiel UPGRADE-2.0 est écrit pour une boutique qui part de la 1.14, et c'est la 1.14 qui signale, par ses dépréciations, ce qui cassera en 2.0. Depuis une 1.12 ou une 1.13, on monte donc d'abord en 1.14, on supprime ses dépréciations, puis on migre vers Sylius 2. Passer par la 1.14 est obligatoire dans les faits, mais cette étape fait partie du même chantier et se prépare sans couper la boutique.

La question revient souvent chez les dirigeants qui découvrent l'échéance du 31 décembre 2026 : pourquoi perdre du temps sur une version 1.x qu'on va quitter ? La réponse tient en une idée. La 1.14 n'est pas un détour, c'est le banc d'essai de la migration. Je vous explique ce que dit la documentation, ce que vous gagnez à respecter l'ordre, et comment j'enchaîne les étapes pour que la marche supplémentaire ne rallonge pas inutilement le calendrier.

Que dit la documentation officielle sur le chemin de migration ?

Sylius publie un fichier UPGRADE par version mineure. Celui de la 1.13 contient une section consacrée au passage de la 1.12 à la 1.13, celui de la 1.14 une section pour le passage de la 1.13 à la 1.14, et le guide UPGRADE-2.0 s'intitule explicitement « UPGRADE FROM 1.14 TO 2.0 ». Chaque document suppose que vous avez appliqué le précédent. Il n'existe pas de guide qui parte de la 1.12 ou de la 1.13 pour arriver en 2.0.

Le fichier de la 1.14 est le plus instructif pour la suite. Il annonce noir sur blanc des éléments dépréciés qui « seront supprimés en 2.0 », comme le paramètre de configuration de la machine à états, et introduit de nouveaux identifiants de services destinés à remplacer les anciens en Sylius 2.0. Autrement dit, la 1.14 vous laisse préparer une bonne partie de la migration pendant que la boutique tourne encore sur une version maintenue.

Côté calendrier, le cycle de publication officiel de Sylius est sans appel pour les versions intermédiaires : la 1.12 ne reçoit plus de correctifs de sécurité depuis le 31 décembre 2024, la 1.13 depuis le 30 avril 2025. La 1.14, dernière version 1.x, en reçoit jusqu'au 31 décembre 2026.

Pourquoi ne pas sauter directement en Sylius 2 ?

Techniquement, rien ne vous interdit de modifier la contrainte dans composer.json et de lancer la mise à jour vers 2.x en une seule fois. En pratique, c'est la façon la plus sûre de vous retrouver avec une application qui ne démarre plus, sans savoir laquelle des centaines de modifications en est la cause. Les changements de la 1.13 et de la 1.14 s'additionnent à ceux de la 2.0, et vous perdez le seul outil de diagnostic gratuit que Sylius vous donne : les avertissements de dépréciation.

Sur une 1.14 à jour, chaque appel à une classe, un service ou une option promise à la suppression laisse une trace dans les journaux et dans la barre de débogage Symfony. On corrige ces traces une par une, on livre en production, et la boutique continue de vendre. Quand la liste est vide, le passage en 2.0 ne porte plus que sur les vraies ruptures : interface, gabarits, paiements, API. Sauter la 1.14, c'est découvrir tout cela le même jour.

Pour le dirigeant, la conséquence est simple : la marche 1.14 réduit le risque de la migration et permet de livrer du travail utile avant l'échéance, même si la version 2 n'est pas encore prête.

Comment enchaîner les étapes depuis une 1.12 ou une 1.13 ?

Monter la version de PHP en premier

Le fichier UPGRADE-1.13 relève la version minimale de PHP à 8.1 et recommande de faire cette mise à jour alors que la boutique est encore en 1.12. Sylius 2 demande ensuite PHP 8.2, et la 2.3 PHP 8.3. Je traite donc souvent l'hébergement en premier, sur la version 1.x actuelle, pour ne pas mélanger un changement de serveur et un changement de framework.

Passer chaque version mineure et la livrer

Depuis une 1.12, j'applique les consignes de la 1.13, je teste les parcours de commande, puis celles de la 1.14. Chaque fichier contient aussi ses migrations de base de données, dont certaines touchent des colonnes existantes : celui de la 1.13 décrit par exemple la conversion de champs stockés en tableau sérialisé vers du JSON. Ces étapes se vérifient sur une copie de la production, pas en direct.

Vider les dépréciations de la 1.14

C'est ici que l'outillage fait gagner du temps. Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store, analyse le projet en local, liste les usages incompatibles avec la version 2 et applique une partie des corrections automatiquement. On obtient une liste chiffrée au lieu d'une impression.

Migrer vers 2.0 puis vers la version cible

On applique enfin le guide UPGRADE-2.0, puis les fichiers des versions suivantes jusqu'à la cible. La 2.0 et la 2.1 ne sont plus maintenues, ce sont des étapes de lecture, pas des destinations. Le choix entre 2.2 et 2.3 dépend surtout de votre hébergement, je le détaille dans l'article sur le choix de la version cible.

Faut-il obligatoirement passer par Sylius 1.14 si la boutique est très ancienne ?

Pour une 1.12 ou une 1.13, oui, et c'est raisonnable : l'écart reste maîtrisable. Pour une boutique plus ancienne, en 1.9, 1.10 ou 1.11, le nombre de marches change la donne. Il faut alors comparer deux chemins : enchaîner les montées de version jusqu'à la 1.14, ou repartir d'une installation Sylius 2 propre et reprendre les données. J'ai consacré un article entier à cet arbitrage : migrer ou reconstruire une vieille version Sylius.

Si vous hésitez sur votre cas, le plus rapide est de me laisser regarder le code. Je lance l'analyseur sur votre projet et je vous remets un diagnostic de migration offert, qui distingue le coût de la marche 1.14 de celui du passage en 2.

Combien de temps ajoute la marche intermédiaire ?

Je ne vous donnerai pas de moyenne, elle n'aurait aucun sens. Une boutique 1.13 proche du standard rejoint la 1.14 rapidement, une boutique qui a surchargé beaucoup de services y passe plus de temps. Ce qui est sûr, c'est que le travail fait sur la 1.14 n'est pas perdu : supprimer une dépréciation, c'est déjà écrire le code compatible avec Sylius 2. La méthode d'estimation que j'applique est détaillée dans l'article sur la durée d'une migration en jours.

Ce que je vous propose

Si votre boutique tourne en 1.12 ou en 1.13, elle ne reçoit déjà plus de correctifs de sécurité, et la 1.14 elle-même n'en recevra plus après le 31 décembre 2026. Le bon moment pour poser le chemin complet, c'est maintenant. Je lance Sylius Upgrade Analyzer sur votre projet, je vous remets un rapport commenté avec les étapes dans l'ordre et une estimation en jours, et je vous rappelle sous 24 heures ouvrées. Le diagnostic est offert et le rapport vous appartient, que vous me confiiez le chantier ou non.