Migrer de Magento vers Shopify : redirections, modèle de données et le moment où Plus devient obligatoire

Personne ne quitte Magento par curiosité. On part parce qu'une date de fin de support tombe, parce que la facture d'infogérance a doublé, ou parce que la dernière montée de version a coûté trois mois de roadmap.

J'ai déjà publié le guide général sur comment migrer vers Shopify sans perdre ton référencement, et le cas WooCommerce, qui est un autre monde. Magento pose des questions que WooCommerce ne pose jamais, parce que derrière la boutique il y a un modèle de données d'entreprise, du B2B, et souvent un ERP branché dessus.

le calendrier qui pousse tout le monde dehors

Magento 1 ne reçoit plus de patch depuis le 30 juin 2020. Si tu es encore dessus, ton problème du jour s'appelle la conformité PCI.

Pour Magento 2, Adobe publie une date par version mineure. Le 11 août 2026, deux échéances sont tombées d'un coup : la fin du support étendu de la 2.4.5 et la fin du support standard de la 2.4.6. La 2.4.7 tient jusqu'au 31 mai 2027 en standard et jusqu'au 31 mai 2028 en étendu. La 2.4.8 va jusqu'au 31 mai 2028, la 2.4.9 est sortie le 12 mai 2026.

Une nuance que je n'ai pas réussi à trancher proprement. Ces dates sont documentées pour Adobe Commerce, et le support étendu concerne les clients payants. Adobe ne détaille pas le calendrier de Magento Open Source au même endroit. Si tu es sur Open Source, ne te fie pas à une date lue sur un blog, la mienne comprise. Demande à ton hébergeur ou à ton intégrateur ce qu'il patche encore.

En arrière-plan, Adobe a lancé en 2025 Adobe Commerce as a Cloud Service, une version SaaS multi-tenant sans numéro de version. La plateforme auto-hébergée continue d'exister, mais l'énergie d'Adobe est ailleurs. Beaucoup de marchands que j'appelle font ce calcul-là : rester sur une base qu'il faut mettre à jour tous les 18 mois, ou payer un abonnement et arrêter d'y penser.

les deux jeux d'URLs de Magento

Avant de générer quoi que ce soit, tu dois savoir quelle structure ton install produit vraiment.

Magento 2 construit ses URLs à partir du champ url_key, avec un suffixe configurable dans Stores, Configuration, Catalog, Search Engine Optimization. La valeur habituelle est html, ce qui donne /veste-en-lin.html.

Au-dessus, il y a le réglage « Use Categories Path for Product URLs ». La doc Adobe est claire là-dessus, le chemin de catégorie n'est pas inclus par défaut. Sauf qu'en pratique un intégrateur sur deux l'a activé en 2017 pour faire plaisir à une agence SEO, et le produit vit alors sous /homme/vestes/veste-en-lin.html. Selon le réglage, un même produit peut avoir été indexé sous une forme ou sous l'autre, parfois les deux.

Ajoute à ça les routes internes non réécrites (/catalog/product/view/id/1234), les URLs de recherche, et la navigation à facettes qui empile les paramètres (?color=45&size=167). Tu as un inventaire à faire avant de parler redirections.

Bonne nouvelle, Magento garde tout ça au propre dans sa table url_rewrite. Un export SQL de cette table te donne la liste des chemins servis, y compris les anciennes URLs déjà redirigées en interne après un changement de nom de produit. C'est beaucoup plus fiable qu'un crawl seul, et ça prend 5 minutes.

la carte des redirections 301, motif par motif

Les correspondances que je pose sur un Magento 2 standard.

Trois points qui décident du résultat.

Le suffixe fait partie du chemin source. Shopify redirige sur des chemins exacts, donc /veste-en-lin.html et /veste-en-lin sont deux lignes différentes. Si le chemin de catégorie était activé, tu as potentiellement deux entrées par produit. Génère les deux, ça ne coûte rien et ça couvre les backlinks anciens.

Les URLs à paramètres ne se redirigent pas proprement. Shopify l'écrit dans sa propre documentation : les URLs contenant une query string peuvent ne pas fonctionner comme prévu dans le tableau de redirections. Sur un Magento avec navigation à facettes indexée, ça représente parfois des milliers d'adresses. Tu rediriges le chemin propre (/homme/vestes.html) et tu laisses les variantes filtrées mourir. Vérifie avant dans la Search Console si l'une d'elles rapporte du trafic, parce que ça arrive.

Le volume a un plafond. Shopify annonce 100 000 redirections sur les plans standards et 20 millions sur Plus. Un catalogue de 40 000 SKU avec deux formes d'URL chacun, plus les catégories et le blog, ça se rapproche vite du plafond bas.

ce que ton modèle de données perd au passage

C'est le poste qui fait dérailler les plannings.

Les produits configurables deviennent des produits à variantes. Shopify autorise 3 options maximum par produit et jusqu'à 2 048 variantes depuis le 15 octobre 2025 (c'était 100 avant, ce qui bloquait beaucoup de migrations). La limite de 3 axes, elle, n'a pas bougé. Un configurable Magento à 4 attributs, du genre taille plus coloris plus longueur plus finition, ne rentre pas. Tu découpes en plusieurs produits ou tu passes par une app d'options, avec les conséquences que ça a sur le stock.

