Migration Sylius 1.x vers Sylius 2 : quand migrer et comment préparer son projet ?

Migration d’un projet e-commerce Sylius 1.x vers Sylius 2

Vous avez un projet e-commerce sous Sylius 1.x et vous vous demandez s’il est temps de passer à Sylius 2 ? La migration ne consiste pas simplement à mettre à jour une version. Selon votre architecture, vos développements spécifiques, vos plugins et vos intégrations avec le système d’information, elle peut nécessiter une adaptation plus ou moins importante de la plateforme.

Avant de migrer, il est donc essentiel d’auditer l’existant pour identifier ce qui peut être conservé, ce qui doit être adapté et ce qui peut être repensé.

à retenir

Faut-il migrer vers Sylius 2 ?
Oui, il est pertinent de préparer la migration d’un projet encore sous Sylius 1.x, notamment parce que Sylius 1.14 est désormais en phase de correctifs de sécurité uniquement. Mais la bonne trajectoire dépend de l’état réel de votre plateforme.

Faut-il refaire son e-commerce ?
Non. Une migration Sylius 2 ne nécessite pas systématiquement de repartir de zéro. Une partie des développements, données, parcours et intégrations peut être conservée si l’architecture le permet.

Quels sont les principaux points de vigilance ?
Les plugins, développements spécifiques, dépendances techniques, frontend, données et connexions avec l’ERP, PIM, CRM, WMS ou les solutions de paiement doivent être analysés avant la migration.

La migration peut-elle être l’occasion de faire évoluer la plateforme ?
Oui. Lorsque l’existant présente une dette technique ou que les besoins métier ont évolué, le passage à Sylius 2 peut être l’occasion de moderniser l’architecture, améliorer les performances et préparer les prochaines évolutions du e-commerce.

La première étape consiste donc à définir une trajectoire adaptée à votre projet : migrer, adapter, refactorer ou faire évoluer certaines briques plutôt que de reproduire automatiquement l’existant.

Votre projet Sylius 1.x arrive à un tournant

Un projet Sylius peut rester performant pendant plusieurs années. Mais les évolutions successives peuvent progressivement complexifier son architecture : développements spécifiques, plugins, dépendances, intégrations avec le système d’information ou règles métier historiques.

La question de la migration devient alors stratégique.

Sylius 1.14, dernière version de la branche 1.x, bénéficie désormais uniquement de correctifs de sécurité jusqu’en décembre 2026.

Pour les entreprises qui exploitent un e-commerce métier, l’enjeu n’est donc pas simplement de « passer à Sylius 2 », mais de déterminer comment faire évoluer la plateforme sans fragiliser l’existant.

Quand faut-il envisager une migration ?

À analyserQuestions à se poser
Code & architectureQuels développements spécifiques doivent être adaptés ?
PluginsSont-ils compatibles, maintenus ou à remplacer ?
DépendancesQuelles évolutions de PHP, Symfony et des composants sont nécessaires ?
FrontendPeut-il être conservé ou doit-il évoluer ?
DonnéesQuelles adaptations ou migrations sont nécessaires ?
Système d’informationLes flux ERP, PIM, CRM, WMS et paiement restent-ils compatibles ?
TestsLes parcours critiques sont-ils suffisamment couverts ?

Migration ou refonte : il ne faut pas forcément choisir

Une migration Sylius 2 peut suivre plusieurs trajectoires :

Migration de l’existant
Lorsque l’architecture est saine et que les besoins métier sont relativement stables.

Migration + évolution
Lorsque certaines briques doivent être modernisées ou que de nouvelles fonctionnalités sont prévues.

Refonte partielle ou complète
Lorsque l’architecture est devenue trop complexe, difficile à maintenir ou ne correspond plus aux enjeux actuels.

L’objectif n’est donc pas de reconstruire systématiquement votre e-commerce, mais de conserver ce qui crée de la valeur et de faire évoluer ce qui limite désormais votre plateforme.

Sylius 2 : transformer une migration technique en projet d’évolution

Le passage à Sylius 2 peut être l’occasion de repartir sur une base plus saine et de préparer les prochaines étapes de votre e-commerce.

La démarche peut être résumée en quatre étapes :

1. Auditer

Analyser la version actuelle de Sylius, l’architecture, les plugins, les développements spécifiques, les dépendances et les intégrations SI.

2. Arbitrer

Déterminer ce qui peut être conservé, adapté, remplacé ou repensé.

3. Migrer

Adapter les composants concernés et sécuriser les parcours critiques à travers les tests et la recette.

4. Faire évoluer

Profiter de cette nouvelle base pour traiter les évolutions métier : nouveaux parcours, performance, B2B, marketplace, multi-store ou nouvelles intégrations.

Une migration Sylius 2 réussie est donc une migration adaptée à votre projet, et non l’application d’une recette standard.

Vous avez déjà un projet Sylius ? Cyllene peut partir de l’existant

Cyllene accompagne aussi les entreprises qui disposent déjà d’une plateforme Sylius et souhaitent la faire évoluer.

Notre intervention peut couvrir :

  • Audit de l’existant : architecture, code, plugins, dépendances et intégrations ;
  • Définition de la trajectoire : migration, refactoring, évolution ou refonte ;
  • Migration et sécurisation : adaptations techniques, tests et recette ;
  • Évolutions métier : nouveaux parcours, fonctionnalités, performance et intégrations SI.

Cette approche permet également de reprendre un projet développé par une autre agence : l’objectif est d’abord de comprendre l’existant avant de décider ce qui doit évoluer.

Notre équipe Web à taille humaine réunit chefs de projet, experts UX/UI et développeurs Sylius/Symfony, avec la possibilité de mobiliser les expertises complémentaires du groupe en infrastructure, hébergement, cybersécurité, data ou IA.

