Sylius 2 : peut-on conserver notre base de données ?

Oui, vous conservez votre base de données. Une migration Sylius 1.14 vers Sylius 2 met à jour la base existante grâce aux migrations Doctrine : produits, déclinaisons, clients, commandes, paiements et promotions restent en place, sans export ni ressaisie. Ce qui change, c'est la structure de quelques tables et la manière dont le code lit certaines données. Le travail consiste donc à appliquer ces migrations sur une copie de la production, à vérifier le résultat, puis à les rejouer le jour de la bascule.

C'est souvent la première inquiétude d'un dirigeant : des années de commandes, des milliers de comptes clients, un historique comptable. Il n'est pas question de repartir d'une boutique vide. Je vous explique ce qui se passe réellement dans la base, les points qui méritent une vraie vérification et la méthode que j'applique pour que rien ne se perde.

Que dit la documentation officielle sur la base de données ?

Le guide officiel UPGRADE-2.0 traite la question en une section courte. Les migrations Doctrine de Sylius ont été régénérées : tous les anciens fichiers de migration du cœur ont été supprimés, et leur contenu tient désormais dans un seul fichier. Pour appliquer la nouvelle migration et se débarrasser des anciennes entrées, la documentation demande simplement de lancer les migrations comme d'habitude, avec bin/console doctrine:migrations:migrate.

Le message est clair : la base n'est pas jetée, elle est mise à niveau. Le même mécanisme servait déjà pour chaque version 1.x. Le fichier UPGRADE-1.13 décrivait par exemple une migration qui convertit des colonnes stockées en tableau sérialisé vers du JSON. Si vous partez d'une 1.12 ou d'une 1.13, ces migrations intermédiaires s'appliquent aussi, dans l'ordre, avant d'arriver en 2.0. Ce qu'il advient des anciens fichiers de migration propres à votre projet est un sujet à part, que je traite dans l'article sur les anciennes migrations Doctrine.

Qu'est-ce qui change réellement dans les données ?

Pour l'essentiel, vos données métier ne bougent pas. Un produit reste un produit, une commande garde ses lignes, ses montants, son adresse et son historique d'états. Les changements portent sur des détails de structure et sur la façon dont le code les exploite.

Le cas le plus sensible concerne les comptes. Le guide officiel indique que l'encodeur et le sel ont été retirés des entités utilisateur, et que c'est désormais le hacheur de mots de passe configuré dans la sécurité Symfony qui est utilisé. Il précise que si certains utilisateurs n'ont pas le nom de l'algorithme stocké dans leur mot de passe, il peut falloir configurer l'option migrate_from, décrite dans la documentation Symfony sur les mots de passe. Mal réglé, ce point ne détruit aucune donnée, mais empêche des clients de se connecter. Je le vérifie avec de vrais comptes anciens, pas avec un compte créé la veille.

Autre exemple : la configuration des passerelles de paiement change de place dans le code, de la ressource Payum vers la ressource de paiement de Sylius. Les paiements passés restent dans la base, mais la configuration de vos moyens de paiement doit être relue et testée.

Enfin, vos propres entités comptent. Si votre boutique a ajouté des champs aux produits, aux clients ou aux commandes, ou créé ses propres tables, leur cartographie Doctrine doit rester cohérente avec le nouveau schéma du cœur. C'est là que se cachent la plupart des surprises.

Comment migrer la base sans rien perdre ?

Travailler sur une copie de la production

Je ne lance jamais une migration de schéma pour la première fois sur la vraie base. Je récupère une copie récente, anonymisée si nécessaire, et je fais tout le chantier dessus. La production continue de prendre des commandes en 1.14 pendant ce temps.

Comparer avant et après

Après chaque migration, je compare les volumes : nombre de produits, de déclinaisons, de clients, de commandes par état, de paiements, de promotions actives. Je vérifie aussi que Doctrine ne voit plus d'écart entre le code et le schéma. Un chiffre qui bouge sans raison est un signal d'arrêt. La méthode de contrôle détaillée fait l'objet de l'article sur la conservation des données clients et commandes.

Répéter et chronométrer

Je rejoue la migration plusieurs fois, depuis une copie fraîche, pour mesurer sa durée réelle et fiabiliser chaque commande. C'est cette répétition qui permet de fixer la fenêtre de bascule et de garder une sauvegarde prête pour un retour arrière.

Si vous voulez savoir ce que votre schéma et vos entités personnalisées impliquent, je lance Sylius Upgrade Analyzer sur votre projet et je vous remets un diagnostic de migration offert, avec les points de vigilance sur vos données.

Faut-il parfois repartir d'une base neuve ?

Rarement pour une boutique en 1.12, 1.13 ou 1.14. La question se pose surtout pour une boutique très ancienne, où l'enchaînement des montées de version coûterait plus cher qu'une installation Sylius 2 propre suivie d'une reprise de données. Même dans ce cas, on ne perd pas l'historique : on le transfère, ce qui demande alors un vrai projet de reprise, avec ses scripts et ses contrôles. C'est un choix à faire en connaissance de cause, pas par défaut.

Ce que je vous propose

Votre base de données est l'actif le plus précieux de la boutique, et elle se conserve très bien lors d'une migration Sylius 2, à condition d'être traitée avec méthode. Avant le 31 décembre 2026, date de fin des correctifs de sécurité de la 1.14, je vous propose de faire le point : je lance l'analyseur sur votre projet, je relève les entités et les configurations à surveiller, et je vous remets un rapport commenté avec une estimation en jours. Je vous rappelle sous 24 heures ouvrées, et le diagnostic est offert.