Sylius 2 : comment conserver clients et commandes ?

Pour garantir la conservation des données clients et commandes lors d'une migration vers Sylius 2, on ne transfère rien d'un système à un autre : on met à niveau la même base, et on le prouve. La garantie repose sur trois choses : une sauvegarde complète que l'on a réellement restaurée, des répétitions de la migration sur une copie de la production, et des contrôles chiffrés avant et après (comptages, échantillons, parcours du service client). Les clients, les commandes et les stocks restent alors exactement là où ils étaient.

Je suis Pierre-Arthur Demengel, développeur Sylius indépendant, et c'est la question sur laquelle je refuse de répondre seulement « ne vous inquiétez pas ». Vos données clients et votre historique de commandes sont votre actif, et vous en avez besoin chaque jour pour la comptabilité, le service client et les réclamations. Une promesse ne vaut rien sans preuve.

Les données clients et commandes sont-elles reprises automatiquement ?

Oui, au sens où elles restent dans la base. Le guide officiel UPGRADE-2.0 indique que les migrations Doctrine ont été regroupées en un seul fichier, appliqué par la commande habituelle. Cette migration ajuste le schéma, elle ne vide aucune table. Les clients, leurs adresses, leurs comptes, les commandes, leurs lignes, leurs paiements, leurs expéditions et les stocks des variantes restent en place. Le sujet de la base dans son ensemble est traité dans l'article sur la conservation de la base de données.

Il y a pourtant des exceptions à connaître. Sylius 2 retire des utilisateurs, clients comme administrateurs, les champs locked, expiresAt et credentialsExpireAt, ainsi que les colonnes correspondantes. Si votre boutique s'en servait, par exemple pour bloquer des comptes ou faire expirer des accès, il faut exporter ces valeurs et prévoir leur remplacement avant la migration. De même, le champ salt et l'ancienne configuration des encodeurs disparaissent au profit du hacheur de mots de passe de Symfony.

Comment garantir la conservation des données en pratique ?

Une sauvegarde que l'on a restaurée

Une sauvegarde qui n'a jamais été restaurée n'est qu'une hypothèse. Avant le chantier, je fais une sauvegarde complète de la base et des fichiers (images, factures générées, documents), puis je la restaure sur un serveur séparé et je vérifie que la boutique y démarre. C'est cette copie qui sert ensuite de terrain d'essai.

Des répétitions sur une copie de la production

La migration est jouée plusieurs fois sur des copies récentes de la production, jamais directement sur la boutique en ligne. Chaque répétition révèle des cas que la base de test ne contenait pas : une commande ancienne au format inhabituel, un client sans adresse, une variante supprimée encore présente dans de vieilles commandes. On corrige, puis on rejoue jusqu'à obtenir un passage propre.

Des contrôles chiffrés avant et après

Avant chaque répétition, je relève par requête le nombre de clients, de comptes, d'adresses, de commandes par état, de lignes de commande, de paiements par état, d'expéditions, ainsi que la somme des montants des commandes et le stock disponible et réservé de chaque variante. Après la migration, les mêmes requêtes doivent donner les mêmes résultats. Une somme identique au centime sur des milliers de commandes est une preuve bien plus solide qu'un coup d'œil dans l'administration.

Pour repérer en amont le code qui touche à ces données (entités clients ou commandes étendues, champs supprimés, configuration des mots de passe), je lance Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store. Si vous voulez ce relevé et le plan de contrôle pour votre boutique, ils font partie du diagnostic de migration offert.

Les stocks et les commandes seront-ils bien repris ?

Les stocks sont des données de la base : le stock disponible et le stock réservé de chaque variante sont repris tels quels. Le risque n'est pas dans la migration, il est dans le moment de la bascule. Si des commandes arrivent ou si l'ERP envoie des mises à jour de stock entre la dernière sauvegarde et la mise en ligne de Sylius 2, ces mouvements sont perdus. La parade est un gel court : boutique en maintenance, synchronisations suspendues, sauvegarde finale, migration, contrôles, réouverture. Je décris cette séquence dans l'article sur les commandes en cours pendant la bascule, et la mise en production dans celui sur la bascule sans coupure.

Retrouverai-je mes commandes et mes clients pour les réclamations ?

Oui, et c'est un test à part entière. Le service client doit pouvoir, dès le lendemain de la bascule, retrouver une commande par son numéro, par le nom ou l'e-mail du client, voir ses lignes, ses paiements, son expédition et son numéro de suivi, puis effectuer un remboursement si besoin. Pendant la recette, je demande à la personne qui traite les réclamations de rejouer ses dix dernières demandes réelles sur la copie Sylius 2. Si elle retrouve tout, la donnée est là et elle est exploitable.

Côté client, la même vérification porte sur l'espace « Mon compte » : connexion avec un ancien mot de passe, historique des commandes, adresses enregistrées. Ce point est détaillé dans l'article sur les comptes clients et l'historique de commandes. Enfin, je conserve la sauvegarde de la version 1.14 et la copie de recette jusqu'à ce que la nouvelle version ait fait ses preuves, pour pouvoir retrouver n'importe quelle donnée dans son état d'origine.

Ce que je vous propose

Je lance l'analyseur sur votre projet, je relève le code et les champs qui touchent aux données clients, commandes et stocks, et je vous remets un rapport commenté avec le plan de contrôle et une estimation en jours. Je vous rappelle sous 24 heures ouvrées. Le support de sécurité de Sylius 1.14 s'arrête le 31 décembre 2026 : préparer la reprise des données tôt, c'est se donner le temps de faire plusieurs répétitions plutôt qu'une seule, la veille de la bascule.