Conclusion

Une migration Sylius 1.x vers Sylius 2 ne signifie pas nécessairement une refonte complète.

La bonne trajectoire dépend de votre version actuelle, de votre architecture, de vos plugins, de vos développements spécifiques et de votre système d’information.

L’audit permet de répondre à trois questions essentielles :

  • Que pouvons-nous conserver ?
  • Que devons-nous adapter ?
  • Que pouvons-nous améliorer ?

C’est à partir de ces réponses que peut être construit un plan de migration réaliste, maîtrisé et cohérent avec les évolutions futures de votre e-commerce.

Vous envisagez de migrer votre projet Sylius vers Sylius 2 ?

Commencez par identifier les impacts sur votre plateforme avant de lancer les développements.

Nos équipes peuvent auditer votre projet Sylius et vous aider à définir la trajectoire adaptée : migration, évolution, refactoring ou refonte. Demander un diagnostic de votre projet Sylius via le formulaire ci-dessous.

Quand passer d’une solution e-commerce standard à Sylius ?

Quand passer d’une solution e-commerce standard à Sylius ?

Votre solution e-commerce fonctionne, mais vos besoins évoluent. Faut-il continuer à faire évoluer l’existant ou envisager Sylius ?

Il n’existe pas de réponse universelle. Une solution standard reste pertinente lorsque les besoins sont courants, les règles métier simples et l’écosystème technique stable. À l’inverse, Sylius devient particulièrement intéressant lorsque le e-commerce doit porter des règles métier différenciantes, s’intégrer profondément au système d’information ou offrir davantage de maîtrise sur son architecture.

L’enjeu n’est donc pas de savoir si Sylius est « meilleur » qu’une solution standard. Il s’agit de déterminer à quel moment les besoins de l’entreprise justifient un socle plus flexible et plus personnalisable.

à retenir

  • Une solution standard reste pertinente pour des besoins e-commerce courants et peu différenciants.
  • Il n’est pas nécessaire de migrer vers Sylius uniquement parce que l’entreprise grandit.
  • Sylius devient pertinent lorsque les règles métier, les intégrations ou l’architecture deviennent structurantes.
  • La multiplication des contournements et développements spécifiques peut signaler que la plateforme actuelle n’est plus adaptée.
  • Le choix doit prendre en compte le métier, le SI, les performances, le TCO et la roadmap, pas uniquement les fonctionnalités du CMS.
  • Avant une migration, il faut comparer plusieurs trajectoires : optimiser l’existant, moderniser progressivement ou changer de plateforme.

Quand rester sur une solution e-commerce standard ?

Une solution standard peut parfaitement répondre aux besoins d’une entreprise lorsque son modèle commercial reste relativement simple.

Elle est notamment adaptée si :

  • le catalogue et les règles de prix sont standards ;
  • le parcours de commande ne nécessite pas de logique particulière ;
  • les besoins B2B restent limités ;
  • les intégrations avec l’ERP, le PIM ou le CRM sont simples et stables ;
  • les fonctionnalités nécessaires existent nativement ou via des extensions fiables ;
  • les évolutions peuvent être réalisées sans multiplier les développements spécifiques ;
  • la roadmap business reste compatible avec les capacités de la plateforme.

Dans ce contexte, changer de technologie apporterait parfois davantage de complexité que de valeur.

Une migration vers Sylius ne doit donc pas être considérée comme une étape obligatoire de la croissance d’un e-commerce.

Le sujet devient différent lorsque l’entreprise commence à adapter régulièrement son fonctionnement aux contraintes de sa plateforme.

Les premiers signaux qu’il est temps d’étudier Sylius

1. Vos règles métier deviennent un avantage concurrentiel

Votre e-commerce ne se contente plus de vendre un produit au prix affiché. Vous devez gérer, par exemple :

  • des tarifs différents selon les clients ;
  • des catalogues spécifiques ;
  • des comptes professionnels avec plusieurs utilisateurs ;
  • des règles de validation de commande ;
  • des workflows particuliers ;
  • des conditions commerciales négociées ;
  • des règles de disponibilité ou de livraison spécifiques.

Ces règles peuvent être essentielles au fonctionnement de l’entreprise.

Lorsqu’elles deviennent difficiles à implémenter avec les fonctionnalités natives de la plateforme, le problème n’est plus simplement fonctionnel : le socle technique peut commencer à contraindre le modèle commercial.

C’est l’un des contextes dans lesquels Sylius prend tout son intérêt. La plateforme est conçue comme un socle e-commerce flexible et personnalisable, permettant de construire les fonctionnalités nécessaires au projet sans repartir de zéro.

2. Les contournements se multiplient

Un autre signal est plus insidieux : votre site fonctionne, mais de moins en moins naturellement.

  • Une fonctionnalité nécessite un module.
  • Puis un développement spécifique.
  • Puis un second module pour faire fonctionner le premier.
  • Puis un contournement pour répondre à une incompatibilité.

À terme, chaque évolution demande davantage d’analyse, de tests et de maintenance.

Le problème n’est pas forcément le nombre de modules. C’est l’écart qui se creuse entre le fonctionnement attendu par l’entreprise et celui imposé par la plateforme.

Si cette situation vous parle, notre article sur les 10 signes qu’un CMS e-commerce freine votre croissance peut vous aider à objectiver le niveau de friction.

3. Votre e-commerce devient une brique stratégique du SI

Un e-commerce complexe ne fonctionne pas seul. Il doit échanger avec le :

  • ERP ;
  • PIM ;
  • CRM ;
  • WMS ;
  • système de pricing ;
  • gestion des stocks ;
  • outils marketing ;
  • marketplaces ou autres canaux.