Les bundles et les produits groupés n'ont pas de traduction directe. Le bundle se refait avec Shopify Bundles ou une app dédiée. Le produit groupé, cette page qui liste plusieurs SKU achetables séparément, se rebâtit en section de thème. Dans les deux cas, quelqu'un doit décider du comportement voulu, et ce quelqu'un est ton chef de produit, pas l'outil de migration.

Les jeux d'attributs et l'EAV. Magento te laisse définir un schéma par type de produit, avec des attributs typés, filtrables, utilisés dans la navigation à facettes. Shopify a des metafields, avec des définitions globales à la boutique. La donnée se transfère, la logique non. Les filtres se reconstruisent avec Search & Discovery à partir des options de variantes, des tags et de certains metafields.

Les groupes de clients et les prix par palier deviennent des catalogues B2B, ce qui est le vrai basculement du projet.

Cart2Cart, LitExtension et Matrixify traitent les produits, les clients, les commandes. Aucun ne prend de décision à ta place sur les points ci-dessus, et les mots de passe clients ne passent pas, comme sur n'importe quelle migration Shopify. Prépare le mail d'activation de compte avant la bascule.

le B2B, là où se joue le choix du plan

Adobe Commerce embarque un module B2B assez complet : comptes entreprise avec hiérarchie, catalogues partagés, devis négociés, listes de réapprovisionnement, bons de commande avec règles d'approbation.

Shopify a rattrapé une bonne partie du terrain. Comptes entreprise, lieux de livraison, catalogues avec prix dédiés, conditions de paiement, règles de quantité, commande rapide. Sur la page B2B de Shopify, les catalogues assignés client par client sont marqués Plus, le reste apparaît sans mention de plan. La répartition exacte a bougé plusieurs fois ces deux dernières années, donc regarde la page tarifs le jour où tu signes plutôt que de me croire sur parole.

Deux manques à regarder de près. Le workflow de devis d'abord, avec aller-retour acheteur et vendeur : sur Shopify tu l'approches avec des commandes provisoires et des apps, il n'existe pas d'objet natif équivalent. Les règles d'approbation ensuite, quand un acheteur doit faire valider sa commande par son responsable au-dessus d'un montant.

Et un critère qui tranche vite. Shopify documente que les boutiques de tous les plans peuvent utiliser des apps publiques contenant des Functions, mais que seules les boutiques Plus peuvent installer une app sur mesure qui en contient une. Or les règles de prix catalogue et de panier de Magento, celles que ton équipe a affinées pendant 6 ans, se réécrivent précisément en Functions. Si aucune app du marché ne couvre ta logique, tu es sur Plus. J'ai détaillé le sujet dans mon article sur ce que remplacent les Shopify Functions.

le coût, sans chiffre inventé

Adobe ne publie pas de grille tarifaire. Tout passe par un devis indexé sur ton chiffre d'affaires, et les fourchettes qui circulent sur les blogs d'agences sont des estimations reconstituées. Je ne vais pas les recopier ici.

Ce que tu peux chiffrer, c'est ta propre facture. Hébergement, infogérance, licences d'extensions renouvelées, et le nombre de jours de développement consommés à chaque montée de version. Additionne les 12 derniers mois, tu auras une base de comparaison honnête.

En face, Shopify affiche ses prix : 27 € par mois pour Basic, 79 € pour Grow, 289 € pour Advanced en paiement annuel, et Plus à partir de 2 100 € par mois sur la page tarifs française au moment où j'écris. Ajoute les apps, qui montent vite quand on les empile, et le développement du thème. Le budget complet, je l'ai décomposé dans combien coûte une boutique Shopify.

les cas où je déconseille la migration

Il y en a, et je préfère le dire avant de facturer un cadrage.

Si ton chiffre d'affaires passe par des devis négociés avec validation hiérarchique, des encours clients gérés dans l'ERP et des tarifs contractuels à 4 niveaux, Shopify va te demander de rebâtir tout ça en apps et en développements sur mesure. Le calcul finit souvent moins bon qu'annoncé.

Si ton catalogue repose sur un configurateur à 5 axes, sur des kits assemblés à la commande, ou sur 12 store views avec des catalogues réellement distincts par pays, tu vas passer ton budget en contournements. Shopify Markets couvre bien les langues, devises et prix par marché, beaucoup moins des entités qui ne vendent pas les mêmes produits.

Et si tu es sur 2.4.7, couvert jusqu'en mai 2027, avec pour seule douleur un site lent, la migration est la réponse la plus chère à ton problème. Un travail de performance sur l'existant coûte moins qu'une refonte de plateforme.

Il y a enfin un réflexe à surveiller, celui de partir sur Shopify en se promettant de recoder la vitrine en Hydrogen pour retrouver la liberté qu'on avait sur Magento. Ça marche, ça coûte cher, et ça ne se justifie que dans des cas précis que j'ai listés dans à qui sert vraiment le headless.

Quand la migration a du sens, elle se prépare dans cet ordre : export de la table url_rewrite, arbitrage sur les types de produits, maquette du B2B sur une boutique de test, puis seulement le catalogue et les redirections chargées avant la bascule DNS. Les projets qui dérapent sont ceux qui commencent par le thème.

Si tu es en train d'arbitrer, ou si un plan de migration t'a déjà été chiffré et que tu veux un deuxième avis sur ce qu'il oublie, c'est exactement ce que je regarde dans un audit.