La terminologie peut prêter à confusion : le passage vers Magento 2 se traduit plus par un changement de technologie qu’une migration vers une nouvelle version. Cette transition, devenue indispensable à l’heure où Adobe abandonne la maintenance sur M1, représente un réel défi technique et organisationnel pour les agences et e-commerçants qui veulent se mettre à jour. Petit tour d’horizon des principaux pièges à éviter.
Repousser l’échéance de la migration
Votre site a été créé il y a des années, il a vécu des jours heureux et vous avez donc des réticences à changer de plateforme. Cette crainte est légitime : la montée en version 2.x représente un effort conséquent. Aucun expert Magento ne vous dira que ce passage se fait en un claquement de doigts !
La réponse à cette interrogation est malheureusement toujours la même : vous n’avez plus le choix. En effet, Magento a abandonné la maintenance applicative de sa version 1.x depuis Juin 2020. Failles de sécurité, incompatibilité avec des nouvelles technos, problématiques de performance, d’évolutivité… Maintenir un Magento 1 sera de plus en plus risqué et coûteux, malgré les initiatives communautaires tel qu’OpenMage LTS.
De plus, les investissements que vous continuez à faire sur votre Magento 1 seront perdus quand le glas de la migration sonnera. Toutes les surcharges de code, les modules installés, les intégrations de style, etc. seront à refaire lors du passage vers M2. Autant s’y mettre le plus tôt possible afin de limiter l’accumulation de développements spécifiques !
La question inévitable continue de tracasser les e-commerçants sous Magento 1 : “À quel moment dois-je migrer vers Magento 2 ?”
La réponse simpliste serait “Migrez dès maintenant !”. La réponse éclairée serait plutôt “Commencez dès maintenant !”. On vous explique pourquoi dans la suite de l’article.
Viser une MVP isopérimètre : une utopie
Vous avez franchi le pas et décidez de migrer vers Magento 2, hourra ! Une rapide consultation des nouveautés sur Magento 2 vous mettent l’eau à la bouche : stack technique plus moderne, amélioration des performances, nombreuses fonctionnalités marketing & SEO, nouvelle interface backoffice… Ces promesses sont tenues, mais elles ne concernent que l’amélioration de la version native de Magento !
Depuis sa création, votre site sous M1 a évolué, des modules communautaires ont enrichi votre panoplie fonctionnelle, des développements spécifiques ont optimisé des comportements natifs, des services extérieurs ont étoffé le noyau Magento. Tel un orfèvre qui sculpte son diamant avec minutie et patience, vous avez peaufiné votre M1 pendant ses années de vie.
Oui, l’objectif est de conserver toute cette expérience lors d’une migration vers M2, mais pas pour la version MVP ! De nombreux projets de migration vers Magento 2 aboutissent tardivement par volonté de conserver le même périmètre fonctionnel alors qu’il a mis des années à être construit sur Magento 1.
Se lancer sans cahier des charges : le risque de régression
Viser une version isopérimètre sur Magento 2 est un moyen de diminuer la charge de conception et de rédaction d’un cahier des charges. Le process est de partir du périmètre fonctionnel sur Magento 1 pour construire celui sur Magento 2. Cette méthodologie a néanmoins une contrainte et non des moindres : construire un backlog à partir du code de Magento 1 est extrêmement complexe car il ne va pas être exhaustif ! En fonction des surcharges de code, des modules communautaires installés mais plus utilisés, des configurations dans le backoffice et du code legacy, il est parfois difficile de déterminer à l’avance la provenance d’un comportement. Par exemple, deux modules différents A et B peuvent surcharger la même fonctionnalité native d’ajout au panier. Sans entrer dans le détail du code de chaque module, il est impossible de démêler ce qui est natif, ce qui est relatif au module A et ce qui est relatif au module B. Un cahier des charges permet d’exprimer un résultat attendu, alors que la lecture du code va exprimer un résultat potentiel.
“La migration des données est facile”
La migration des données est facilitée par le module Data Migration Tools de Magento. Bien qu’elle simplifie le match de la structure des tables entre M1 et M2, ce module ne fait pas tout ! Bon nombre de cas de figure ne seront pas pris en compte dans cet outil :
-
Développement spécifique sur la gestion du catalogue, des clients et des commandes
-
Modules communautaires qui ajoutent des tables à la base de données
-
Types de contenus éditoriaux (Actualités, Blog, Lookbook, etc)
Cette liste est non-exhaustive et dépend surtout des évolutions qu’a connu votre Magento natif. Elle montre néanmoins les précautions à prendre avant de centraliser toute la migration data via Data Migration Tools.
API, synchronisations et services externes : les éternels oubliés
Bien que Magento 2 soit livré avec un arsenal fonctionnel très complet, des services et outils complémentaires vont venir compléter votre écosystème de vente. Entre les outils de tracking, les plans de taggage, les API ouvertes et consommées, les imports de catalogue depuis un PIM, les flux catalogue pour les marketplaces, les exports des commandes pour l’ERP, les services de marketing automation… vous avez construit pendant des années un système complexe, interdépendant et difficile à cartographier.
Partir sur un projet de migration sans matérialiser l’ensemble des connexions, flux et interfaces peut provoquer de mauvaises surprises ! De plus, si les intervenants se sont succédés, les développements n’ont pas été archivés et la vision macro de ces systèmes gravitant autour de Magento n’est pas maîtrisée, les déboires semblent inévitables !
Rassurez-vous, tous ces pièges sont faciles à contourner quand on est bien entouré. Prenez contact avec notre équipe en envoyant un mail à hello@bird.eu afin d’échanger sur votre projet de migration. A l’instar du merle noir qui représente Blackbird, nous vous aiderons à migrer avec coordination et Agilité (et en formation en « V ») vers les contrées chaleureuses de Magento 2 !