Lorsque ces flux deviennent structurants, la question n’est plus seulement « quelles fonctionnalités propose mon CMS ? ».

Elle devient : Quelle place mon e-commerce doit-il occuper dans mon système d’information ?

Une architecture plus ouverte et personnalisable peut alors devenir pertinente.

C’est notamment l’approche mise en œuvre par Cyllene sur le projet Innelec : plateforme B2B basée sur Sylius, architecture API-first et intégrations avec le PIM, le CRM et SAGE.

4. Vous devez maîtriser davantage votre architecture

Certaines entreprises arrivent à un moment où elles veulent davantage de contrôle sur leur plateforme :

  • architecture technique ;
  • données ;
  • règles métier ;
  • évolutions ;
  • intégrations ;
  • performance ;
  • hébergement ;
  • dépendances vis-à-vis d’extensions ou d’éditeurs.

Sylius peut être pertinent dans ce contexte car il fournit un socle e-commerce open source basé sur Symfony, conçu pour être adapté à l’architecture et aux besoins du projet.

Mais cette liberté implique aussi davantage de responsabilités. Sylius n’est donc pas nécessairement le meilleur choix pour une entreprise qui recherche avant tout une solution prête à l’emploi avec un minimum de développement spécifique.

5. Votre roadmap évolue plus vite que votre plateforme

Vous prévoyez :

  • un nouveau modèle B2B ;
  • plusieurs pays ;
  • plusieurs marques ;
  • de nouveaux canaux ;
  • une nouvelle expérience client ;
  • de nouvelles intégrations ;
  • des parcours différents selon les profils.

Et chaque évolution nécessite de vérifier si la plateforme actuelle peut suivre.C’est souvent le véritable déclencheur.

Le bon moment pour étudier Sylius n’est pas lorsque votre plateforme est complètement bloquée. C’est lorsque vous constatez qu’elle risque de le devenir au regard de votre roadmap.

Standard ou Sylius : comment arbitrer ?

Votre situationSolution standardSylius
Besoins e-commerce courants✅ PertinentPossible, mais souvent inutile
Catalogue et prix simples✅ PertinentPossible
Règles métier spécifiques⚠️ À évaluer✅ Pertinent
B2B avec règles commerciales avancées⚠️ Limites possibles✅ Très pertinent
ERP/PIM/CRM fortement intégrés⚠️ À évaluer✅ Pertinent
Nombreux développements spécifiques⚠️ Risque de complexité✅ À étudier
Architecture API-first / headless⚠️ Selon solution✅ Pertinent
Forte maîtrise de l’architecture recherchée⚠️ Variable✅ Pertinent
Projet simple et rapide à déployer✅ Pertinent❌ Souvent disproportionné

Le critère déterminant n’est donc pas la taille de l’entreprise. C’est la complexité du modèle e-commerce et de son environnement.

Faut-il forcément migrer vers Sylius ?

Non. C’est même une question essentielle à se poser avant de lancer un projet de migration.

Trois scénarios peuvent être comparés :

1. Optimiser l’existant
La plateforme répond encore aux besoins et les limites peuvent être corrigées sans remettre en cause l’architecture.

2. Moderniser progressivement
Certaines briques peuvent être refondues ou découplées sans changer immédiatement toute la plateforme.

3. Repenser le socle e-commerce
Les contraintes métier, les intégrations et la roadmap justifient une nouvelle architecture. Sylius peut alors constituer une option pertinente.

Cette logique rejoint l’approche que Cyllene applique dans ses projets de replatforming : analyser l’existant avant de déterminer la trajectoire technique la plus adaptée.

Sylius n’est pas une fin en soi

Choisir Sylius uniquement parce qu’il est plus flexible que votre solution actuelle serait une mauvaise raison.

La question doit plutôt être : Quels besoins notre plateforme actuelle ne nous permet-elle plus de traiter correctement ? 

Puis : Ces besoins justifient-ils réellement une nouvelle architecture ?

C’est cette analyse qui permet d’éviter deux erreurs opposées : rester trop longtemps sur une plateforme qui freine le développement ou migrer vers une solution plus complexe sans besoin réel.

Sur le projet Bollinger, par exemple, le choix de Sylius répondait à des enjeux métier précis : simplification de l’administration, intégration du catalogue, optimisation des processus logistiques et personnalisation des processus métier.

Comment Cyllene vous aide à faire le bon choix ?

Le rôle d’un intégrateur ne devrait pas être de recommander systématiquement la technologie qu’il maîtrise. Il doit d’abord comprendre :

  • votre modèle commercial ;
  • vos règles métier ;
  • votre système d’information ;
  • vos contraintes techniques ;
  • votre roadmap ;
  • vos enjeux UX, SEO et performance ;
  • et le niveau de maîtrise que vous souhaitez conserver sur votre plateforme.

C’est précisément l’approche portée par Cyllene : accompagner des projets e-commerce B2B, B2C ou hybrides, en combinant expertise Sylius, architecture, UX/UI, développement et intégration au SI.

L’équipe Web s’appuie également sur les expertises complémentaires du groupe, qui compte plus de 400 experts dans les métiers du numérique.

L’objectif n’est donc pas de vous convaincre de passer à Sylius, mais de déterminer si Sylius est réellement le bon socle pour votre prochaine étape.

Conclusion

Passer d’une solution e-commerce standard à Sylius devient pertinent lorsque la complexité du métier, du SI ou de la roadmap justifie davantage de liberté architecturale.

Restez sur votre solution actuelle si elle répond efficacement à vos besoins et évolue sans friction excessive.

