Votre site Magento tourne, les commandes rentrent, et pourtant la question revient à chaque comité de direction : jusqu'à quand ? Faut-il rester, monter de version, ou changer de plateforme ?
Ce guide ne vend pas la migration. Il pose les éléments qui permettent de décider : où en est réellement Magento aujourd'hui, ce que coûte le fait de rester, ce qu'un changement de plateforme implique concrètement, et vers quoi migrer une fois la décision prise. Nous maintenons des Magento et nous en avons migré vers Sylius : nous dirons donc aussi, à la fin, pourquoi Sylius est notre réponse par défaut, et dans quels cas ce n'en est pas une.
Où en est Magento aujourd'hui ?
Avant de parler méthode et budget, il faut regarder le calendrier. Une migration se déclenche rarement parce qu'on en a envie : elle se déclenche parce qu'une date approche.
Magento 1 : le sujet est clos
Le support de Magento 1 s'est arrêté le 30 juin 2020. Un site encore sous Magento 1 aujourd'hui n'a plus reçu de correctif de sécurité officiel depuis six ans. Ce n'est plus un débat de plateforme : c'est un sujet de conformité, notamment vis-à-vis de PCI DSS, et un sujet d'assurance. Les correctifs communautaires et les pare-feu applicatifs permettent de tenir, pas de durer.
Si c'est votre situation, nous avons détaillé les options qui restent dans notre article sur la fin de vie de Magento 1.
Magento 2 : le calendrier se resserre
C'est le point que beaucoup de marchands sous-estiment. Passer sur Magento 2 n'a pas mis fin au sujet : chaque ligne de version a sa propre date de fin de support, et elles tombent vite. D'après la politique de cycle de vie publiée par Adobe :
- les versions 2.4.3 et antérieures sont hors support depuis novembre 2022 ;
- 2.4.4 : support standard terminé le 12 avril 2025, support étendu terminé le 14 avril 2026 ;
- 2.4.5 : support standard terminé le 12 août 2025, support étendu jusqu'au 11 août 2026 ;
- 2.4.6 : support jusqu'au 11 août 2026 ;
- 2.4.7 : support jusqu'au 9 avril 2027 ;
- 2.4.8 : support jusqu'au 11 avril 2028 ;
- 2.4.9, sortie le 12 mai 2026 : support jusqu'en mai 2029.
Traduction concrète : si vous êtes en 2.4.6 ou en dessous, vous êtes déjà dans la fenêtre de décision. Et même en 2.4.7, vous avez moins de deux ans avant de devoir remettre au budget une montée de version. Le rythme est d'environ une migration technique tous les deux ans, indéfiniment.
Adobe pousse vers le cloud et le SaaS
Adobe a étoffé son offre avec des produits gérés en SaaS, Adobe Commerce as a Cloud Service et Adobe Commerce Optimizer, où l'infrastructure et les mises à jour sont prises en charge par Adobe. Magento Open Source, la version auto-hébergée et gratuite, reste distribuée à part.
Notre lecture, et c'est une lecture et pas un fait : l'énergie de la feuille de route va désormais vers le cloud propriétaire, pas vers la version open source auto-hébergée. Si votre choix initial de Magento reposait sur l'argument open source et sur l'indépendance vis-à-vis d'un éditeur, il est légitime de se demander si cet argument tient encore.
Rester sur Magento est une décision, pas une absence de décision
Ne rien faire coûte quelque chose : des montées de version régulières, des extensions tierces à racheter ou à adapter à chaque fois, des développeurs Magento de plus en plus rares et de plus en plus chers. C'est un choix défendable, à condition de le budgéter comme un choix. C'est d'ailleurs ce que nous faisons pour plusieurs clients au sein de notre tierce maintenance applicative : maintenir un Magento proprement, en attendant le bon moment pour bouger.
Mettre à jour ou migrer : trancher avant de chiffrer
C'est la première bifurcation, et c'est celle sur laquelle on perd le plus de temps quand on la traite en dernier. Une montée de version et un changement de plateforme ne se comparent pas sur le seul devis initial : ils se comparent sur trois ans.
Vous venez de loin
Magento est une solution extrêmement complète, qui profite d'une quantité de modules incroyable. Le problème, c'est que ces modules ne sont pas toujours bien développés, et que Magento embarque beaucoup de fonctionnalités que les marchands n'utilisent jamais. Le résultat est un Magento lent, avec une surface de code à maintenir sans rapport avec ce que vous exploitez vraiment.
Beaucoup de marchands ont fait ce chemin il y a une dizaine d'années et se retrouvent aujourd'hui avec dix ans de développements spécifiques empilés, dont personne dans l'entreprise ne connaît plus la raison d'être. C'est ce patrimoine, plus que la plateforme elle-même, qui rend l'arbitrage difficile.
Magento 2 est déjà un changement de plateforme
Quand il s'agit de repartir sur une base plus saine, on pense d'abord à Magento 2. C'est la suite logique : après la version 1, on passe à la version 2. On se dit aussi que ce sera moins compliqué que d'aller ailleurs.
Sauf que Magento 2 est un changement de plateforme complet. La logique applicative reste la même, le back-office ressemble à ce que vous connaissez, on y retrouve les mêmes principes et les mêmes fonctionnalités. Mais le code est très différent : pour reprendre un développement spécifique de Magento 1, il faut le réécrire. Et le coût de cette réécriture dépasse souvent le coût initial du développement.
Pourquoi ? Parce que tout a changé. Magento 2 est plus complexe, et les développeurs sont plus difficiles à trouver : ils sont attirés par les autres solutions e-commerce qui existent, et ils demandent des salaires plus importants qu'avant. En bref, tout coûte plus cher.
Autrement dit : si vous acceptez de repayer une réécriture, autant vous demander vers quoi vous voulez réécrire.
Les signaux qui font pencher vers la migration
- Des extensions critiques abandonnées par leur éditeur, ou bloquées sur une version de PHP ancienne.
- Un coût de maintenance annuel qui a rejoint, ou dépassé, le coût d'un projet neuf sur trois ans.
- Des délais de recrutement ou de prestation qui s'allongent parce que le vivier Magento se réduit.
- Un back-office que vos équipes contournent avec des tableurs, parce qu'il ne correspond pas à vos opérations.
- Une feuille de route commerciale bloquée : le projet qui rapporterait est toujours celui qui est trop cher à faire sur la plateforme actuelle.
- Des performances que vous ne parvenez plus à améliorer sans surdimensionner l'hébergement.
Les signaux qui disent de rester
Ils existent, et il faut les dire aussi. Restez et montez de version si votre Magento est déjà en 2.4.7 ou plus, si votre catalogue et vos process sont simples, si vous avez peu de spécifiques, si vos extensions sont maintenues, et si vous disposez d'une équipe interne qui connaît la plateforme. Dans ce cas, une migration vous coûterait plus cher qu'elle ne vous rapporterait.
Une règle simple : migrer coûte toujours plus cher qu'une montée de version à l'instant T. Ce qui justifie une migration, ce n'est jamais le coût du projet, c'est le coût cumulé de tout ce qui vient après.
Ce qu'une migration Magento implique vraiment
La première chose à faire n'est pas de choisir la plateforme d'arrivée. C'est de lister ce qui doit survivre au déménagement. Tant que cette liste n'existe pas, tous les devis que vous recevrez seront faux, y compris le nôtre.
Commencez par vos fonctionnalités critiques
Listez, noir sur blanc, ce sans quoi votre business s'arrête :
- la connexion à votre ERP ;
- la connexion à votre outil d'emailing ;
- l'import et la mise à jour de vos produits ;
- la récupération de vos clients ;
- les modes de paiement disponibles ;
- les transporteurs et les tarifs de frais de port ;
- vos règles de promotion et de fidélité ;
- vos flux marketplaces et comparateurs.
Réfléchissez aussi à l'usage réel que vous avez de votre back-office, aux opérations de picking et à votre logistique. Certains de nos clients ont un back-office extrêmement personnalisé, sous Magento comme sous Sylius : c'est souvent là, et pas sur la boutique, que se trouve la vraie complexité d'un projet.
Le catalogue et vos attributs personnalisés
La migration du catalogue natif Magento va généralement vite : produits simples, configurables, catégories, images, prix. Ce qui coûte, ce sont les attributs personnalisés accumulés au fil des ans, les jeux d'attributs incohérents entre familles de produits, et les valeurs saisies à la main dans des champs prévus pour autre chose.
Une migration est le seul moment où il est politiquement possible de faire le ménage dans un catalogue. Profitez-en : chaque attribut que vous ne reprenez pas est un attribut que vous ne maintenez plus.
Les clients, les adresses et les mots de passe
Les comptes clients et les adresses se reprennent bien, surtout si vous êtes resté proche du natif. Le point d'attention est le mot de passe : selon l'algorithme de hachage utilisé par votre version de Magento et selon la plateforme d'arrivée, les mots de passe sont parfois reprenables tels quels, parfois non. Dans le second cas, il faut prévoir une réinitialisation de masse, donc une campagne d'e-mails, donc un pic de sollicitation du service client le jour de la bascule. Cela se prépare, cela ne s'improvise pas le week-end de la mise en ligne.
L'historique de commandes : migrer ou archiver ?
Les commandes ? On les importe seulement si c'est vraiment nécessaire. Si l'objectif est simplement de donner à vos clients un historique consultable, il est souvent plus économique de conserver l'ancienne base de données en lecture seule et d'afficher le strict nécessaire dans le compte client.
Migrer dix ans de commandes, avec les statuts, les avoirs, les remboursements partiels et les factures, représente un chantier à part entière. Posez-vous la question de la valeur réelle : qui consulte ces données, à quelle fréquence, et pour quoi faire ? La comptabilité a souvent déjà ces informations ailleurs.
Les intégrations : ERP, PIM, paiement, transport
C'est le poste le plus sous-estimé des cadrages de migration. Un ERP qui pousse les fiches produits, les stocks, les créneaux de retrait, les commandes et la comptabilité représente une surface d'intégration bien plus large qu'une boutique. Sur le projet de migration de Magento vers Sylius de la maison Vincent Guerlais, la synchronisation avec l'ERP Odoo et les caisses des boutiques physiques a pesé autant que le site lui-même.
Recensez chaque flux : qui est maître de la donnée, dans quel sens elle circule, à quelle fréquence, et ce qui se passe quand le flux tombe. C'est fastidieux. C'est aussi ce qui évite les mauvaises surprises à trois semaines de la mise en ligne.
N'oubliez pas : c'est une nouvelle aventure
Vous avez accumulé beaucoup de fonctionnalités et de données avec votre Magento, et il n'est pas possible d'avoir exactement la même chose de l'autre côté. Il va falloir faire des concessions. C'est comme changer de voiture : au global on est gagnant, mais il y a presque toujours un petit truc qui nous manque.
Attention au SEO : c'est là qu'on perd le plus d'argent
Changer de plateforme, c'est presque toujours changer les URL. Cela veut dire que vous risquez de perdre beaucoup de trafic organique si vous ne vous en occupez pas dès le début du projet, et pas la semaine de la bascule. Le SEO est le seul poste d'une migration où une erreur se paie en chiffre d'affaires immédiat.
Le plan de redirections
Le principe est simple, l'exécution l'est moins. Il faut crawler l'intégralité de l'ancien site avant la bascule, croiser ce crawl avec les URL qui reçoivent réellement des impressions dans la Search Console sur les seize derniers mois, et établir une correspondance une pour une entre ancienne et nouvelle URL.
- Des redirections 301, permanentes, pas des 302.
- Une correspondance vers la page équivalente, jamais une redirection en masse vers la page d'accueil : Google la traite comme une page introuvable déguisée.
- Pas de chaîne de redirections : l'ancienne URL doit pointer directement vers la cible finale.
- Les paramètres, les filtres et les pages de résultats doivent être traités explicitement, sinon ils génèrent des milliers d'erreurs le lendemain.
Nous avons des outils pour suivre les erreurs 404 une fois la migration effectuée et la plupart des redirections en place, parce qu'on loupe toujours des pages : c'est un fait, sur tous les projets, et il vaut mieux l'outiller que le nier.
Ce qu'il faut mesurer avant de couper
On ne peut pas démontrer qu'une migration s'est bien passée si on n'a pas de point de référence. Avant la bascule, figez : les clics et impressions par URL sur douze à seize mois, la liste des pages réellement indexées, les positions sur vos requêtes stratégiques, les revenus par page d'entrée, et vos Core Web Vitals. Sans cela, le premier creux de trafic déclenchera un débat d'opinions au lieu d'un diagnostic.
Les balises qui changent sans prévenir
Un nouveau thème reconstruit les balises title et les méta-descriptions à sa façon. On découvre souvent après coup que le modèle concatène le nom du site partout, ou tronque les titres de catégorie. Vérifiez ces balises sur un échantillon de chaque type de page avant la mise en ligne, pas après : nous détaillons les pièges dans notre guide sur la balise title.
Même vigilance sur la pagination du catalogue et les URL canoniques, qui sont gérées différemment d'une plateforme à l'autre et produisent très vite de la duplication à grande échelle. Nous avons écrit sur la mise en place des canoniques et de la pagination.
Une migration est aussi l'occasion de reprendre le maillage interne, souvent dégradé par des années d'ajouts successifs.
Les trois premiers mois après la bascule
Un creux de trafic dans les premières semaines est normal : Google doit recrawler, comprendre les redirections et recalculer. Ce qui n'est pas normal, c'est que ce creux dure. Surveillez les erreurs 404 quotidiennement le premier mois, l'état d'indexation dans la Search Console chaque semaine, et gardez la capacité d'ajouter des redirections pendant tout le trimestre.
On en profite aussi pour améliorer le SEO au global sur la nouvelle plateforme : une meilleure ergonomie, des données structurées propres, de bonnes pratiques un peu meilleures en général, et surtout une formation de vous et de vos équipes. Une migration bien menée ne se contente pas de ne rien perdre.
Vers quoi migrer ? Les destinations, sans complaisance
Il n'y a pas de bonne plateforme dans l'absolu, il y a une plateforme cohérente avec votre modèle, votre équipe et votre budget de fonctionnement. Voici comment nous voyons les quatre destinations que l'on nous demande le plus souvent quand un marchand quitte Magento.
Magento 2 et Adobe Commerce
C'est la continuité, et ce n'est pas un mauvais choix pour tout le monde. Magento reste très solide sur les gros catalogues, le multi-boutique, le multi-pays et le B2B, avec des fonctionnalités natives que les autres plateformes demandent de redévelopper.
Le coût de possession est le point de vigilance : hébergement dimensionné, licences pour la version Adobe Commerce, extensions tierces à renouveler, et surtout ce cycle de montée de version tous les deux ans qui ne s'arrêtera pas. C'est le choix rationnel si votre complexité métier correspond vraiment à ce que Magento sait faire nativement. C'est un choix coûteux si vous n'utilisez que 20 % de la plateforme.
Shopify
C'est la destination qui rassure : on ne gère plus d'infrastructure, on ne fait plus de montée de version, le run devient léger et prévisible, et l'écosystème d'applications couvre l'essentiel des besoins standards. Pour un marchand dont le modèle est proche du standard, c'est souvent le meilleur rapport effort / résultat.
Les limites apparaissent quand le métier sort du cadre : tunnel de commande atypique, logistique multi-points, règles de prix complexes, intégration profonde avec un ERP maison. On les contourne à coups d'applications, ce qui reconstitue peu à peu une dette d'un autre genre, et on reste dans un modèle où l'on ne décide ni du calendrier ni des règles. Il faut aussi intégrer le coût réel complet : abonnement, applications, et commissions.
PrestaShop
L'écosystème français est un vrai atout : documentation, prestataires, modules métier locaux, coût d'entrée modéré. Pour un catalogue de taille moyenne et un besoin classique, la plateforme fait le travail.
Notre réserve est structurelle : la qualité des modules tiers est très inégale, et un site PrestaShop chargé de modules retrouve assez vite les symptômes qui vous font quitter Magento aujourd'hui. Si vous migrez pour échapper à une accumulation d'extensions mal maîtrisées, vérifiez que vous n'êtes pas en train de refaire le même chemin.
Sylius
Sylius n'est pas la solution complète qui permet de mettre en place un site e-commerce en quelques heures, comme c'était possible avec Magento. C'est un framework e-commerce construit sur Symfony : on part d'une base saine et on développe ce dont vous avez besoin, plutôt que de désactiver ce dont vous n'avez pas besoin.
L'avantage est direct pour un marchand qui vient de Magento : plus de dette de fonctionnalités inutilisées, un back-office que l'on adapte réellement aux opérations, un socle Symfony pour lequel on recrute sans difficulté en France, et pas de licence. L'inconvénient est tout aussi direct : il n'y a pas de version clé en main, il faut une équipe ou une agence, et le projet initial demande plus de conception qu'un déploiement Shopify.
Nous détaillons la comparaison point par point dans Sylius contre Magento.
Comment nous tranchons
Sylius est notre réponse par défaut pour un marchand qui quitte Magento avec un métier spécifique et l'intention de continuer à faire évoluer son site pendant des années. C'est le cas de la maison Vincent Guerlais, où après plusieurs années de maintenance sous Magento la migration vers Sylius nous a semblé évidente : un tunnel multi-shipping sur mesure et une synchronisation ERP fine n'auraient pas trouvé leur place dans un cadre plus fermé.
Ce n'est pas notre réponse si vous vendez un catalogue simple, sans intégration lourde, avec une équipe de deux personnes et sans budget de développement récurrent. Dans ce cas, une plateforme SaaS vous rendra plus service, et nous vous le dirons.
Comment se déroule concrètement un projet de migration
Une fois que tout le monde est au fait de la direction à prendre, il n'y a pas de temps à perdre. Voici l'ordre dans lequel nous menons les chantiers, et pourquoi cet ordre.
L'ordre des chantiers
- Le socle d'abord. Le setup du projet, la mise en place de la plateforme, les bonnes pratiques, les tests automatisés, le serveur de production et les environnements de recette : tout cela se fait dès le départ, pas à la fin.
- Le design ensuite, tôt. On conçoit le nouveau design très vite, parce que c'est le moyen le plus rapide de valider le fonctionnel avec vous. Un parcours dessiné provoque des questions qu'un cahier des charges ne provoque jamais.
- Les données en parallèle. Pendant ce temps, on migre les données essentielles : les clients et les adresses en premier. C'est rapide sur du Magento resté proche du natif, plus long dès qu'il y a des attributs personnalisés.
- L'intégration et les spécifiques. Une fois le design validé, on intègre et on développe les fonctionnalités qui ne sont pas incluses dans la plateforme d'arrivée.
- Le SEO tout du long. Le plan de redirections se construit pendant le projet, pas la veille de la bascule.
Votre temps, pas seulement le nôtre
Nous connaissons rarement votre site Magento aussi bien que vous. Nous connaissons la technique, mais ce n'est pas nous qui faisons votre business, c'est vous. Restez avec nous tout au long du projet, investissez du temps pour nous, afin que nous puissions faire les bons choix techniques et que nous menions ensemble le projet jusqu'au bout et dans les temps.
Un tel projet en prend beaucoup, du temps. Mais avec une bonne organisation agile comme chez Monsieur Biz, on s'en sort finalement avec quelques coups de fil dans la semaine et une à deux heures de rendez-vous en fin de semaine.
Les surprises font partie du plan
Et n'oubliez pas que des surprises, bonnes ou mauvaises, vous en aurez. On ne change pas de plateforme e-commerce sans oublier quelque chose, sans stress et sans imprévus. La différence entre un projet qui se passe bien et un projet qui dérape n'est pas l'absence de surprises : c'est la marge qu'on a gardée pour les absorber.
Par où commencer
Avant de demander un devis de migration, faites-vous cadrer. La liste des fonctionnalités critiques, l'inventaire des flux, la photographie SEO et l'arbitrage entre mise à jour et replatforming valent d'être posés avant d'écrire la moindre ligne de code : c'est exactement l'objet de notre accompagnement conseil sur une refonte de site. Vous en ressortez avec un périmètre, pas avec une intuition, et les devis que vous recevrez ensuite deviennent comparables.
Migration Magento : les questions fréquentes
Combien de temps dure une migration Magento ?
Cela se compte en mois, pas en semaines. La durée ne dépend presque pas de la taille du catalogue : elle dépend du nombre d'intégrations à refaire, du volume de développements spécifiques à reprendre, de la propreté de vos données et de votre disponibilité pour arbitrer. Deux marchands avec le même nombre de références peuvent avoir des projets du simple au triple. C'est précisément pour cela qu'un cadrage préalable vaut mieux qu'un délai annoncé au téléphone.
Peut-on migrer sans perdre son référencement ?
Sans rien perdre du tout, non : il y a toujours un creux le temps que Google recrawle et recalcule. Avec un plan de redirections construit pendant le projet et non à la fin, une correspondance une pour une sur les URL qui comptent, et un suivi des 404 les premières semaines, ce creux se referme. Les pertes durables que nous constatons viennent presque toujours du même endroit : des redirections faites dans l'urgence, ou une redirection globale vers la page d'accueil.
Faut-il migrer l'historique des commandes ?
Rarement en totalité. Conserver l'ancienne base en lecture seule pour afficher un historique simple dans le compte client coûte beaucoup moins cher que de reprendre statuts, avoirs, remboursements partiels et factures. Posez la question de l'usage réel avant celle de la faisabilité.
Que deviennent nos extensions Magento ?
Elles ne migrent pas. C'est une bonne nouvelle plus souvent qu'on ne le croit : l'inventaire des extensions révèle presque toujours des modules installés pour un besoin ponctuel et jamais désinstallés. Pour chacune, trois issues possibles : la fonctionnalité existe nativement sur la plateforme d'arrivée, elle existe sous forme de plugin, ou elle doit être redéveloppée. Ce tri est un livrable de cadrage à part entière.
Peut-on migrer par étapes plutôt que d'un coup ?
Sur le papier oui, en pratique c'est coûteux. Faire cohabiter deux plateformes suppose de synchroniser en permanence catalogue, stocks, clients et commandes, et de gérer un SEO réparti sur deux socles. Cette approche se justifie sur des architectures très volumineuses ou multi-pays, où l'on migre pays par pays. Pour un site unique, une bascule préparée reste plus simple et moins risquée qu'une cohabitation prolongée.
Notre site est encore sous Magento 1 : est-ce rattrapable ?
Oui, et vous n'êtes pas seuls dans ce cas. Ce qui change, c'est l'urgence : sans correctif de sécurité officiel depuis juin 2020, le sujet n'est plus l'optimisation mais l'exposition. La priorité est de sécuriser l'existant pendant que le projet de migration se cadre, pas de courir les deux en même temps.
Migrer coûte-t-il plus cher que monter de version ?
À l'instant T, oui, toujours. Sur trois à cinq ans, cela dépend entièrement du nombre de montées de version que vous auriez payées sur la période, du coût de vos extensions et de ce que la plateforme actuelle vous empêche de faire. Comparez des coûts cumulés, jamais deux devis initiaux.
Ce qu'il faut retenir
- Magento 1 n'est plus supporté depuis le 30 juin 2020 : le sujet n'est plus technique, il est de conformité.
- Sur Magento 2, chaque ligne de version a sa propre date de fin de support, et le rythme est d'environ une montée de version tous les deux ans, indéfiniment.
- Rester est une décision légitime, à condition de la budgéter comme telle.
- Ne choisissez pas la plateforme d'arrivée en premier. Listez d'abord ce qui doit survivre : intégrations, attributs, opérations, historique.
- L'historique de commandes s'archive plus souvent qu'il ne se migre.
- Le SEO est le poste où une migration se paie le plus vite : plan de redirections 301 une pour une, photographie avant bascule, suivi des 404 pendant trois mois.
- Magento 2, Shopify, PrestaShop et Sylius répondent à des profils différents. Sylius est notre réponse par défaut quand le métier est spécifique et que le site doit continuer à évoluer ; ce n'est pas la bonne réponse pour un catalogue simple sans budget de développement récurrent.
- Un cadrage préalable rend les devis comparables. Sans lui, ils ne le sont pas.
Et si vous en parliez avec nous ? Nous maintenons des Magento, nous en avons migré vers Sylius, et nous vous dirons franchement si la migration est le bon mouvement pour vous maintenant, ou si elle peut attendre. Parlons de votre projet.