Envisagez Sylius lorsque les règles métier deviennent différenciantes, que les contournements se multiplient, que les intégrations deviennent structurantes ou que votre plateforme limite vos évolutions.

Le bon choix n’est pas nécessairement de changer de plateforme. C’est de choisir une architecture capable d’accompagner votre stratégie e-commerce.

Checklist migration Sylius : les contrôles à ne pas oublier

checklist-migration-sylius

Migrer un site e-commerce vers Sylius ne consiste pas uniquement à reprendre un catalogue et à refaire le front. Une migration peut impacter le SEO, les données clients, les commandes, les prix, les stocks, les flux ERP/PIM/CRM, le paiement, le tracking et les performances.

Pour éviter les mauvaises surprises au moment de la mise en production, voici les principaux contrôles à prévoir avant, pendant et après une migration Sylius.

à retenir

  • Une migration e-commerce doit couvrir à la fois les données, les flux, les parcours métier et le SEO.
  • Les redirections 301 et la reprise des données ne suffisent pas : il faut tester les échanges avec le SI.
  • La recette doit reproduire les principaux scénarios réels du site.
  • Un plan de rollback et un monitoring post-mise en ligne sont indispensables.
  • Plus le SI est complexe, plus la migration doit être préparée comme un projet d’intégration, et pas comme un simple changement de plateforme.

1. SEO : protéger l’existant avant de migrer

Une migration Sylius peut être l’occasion d’améliorer la structure du site, mais elle peut aussi provoquer une perte de trafic si les fondamentaux SEO ne sont pas anticipés.

Avant la bascule, il faut notamment identifier les pages générant du trafic organique, les pages stratégiques et les principales URLs indexées.

À contrôler :

  • pages indexées et pages générant du trafic ;
  • titles, meta descriptions et H1 ;
  • balises canonical ;
  • sitemap XML et robots.txt ;
  • données structurées lorsque nécessaire ;
  • profondeur des pages et maillage interne.

L’objectif n’est pas nécessairement de conserver chaque élément à l’identique, mais de maîtriser ce qui change.

Pour aller plus loin, consultez notre guide sur la migration e-commerce sans perte SEO.

2. URLs et redirections : préparer le mapping avant la bascule

Si les URLs évoluent avec Sylius, il faut établir un mapping entre les anciennes et les nouvelles URLs.

Les redirections 301 doivent être définies avant la mise en production, puis testées.

Une attention particulière doit être portée aux :

  • fiches produits ;
  • catégories ;
  • pages éditoriales ;
  • anciennes URLs stratégiques ;
  • URLs supprimées ou fusionnées.

Il faut également éviter les chaînes de redirections et les redirections généralisées vers la homepage.

3. Catalogue : ne pas se limiter au nombre de produits

Une reprise catalogue réussie ne signifie pas seulement que “tous les produits sont là”.

Il faut contrôler les produits, variantes, catégories, attributs, médias, statuts, références et éventuelles données spécifiques au métier.

Le contrôle doit également porter sur les règles qui déterminent ce qui est affiché et vendu sur le site.

Dans un environnement connecté à un PIM, il faut notamment tester les flux de création, modification et suppression.

Notre article sur l’intégration de Sylius avec un ERP ou un PIM détaille les principaux points de vigilance.

4. Clients : reprendre les bonnes données

La migration doit définir précisément quelles données clients sont reprises :

  • comptes ;
  • coordonnées ;
  • adresses ;
  • groupes ;
  • données B2B ;
  • historiques utiles ;
  • préférences et consentements selon le périmètre.

La gestion des mots de passe mérite une attention particulière. Selon l’architecture de départ, leur reprise peut nécessiter une stratégie spécifique et un parcours de réactivation.

Pour un site B2B, il faut également tester les comptes sociétés, les rôles utilisateurs et les éventuelles règles d’accès.

5. Commandes : penser historique et nouveaux flux

L’historique des commandes doit être traité selon les besoins métier et les contraintes du projet.

Mais le point le plus important concerne surtout les nouvelles commandes après migration.

Il faut tester le parcours complet : visite → panier → commande → paiement → transmission au SI → préparation → livraison → changement de statut.

Une commande qui fonctionne sur le front mais qui n’est pas correctement transmise à l’ERP constitue évidemment un échec de migration.

6. Prix, promotions et règles commerciales

Le prix affiché doit être contrôlé dans tous les contextes prévus par le projet.

Selon le modèle commercial, cela peut inclure :

  • prix catalogue ;
  • tarifs négociés ;
  • prix par groupe ou compte client ;
  • remises ;
  • promotions ;
  • règles B2B ;
  • prix selon le pays ou le canal.

Pour un modèle B2B/B2C, la recette doit notamment vérifier qu’un même produit peut être proposé selon des conditions commerciales différentes, sans créer de conflit dans les données ou les flux.

7. Stocks et disponibilité

Le stock doit être testé de bout en bout.

Il faut vérifier :

  • la source de vérité du stock ;
  • la fréquence de synchronisation ;
  • les stocks par canal ou entrepôt ;
  • les règles de disponibilité ;
  • les mises à jour après commande ;
  • les cas d’erreur ou de rupture de flux.

Un stock correct dans Sylius mais incorrect dans l’ERP peut rapidement générer des commandes impossibles à honorer.

8. ERP, PIM et CRM : tester les flux, pas seulement les connexions

C’est souvent ici que se situe une grande partie de la complexité d’une migration e-commerce. La présence d’une API ou d’un connecteur ne signifie pas que l’intégration est correctement fonctionnelle.

Pour chaque flux, il faut définir :

source → données transmises → fréquence → transformation → destination → retour éventuel

Les principaux flux peuvent concerner les produits, prix, stocks, clients, commandes, factures, statuts ou données marketing.

Dans une architecture API-first, cette cartographie devient particulièrement importante car le e-commerce peut jouer le rôle de moteur connecté à plusieurs briques du SI.

9. Paiement et livraison

Chaque moyen de paiement doit être testé dans les principaux scénarios :

  • paiement accepté ;
  • paiement refusé ;
  • abandon ;
  • remboursement ;
  • retour de statut ;
  • erreur technique.

Même logique pour la livraison : zones, tarifs, transporteurs, règles de disponibilité et statuts doivent être vérifiés.

Une migration n’est réellement validée que lorsque le parcours transactionnel complet fonctionne.

10. Tracking et analytics

Le changement de plateforme peut casser une partie du tracking existant. Avant la mise en ligne, il faut inventorier puis tester :

  • Analytics ;
  • Google Tag Manager ;
  • événements ;
  • conversions ;
  • campagnes ;
  • pixels publicitaires ;
  • consentement ;
  • remontées e-commerce.

Il est également utile de comparer les données avant et après migration afin d’identifier rapidement une rupture de mesure.

11. Performance

Une migration vers Sylius doit aussi être l’occasion de vérifier les performances réelles du site. À mesurer notamment :

  • temps de réponse serveur ;
  • Core Web Vitals ;
  • temps de chargement des pages clés ;
  • performances du panier et du checkout ;
  • comportement lors des pics de trafic ;
  • charge générée par les appels aux systèmes externes.

La performance doit être testée dans des conditions représentatives, et pas uniquement sur une page isolée.

12. Sécurité

Avant la mise en production, contrôler notamment :

  • droits et rôles ;
  • accès aux environnements ;
  • secrets et clés API ;
  • certificats ;
  • sauvegardes ;
  • dépendances ;
  • exposition des interfaces ;
  • journalisation et monitoring.

Une migration est aussi un bon moment pour supprimer les anciens accès et composants devenus inutiles.

13. Recette : tester des parcours, pas uniquement des fonctionnalités

La recette doit reproduire les usages réels. Par exemple, plutôt que de tester séparément “ajouter au panier” et “payer”, il est préférable de tester un scénario complet :

un client B2B se connecte → consulte son catalogue → bénéficie de son tarif → commande → paie → la commande est transmise à l’ERP.

Les scénarios doivent couvrir les différents profils, pays, canaux et règles métier réellement utilisés.

14. Monitoring et rollback : prévoir l’après-migration

La migration ne s’arrête pas au moment où le site devient accessible. Les premiers jours doivent faire l’objet d’une surveillance renforcée :

  • erreurs 404 ;
  • erreurs serveur ;
  • commandes ;
  • paiements ;
  • flux ERP/PIM/CRM ;
  • trafic ;
  • indexation ;
  • performances.

Et surtout, un plan de rollback doit être défini avant la bascule : qui décide, dans quelles conditions et selon quelle procédure revenir à l’environnement précédent ?

La checklist migration Sylius à télécharger

Ces 20 contrôles constituent un socle pour préparer une migration e-commerce vers Sylius. Pour ne rien oublier, nous avons regroupé les principaux points de contrôle dans une checklist migration Sylius téléchargeable : SEO, URLs, catalogue, clients, commandes, prix, stocks, ERP, PIM, CRM, paiement, livraison, tracking, performance, sécurité, recette, monitoring et rollback.

Une migration Sylius est aussi un projet d’intégration

Plus un e-commerce est connecté à son système d’information, plus la migration dépasse le simple changement de plateforme.

Le véritable enjeu consiste à préserver les données, les règles commerciales, les parcours clients et les flux qui font fonctionner le commerce au quotidien.

C’est notamment le cas des projets B2B ou B2B/B2C combinant ERP, PIM, CRM, règles tarifaires, stocks et processus métier spécifiques.

Chez Cyllene, cette approche s’inscrit dans une expertise Sylius dédiée aux projets e-commerce complexes, avec des compétences Web, architecture, développement, DevOps et production.

Besoin d’évaluer votre projet de migration ? Notre équipe peut réaliser un premier diagnostic de votre architecture, de vos flux et des principaux risques de migration.

Découvrez notre réalisation B2B sous Sylius : Projet Innelec

Migration e-commerce sans perte SEO : la méthode pour sécuriser une migration (exemple vers Sylius)

migration sylius conservation SEO

Une migration e-commerce peut améliorer les performances, l’expérience client et l’agilité d’un site. Mais sans préparation SEO, elle peut aussi entraîner une perte de trafic organique, de positions et de chiffre d’affaires. Découvrez la méthode pour sécuriser chaque étape d’une migration, avec Sylius comme exemple de plateforme cible.

Changer de CMS, refondre son site ou faire évoluer son architecture e-commerce est un projet stratégique.

Le problème ? Une grande partie de la valeur d’un site ne se trouve pas uniquement dans sa technologie. Elle est aussi dans ses URL, ses contenus, ses backlinks, son historique d’indexation et son trafic organique.

Une migration réussie doit donc préserver cet actif tout en permettant au nouveau site de progresser.

Point essentiel

Le SEO d’une migration e-commerce ne doit pas être traité au moment de la recette. Il doit être intégré dès la conception du projet.

À retenir

  • Changer de CMS ne provoque pas automatiquement une perte de référencement.
  • Le principal risque vient des changements d’URL, des redirections incomplètes et des problèmes d’indexation.
  • L’ancien site doit être entièrement cartographié avant de construire le nouveau.
  • Le plan de redirection 301 doit être préparé et testé avant la mise en production.
  • Le staging doit faire l’objet d’une véritable recette SEO.
  • Après la mise en ligne, le suivi doit continuer pendant plusieurs semaines.

Pourquoi une migration e-commerce peut-elle faire perdre du SEO ?

Le changement de technologie n’est pas, en lui-même, un problème pour les moteurs de recherche.

Les difficultés apparaissent lorsque la migration modifie sans contrôle les signaux qui permettent de comprendre, explorer et positionner le site. Par exemple :

  • les performances se dégradent.nt une mauvaise migration SEO.
  • les URL changent ;
  • des pages disparaissent ;
  • l’arborescence est modifiée ;
  • les balises Title et Hn évoluent ;
  • le maillage interne est reconstruit ;
  • les balises canonical changent ;
  • certaines pages deviennent non indexables ;
  • les données structurées disparaissent ;

Prenons l’exemple d’une fiche produit :

Avant migration : /chaussures-homme/basket-mode-123.html

Après migration : /chaussures-homme/baskets/basket-mode/

Si l’ancienne URL disparaît sans redirection pertinente, le moteur de recherche doit retrouver et réévaluer la nouvelle page.

À l’échelle de quelques URL, le problème peut sembler limité.

À l’échelle de 50 000, 100 000 ou plusieurs centaines de milliers d’URL, l’enjeu devient stratégique.

La méthode en 5 phases pour réussir une migration e-commerce sans perte SEO

Phase 1 — Cartographier votre patrimoine SEO

La première erreur consiste à commencer par le nouveau site. Avant de développer, il faut comprendre ce que l’ancien site a accumulé.

Commencez par crawler l’ensemble des URL existantes :

  • produits ;
  • catégories ;
  • sous-catégories ;
  • pages éditoriales ;
  • articles ;
  • pages de marques ;
  • filtres et facettes ;
  • landing pages ;
  • anciennes pages commerciales.

Mais connaître les URL ne suffit pas. Il faut également identifier celles qui ont une véritable valeur.

Croisez notamment :

  • les données de Google Search Console ;
  • les données Analytics ;
  • les données commerciales ;
  • les backlinks ;
  • les données de crawl.

Une page peut avoir peu de trafic mais disposer de nombreux backlinks. À l’inverse, une page peut générer beaucoup de chiffre d’affaires sans être particulièrement visible dans les moteurs..

Notre recommandation : classer les URL en P1, P2 et P3

P1 — Protection absolueFort trafic, fort chiffre d’affaires, nombreux backlinks ou forte valeur stratégique.
P2 — Conservation recommandéeTrafic organique régulier ou valeur éditoriale.
P3 — À analyserFaible trafic, contenu obsolète ou URL sans valeur clairement identifiée.

Cette classification permet aussi de décider quelles pages doivent être conservées, fusionnées, supprimées ou redirigées.

Phase 2 — Construire un plan de redirection 301 exhaustif

Le plan de redirection est probablement le document le plus important d’une migration SEO.

REGLE A RETENIR

Une ancienne URL doit avoir une nouvelle destination pertinente lorsqu’elle conserve une valeur SEO ou commerciale. Il faut conserver autant que possible la pertinence sémantique et commerciale.

L’erreur classique : tout rediriger vers la homepage 

Google recommande de préparer un mappage entre les anciennes et les nouvelles URL, puis de mettre en place des redirections permanentes vers les destinations correspondantes.

Définition

Une redirection 301, c’est quoi ?

Une redirection 301 indique qu’une URL a été déplacée définitivement vers une autre URL.

ancienne-url-produit → nouvelle-url-produit

Elle permet d’accompagner les utilisateurs et les moteurs de recherche vers la nouvelle adresse.

Trois règles à respecter :

1. Éviter les chaînes

Mauvais : URL A → URL B → URL C

Préférable : URL A → URL C

2. Éviter les boucles

URL A → URL B → URL A

Une telle configuration doit être détectée avant la mise en production.

Traiter les pages supprimées au cas par cas

Un ancien produit peut avoir un équivalent, une nouvelle catégorie peut remplacer une ancienne catégorie, mais certaines pages peuvent aussi ne plus avoir de destination pertinente.

Le plan doit également prendre en compte les filtres, les anciennes campagnes, la pagination et les catégories fusionnées.

Phase 3 — Recetter le nouveau site en pré-production

Le staging ne sert pas uniquement à vérifier que le site fonctionne.

Il doit permettre de vérifier que le futur site conserve les fondamentaux SEO de l’ancien tout en apportant les améliorations attendues.

Indexation

Vérifiez :

  • protection du staging ;
  • noindex ;
  • robots.txt ;
  • absence d’URL staging indexées.

SEO on-page

Contrôlez :

  • Titles ;
  • meta descriptions ;
  • H1 et structure Hn ;
  • canonical ;
  • URLs ;
  • contenus stratégiques.

Architecture

Testez :

  • navigation ;
  • maillage interne ;
  • breadcrumbs ;
  • profondeur des pages ;
  • pages orphelines ;
  • liens cassés.

E-commerce

Le SEO ne doit jamais être testé séparément du business.

Il faut également valider :

  • catalogue ;
  • prix ;
  • stocks ;
  • recherche ;
  • filtres ;
  • panier ;
  • tunnel de commande ;
  • paiement.

Données structurées

Pour un site e-commerce, contrôlez notamment :

  • Product ;
  • Offer ;
  • Breadcrumb ;
  • Organization ;
  • Prix ;
  • Disponibilité.

Le staging doit reproduire le plus fidèlement possible le comportement du futur site afin que les problèmes soient détectés avant la mise en production. C’est l’environnement dans lequel la future plateforme doit être auditée avant sa mise en production.

Phase 4 — Organiser une bascule e-commerce sans rupture

Le jour J ne doit pas être improvisé. Il doit être préparé comme une opération critique.

Avant la bascule

À valider :

  • sauvegarde complète ;
  • dernière synchronisation des données ;
  • freeze des développements ;
  • validation du mapping URL ;
  • validation du plan 301 ;
  • validation des flux ;
  • validation du tracking ;
  • décision Go/No-Go.

Pendant la bascule

Contrôlez notamment :

  • déploiement de la nouvelle plateforme ;
  • activation des redirections ;
  • HTTPS ;
  • DNS ;
  • robots.txt ;
  • sitemap ;
  • accès aux principales pages ;
  • panier ;
  • paiement ;
  • confirmation de commande ;
  • tracking.

Dans les premières heures

Les premières vérifications doivent porter sur les pages les plus critiques. Commencez par :

  1. la homepage ;
  2. les principales catégories ;
  3. les pages SEO prioritaires ;
  4. les produits stratégiques ;
  5. le panier ;
  6. le tunnel de commande ;
  7. le paiement ;
  8. les principales anciennes URL ;
  9. le tracking ;
  10. les erreurs serveur.

Phase 5 — Monitorer le site pendant 30 jours

Une migration ne se termine pas lorsque le nouveau site est accessible. C’est à ce moment que commence la phase de surveillance.

De J+1 à J+7

Surveillez quotidiennement :

  • erreurs 404 ;
  • erreurs 500 ;
  • pages non indexées ;
  • couverture d’indexation ;
  • trafic organique ;
  • positions ;
  • logs Googlebot ;
  • performances ;
  • conversions ;
  • chiffre d’affaires.

De J+7 à J+30

Analysez les tendances :

  • évolution des positions ;
  • évolution du trafic ;
  • pages stratégiques ;
  • évolution des conversions ;
  • crawl des robots ;
  • nouveaux problèmes d’indexation ;
  • évolution des erreurs 404.

L’objectif n’est pas uniquement de constater une éventuelle baisse. Il faut être capable de relier une anomalie à une cause technique ou éditoriale précise.

Exemple : une migration vers Sylius

Prenons maintenant un cas concret. Une entreprise dispose d’un site e-commerce devenu difficile à faire évoluer. Elle décide de profiter de sa refonte pour adopter Sylius comme nouvelle plateforme.

Le principe reste exactement le même que pour toute autre migration. Il faut d’abord préserver le patrimoine SEO existant, puis reconstruire l’architecture cible.

L’intérêt d’une plateforme comme Sylius peut apparaître lorsque le projet nécessite davantage de flexibilité :

  • règles métier spécifiques ;
  • besoins B2B ;
  • catalogue complexe ;
  • nombreuses intégrations ;
  • architecture personnalisée ;
  • plusieurs canaux ;
  • évolutions importantes de la plateforme.

Mais le choix de Sylius ne remplace pas le travail SEO.

Les URL doivent toujours être définies.
Les redirections doivent toujours être préparées.
Le maillage doit toujours être testé.
Les données structurées doivent toujours être contrôlées.
Le nouveau site doit toujours être monitoré après son lancement.

Les 10 erreurs qui peuvent coûter cher lors d’une migration

ErreurRisque principal
Ne pas crawler l’ancien siteURL oubliées
Préparer les 301 trop tardMapping incomplet
Rediriger vers la homepagePerte de pertinence
Supprimer massivement des URLPerte de longue traîne
Indexer le stagingMauvaise indexation
Modifier le maillage sans analysePerte de popularité interne
Oublier les canonicalSignaux contradictoires
Négliger les performancesDégradation de l’expérience
Oublier le trackingPerte de visibilité business
Arrêter le monitoring trop tôtCorrections tardives

Une migration e-commerce est aussi l’occasion de repenser son architecture

Une migration ne consiste pas seulement à déplacer un site d’une plateforme à une autre. Elle permet aussi de prendre du recul sur son architecture e-commerce et de se poser une question essentielle : la plateforme actuelle est-elle encore adaptée aux ambitions de l’entreprise ?

Si votre CMS répond toujours efficacement à vos besoins, une migration n’est pas forcément nécessaire. En revanche, si les évolutions deviennent complexes, que les développements spécifiques se multiplient ou que la plateforme limite vos projets, la migration peut être l’occasion de repartir sur un socle plus évolutif.

Et dans certains projets, cette réflexion conduit également à envisager une architecture headless commerce, qui permet de découpler le front-end de la plateforme e-commerce pour gagner en liberté sur les expériences digitales et les différents canaux.

Avant de choisir une nouvelle solution, commencez donc par identifier les limites de l’existante.

Chez Cyllene, nous accompagnons les entreprises dans ces transformations e-commerce, de l’analyse de l’existant au choix d’architecture, jusqu’à la migration et à la mise en production. L’objectif : construire une plateforme qui réponde aux enjeux d’aujourd’hui, mais surtout à ceux de demain.

Anticipez la Fin de Support Microsoft Exchange

Les clés pour une migration réussie

La fin du support de Microsoft Exchange 2016/2019 approche :

Microsoft mettra fin au support d’Exchange 2016 et 2019 le 14 octobre 2025, mettant ainsi un terme aux mises à jour et à l’assistance. Cette échéance soulève d’importants défis de migration.

 

Quelles sont les conséquences ?

L’arrêt des mises à jour et correctifs de sécurité expose les systèmes à des vulnérabilités critiques. Les entreprises risquent des cyberattaques, des fuites de données et des interruptions de service. De plus, l’absence de support technique peut entraîner des pannes majeures qui affecteront la continuité des activités.

 

Pourquoi ne pas attendre la version Exchange SE ?

L’un des arguments courants est de reporter la migration en attendant la prochaine version de Microsoft Exchange Server (SE). Cependant, il est important de comprendre que :

 

– La migration directe d’Exchange 2016 vers Microsoft SE est impossible.

 

– Le passage d’Exchange 2019 vers Exchange SE se fera par une simple mise à jour Inplace.

 

Cela signifie que les entreprises qui restent sur Exchange 2016 devront passer par Exchange 2019 avant d’accéder à Exchange SE.

 

Cyllene votre expert en migration Exchange vous propose une gamme complète de solutions pour vous accompagner dans ces transitions critiques :

– Migration d’Exchange 2016 Hybrid : Mise à niveau des serveurs hybrides.

 

– Migration de Exchange 2016 vers 2019 : Une migration on-premise préparant le passage à Exchange SE.

 

– Migration de Exchange 2016/2019 vers Office 365 : Nous vous accompagnons vers une infrastructure hybride Office 365.

 

En plus des migrations, Cyllene propose des services supplémentaires en Sauvegarde, Supervision, Hébergement, Antispam, OSM des serveurs Exchange.

 

Ne prenez pas de risques inutiles. Anticipez dès maintenant la fin du support de Microsoft Exchange et assurez-vous une migration fluide et sécurisée !

GA4 : Pourquoi faire votre migration

Des mois que tout le monde en parle : le 1er Juillet 2023 signera la fin de Google Analytics Universal. Plus aucune donnée ne sera collectée à partir de cette date. Si vous voulez conserver votre outil de mesure de votre site Web, il vous faudra migrer vers une autre solution Analytics : Google Analytics 4 (GA4) ou une autre solution du marché.

1. Migration vers GA4

Notez que GA4 n’intègre pas vos données historiques Universal (qui resteront disponibles jusqu’au 31/12/2023). Si vous ne l’avez pas encore fait, il devient donc urgent de passer sur cette nouvelle propriété afin de vous constituer un historique de données comparatives à N-1.

Comment migrer de GA Universal à GA 4?

Google propose de faire la bascule automatiquement :

Le 1er juillet 2023, cette propriété cessera de traiter des données. A partir de mars 2023, vous devrez créer une propriété Google Analytics 4 (GA4) pour ne pas interrompre la mesure de votre site web. Si vous ne le faites pas, elle sera créée pour vous d’après votre propriété d’origine, en réutilisant les balises existantes du site.

Google

Attention cependant, les données ne seront que partiellement migrées : vos audiences, vos objectifs, les associations types Google Ads, etc. devront être redéfinis.

Contrairement à Google Universal qui s’appuyait sur un modèle de données orienté sur les sessions (interactions d’utilisateurs sur un site web dans un temps limité), GA4 nécessite le paramétrage d’évènements (actions réalisées sur le site ou l’application : clics, scroll, pages vues etc.)

Google Analytics 4 propose de nombreuses options de personnalisation des rapports. Son interface peut parfois être déstabilisante et retrouver ou exploiter correctement ses données peut vite s’avérer complexe.

GA 4 est une version entièrement nouvelle de Google Analytics, bien distincte de la précédente. Il faut l’appréhender comme un produit à part entière. C’est pourquoi il est fortement conseillé de vous faire accompagner dans votre projet de migration.

2. Migration vers une solution alternative à GA4

Google Analytics est actuellement incompatible avec les exigences RGPD et les directives de la CNIL :

  • Transferts des données vers les Etats-Unis pointés par la CNIL : la majorité des déploiements GA4 actuels ne sont donc pas conformes.
  • La version Web de Google Analytics par défaut ne respecte pas la RGPD : des ajustements sont nécessaires pour l’utiliser.

Des alternatives existent : Matomo (anciennement Piwik), Piano (AT Internet), Eulerian …

Contrairement à Google, ces solutions sont légalement exemptées de consentement par la CNIL. Vous affranchir de l’obtention du consentement vous permet de maximiser votre collecte de données relatives à la mesure d’audience.

Vous vous interrogez sur l’intérêt de conserver l’environnement Google à long terme et souhaitez un accompagnement pour migrer sur un outil exempt de consentement ? Nos équipes peuvent vous conseiller.

3. Comment réaliser sa migration ?

Quelle que soit la solution choisie, nos experts Cyllene vous proposent un accompagnement en plusieurs étapes :

  • Atelier
  • Définition de vos besoins Analytics : que voulez-vous mesurer ?
  • Définition de vos KPI prioritaires et les événements que vous souhaitez suivre dans la durée
  • Paramétrage du Tag Manager : création d’un plan de tags et déploiement sur l’outil
  • Création et paramétrage de votre propriété Google Analytics 4 (GA4) ou autre solution
  • Optionnel : réalisation de Dashboard afin de retrouver plus facilement et exploiter vos données

Pour aller plus loin : Des questions sur la configuration de vos outils en mode Server-Side, sujet phare de 2023 ? Nous sommes là pour échanger !

Racontez-nous une histoire


























    Les réponses aux rubriques « civilité », « nom », « prénom », « email professionnel » et « numéro de téléphone » sont obligatoires et nécessaires pour traiter vos demandes de contact et d’information. Les réponses aux autres rubriques sont facultatives.
    Les informations collectées sont traitées conformément à la Politique de confidentialité
    .

    *Conformément à la loi n° 78-17 du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés telle que modifiée, et au Règlement (UE) 2016/679 du Parlement Européen et du Conseil du 27 avril 2016, vous pouvez exercer votre droit d’accès, de rectification, d’opposition, d’effacement et de portabilité en envoyant une demande écrite accompagnée d’un justificatif d’identité valide à dpo@groupe-cyllene.com ou DPO – CYLLENE – 93/99, rue Veuve Lacroix 92000 Nanterre.