Guide de migration WooCommerce vers Shopify : le playbook d'ingénierie qui préserve votre trafic, vos données et votre santé mentale

La plupart des guides de migration WooCommerce vers Shopify s'arrêtent à "utilisez Matrixify, mettez en place des redirections 301, ça ira". Cette phrase est correcte et dangereusement incomplète. Les marchands qui perdent 30 à 60 pour cent de leur trafic organique dans les semaines après le lancement n'ont pas sauté les redirections. Ils ont sauté la logique de mappage d'URL qui se trouve sous les redirections. Ils ont sauté l'audit des variantes. Ils ont sauté la réalité des mots de passe clients. Ils ont sauté la passe de validation post-lancement qui attrape les 20 pour cent de produits qu'un outil a silencieusement abandonnés sans message d'erreur.

Ce guide est le playbook d'ingénierie que nous déroulons sur les projets de migration WooCommerce vers Shopify. Il est écrit pour le marchand ou le développeur qui a décidé que le déménagement allait se faire et qui doit maintenant le faire sans perdre de classements, de commandes ou de confiance client. Il suppose que la décision stratégique est prise ; si vous débattez encore si Shopify est le bon choix, c'est une autre conversation, et l'essentiel se résume à où la dette technique se trouve aujourd'hui versus où vous la voulez demain.

Le cadrage honnête : une migration propre WooCommerce vers Shopify est faisable, reproductible et bien en deçà du seuil de catastrophe si vous la planifiez. Une migration précipitée, exécutée en panique quand WooCommerce finit par s'effondrer sous le trafic, est exactement comme cela qu'on devient l'histoire édifiante dans le post de blog de quelqu'un d'autre. Le timing compte. Migrez selon votre calendrier, pas celui de votre hébergeur.

Pourquoi les marchands déménagent réellement

Nous faisons attention à ne pas vendre Shopify dans nos projets de migration, parce que les marchands avec qui nous travaillons ont généralement décidé. Mais les patterns qui les amènent à la décision sont assez constants pour mériter d'être nommés, parce qu'ils façonnent ce que la migration doit corriger, pas seulement ce qu'elle doit copier.

Les boutiques WooCommerce accumulent de la dette de plugins. Vingt, quarante, soixante plugins, chacun chargeant des scripts, chacun avec son propre cycle de mises à jour, chacun une vulnérabilité potentielle. Le site ralentit année après année, le page builder se bat avec le thème, le plugin de checkout se bat avec le plugin de paiement, et chaque "petit changement" a besoin du développeur qui l'a branché initialement. Le site fonctionne, mais c'est un tapis roulant de maintenance, et le marchand passe plus de temps à le faire tourner qu'à l'améliorer.

La facture d'hébergement est imprévisible. WooCommerce sur un hébergeur économique s'écroule pendant les ventes. WooCommerce sur un hébergeur WordPress managé sérieux coûte autant que Shopify Plus et vous demande encore de gérer votre propre cache, votre propre sécurité, vos propres sauvegardes et votre propre uptime. La conversation TCO ressemble à autre chose une fois qu'on compte le temps d'ingénierie honnêtement.

Les attentes des acheteurs ont bougé. Pages qui se chargent en moins d'une seconde, checkout mobile-first, stock en temps réel, inclusion dans les surfaces de recherche IA, méthodes de paiement modernes incluant Shop Pay, Apple Pay et les fournisseurs buy-now-pay-later. Atteindre tout cela sur WooCommerce est possible. C'est aussi un investissement annuel d'ingénierie à six chiffres dans quelque chose que la plupart des équipes préféreraient acheter plutôt que construire.

Si votre situation ressemble à l'une de celles-là, le déménagement a du sens. Le reste de ce post est comment le faire proprement.

Le calendrier et le coût réalistes

Deux questions que chaque marchand pose en premier : combien de temps cela prend, et combien cela coûte. Fourchettes honnêtes, pas chiffres marketing.

Un catalogue standard de quelques milliers de SKU, sans abonnements, sans personnalisations lourdes, sans portail B2B, tourne en quatre à huit semaines de bout en bout. Cela couvre la planification, le build du thème, la migration des données, le mappage des redirections, le QA, le lancement et une passe de validation post-lancement. Les catalogues plus petits vont plus vite. Les catalogues plus gros, les variantes complexes, les données d'abonnement, le B2B avec prix négociés et les intégrations ERP poussent à douze à seize semaines.

Le coût dépend presque entièrement du travail de design et d'intégration, pas de la migration des données elle-même. Le déplacement des données représente quelques milliers d'euros d'outillage plus du pilotage d'ingénierie. La refonte du thème, les intégrations, le nettoyage des données et le réglage post-lancement sont l'essentiel de la facture. Pour une boutique WooCommerce mid-market typique, le total réaliste est un projet à cinq chiffres. Les boutiques qui essaient de migrer pour le seul coût d'une licence Matrixify sont celles qui finissent par tout refaire.

La forme en quatre phases d'une migration propre

Chaque migration que nous menons suit les mêmes quatre phases. Les frontières entre phases comptent, parce que franchir l'une avant que la précédente soit validée est la cause unique la plus courante des incendies post-lancement.

Phase 1 : audit et planification. Ce qu'il y a réellement sur votre boutique WooCommerce aujourd'hui, ce que vous gardez, ce que vous retirez enfin, et à quoi ressemble la nouvelle version Shopify.

Phase 2 : construction du thème et des intégrations. Le storefront Shopify, les apps, les intégrations, l'architecture metafield, tout construit sur une boutique de dev avec des données d'exemple importées, prêt à partir avant que la vraie migration tourne.

Phase 3 : migration des données et mappage des redirections. Le vrai catalogue, les clients, les commandes et le contenu migrent, avec une carte complète de redirections 301 prête à publier à la bascule DNS.

Phase 4 : lancement et validation post-lancement. Bascule avec les redirections en ligne, monitoring, et une passe de validation de deux semaines pour attraper les choses qui passent toujours à travers.

Le reste de ce post parcourt chaque phase avec les vraies décisions et pièges.

Phase 1 : audit et planification

Cette phase détermine si le reste se passe bien ou si vous découvrez les surprises au lancement. D'une demi-journée à deux jours de travail selon la complexité de la boutique, et cela se rentabilise plusieurs fois.

Inventoriez ce que vous avez réellement

Sortez un inventaire complet de WooCommerce : chaque produit y compris les variations, chaque client, chaque commande, chaque code promo, chaque article de blog, chaque page statique, chaque pattern d'URL. Les outils gratuits sont utiles ici ; Screaming Frog vous donnera une liste d'URL propre, et l'export natif de WooCommerce couvre les données du catalogue. Ne sautez pas l'inventaire en vous disant "nous savons ce que nous avons". Vous ne savez quasi certainement pas. Nous n'avons jamais mené d'audit de migration qui n'ait pas fait remonter des produits dont personne ne se souvenait, des redirections de 2019 toujours en place et des segments clients que l'équipe marketing pensait disparus.

Auditez les variantes contre la limite Shopify

C'est le piège qui attrape plus de migrations WooCommerce que tout autre point. Shopify a une limite dure de 3 options par produit (donc taille, couleur et matière passe ; taille, couleur, matière et finition non) et une limite de 100 variantes par produit sur les plans standard. Shopify Plus étend à 2 000 variantes par produit, ce qui résout la plupart des cas mais pas tous.

WooCommerce n'a pas ces limites. Les boutiques de prêt-à-porter, de produits industriels configurables ou de fabrication à la demande découvrent à ce stade qu'elles ont des produits avec 4 à 7 options et des centaines de variantes. Les choix, par ordre approximatif de coût et difficulté :

Restructurez le catalogue pour que les produits multi-options se scindent en produits liés, souvent en utilisant les metaobjects Shopify pour les garder regroupés sur le storefront. C'est la réponse la plus propre mais c'est du vrai travail.

Passez à Shopify Plus pour le plafond à 2 000 variantes. Raisonnable si le nombre de variantes est la seule chose qui vous y pousse, mais Plus a son propre coût qui mérite sa propre décision.

Utilisez une app Shopify d'extension de variantes pour lever les limites avec des metaobjects sous le capot. Faisable mais ajoute une dépendance et un coût d'app.

La décision doit se prendre en phase d'audit, pas quand l'import échoue à mi-chemin.

Auditez la couche design

La pièce qui surprend les gens : rien ne migre le design. Si votre site WooCommerce utilise Elementor, Divi, WPBakery ou un page builder custom, chaque page rendue à travers ce builder doit être reconstruite dans Shopify, section par section. Il n'y a pas d'outil qui convertit les blocs Elementor en sections Shopify, et les outils de conversion assistés par IA qui prétendent le faire produisent des résultats qui doivent quand même être reconstruits.

C'est l'une des plus grosses lignes dans un vrai budget de migration et l'une des raisons les plus courantes pour lesquelles les projets devisés doublent en coût. Identifiez les pages dans le périmètre, décidez lesquelles valent vraiment la peine d'être recréées versus consolidées dans les primitives plus fortes de Shopify, et budgétez le travail du thème honnêtement.

Cataloguez les intégrations

Listez chaque système externe avec lequel WooCommerce parle actuellement. Email marketing, avis, comptabilité, ERP, fulfillment, service client, analytics, pixels publicitaires, gestion d'abonnements. Pour chacun, déterminez si le même outil existe pour Shopify (la plupart oui), s'il a un chemin d'export-import pour les données historiques, et si le modèle de données se mappe proprement.

Les avis sont une mine fréquente. Les notes étoiles et le contenu d'avis stockés dans un plugin d'avis natif WooCommerce n'apparaissent pas automatiquement dans l'équivalent Shopify. Récupérez l'export, confirmez le chemin d'import côté Shopify, et confirmez le mappage d'URL pour que le schema markup reste attaché à la bonne page produit.

Les abonnements sont une autre mine. Les données WooCommerce Subscriptions, avec leurs dates de renouvellement, tokens de paiement et calendriers de facturation client, ne migrent pas automatiquement vers les apps d'abonnement Shopify. Recharge a un processus de migration établi ; les autres apps d'abonnement varient. Si vous avez une base d'abonnements active, c'est l'intégration au plus gros rayon d'impact et celle à cadrer en premier.

Construisez le plan d'hygiène des données

La migration est le bon moment pour faire le ménage. Supprimez les SKU discontinués que vous voulez retirer depuis longtemps. Standardisez le nommage produit incohérent. Abandonnez les clients qui n'ont pas interagi depuis trois ans et qui vous coûteraient inutilement en email marketing sur Shopify. Les données que vous emmenez sont les données que vous maintenez pour toujours ; n'emmenez que ce que vous voulez réellement.

Phase 2 : construction du thème et des intégrations

Cette phase se passe en parallèle des dernières étapes de la phase 1. La boutique Shopify se construit sur une boutique de développement, avec des données d'exemple, prête à être remplie avec les vraies données quand la phase 3 tourne.

La décision du thème : un thème Shopify standard comme Dawn personnalisé via l'éditeur, un thème payant du Shopify Theme Store, un thème custom construit de zéro, ou un storefront Shopify headless sur Hydrogen ou Next.js. Pour la plupart des migrations mid-market, un thème payant avec une personnalisation réfléchie vous mène à 80 pour cent du chemin et c'est la voie la plus rapide. Les thèmes custom ont du sens quand la marque ou le modèle commerce le demande vraiment. Le headless a du sens quand les exigences de performance, de flexibilité de contenu ou d'écosystème front-end justifient réellement la complexité ; nous avons écrit sur cet arbitrage dans Hydrogen versus Next.js.

L'architecture metafield : définissez vos metafields et metaobjects avant de commencer à importer les données. Nous l'avons couvert en profondeur dans notre guide metaobjects et metafields ; la migration est le moment le plus efficace pour la construire parce que vous touchez à chaque produit de toute façon. Les boutiques qui sautent cette étape finissent par ajouter les données structurées après, à un coût bien plus élevé.

Les intégrations : installez et configurez chaque intégration sur la boutique de dev avec des données d'exemple. Lancez le vrai import pour tout outil qui supporte un environnement de test. Avis, abonnements, email marketing, comptabilité, ERP, fulfillment, analytics, pixels. Chaque intégration doit fonctionner dans l'environnement de dev avant que la phase 3 commence, parce que debugger des problèmes d'intégration avec des vraies données qui circulent est significativement plus dur.

La configuration du checkout : taxes, zones de livraison, méthodes de paiement, extensions de checkout custom si besoin. Avec Shopify Scripts qui se retire le 30 juin 2026, toute logique de checkout complexe que vous emmenez doit être implémentée comme Function dès le départ plutôt que comme Script, même si vous lancez avant cette deadline. Migrer maintenant et re-migrer dans huit semaines est du travail gaspillé.

Phase 3 : migration des données et mappage SEO

C'est la phase qui détermine si vous gardez votre trafic organique.

Choisissez l'outil de migration délibérément

Trois vraies options en 2026, plus une à éviter.

Matrixify est le choix d'ingénierie. Il déplace les produits avec les metafields complets, les données clients, l'historique des commandes, les articles de blog, les pages, la navigation et les redirections, tout via l'API Shopify avec un round-trip import-export propre. Il supporte les dry runs, qui vous laissent valider tout l'import avant de committer. C'est l'outil que nous utilisons sur les projets sérieux et le seul auquel nous faisons confiance pour les boutiques avec une complexité de données non triviale.

Cart2Cart et LitExtension sont des migrateurs automatiques managés. Moins chers que Matrixify-plus-temps-d'ingénierie en apparence, adaptés aux catalogues standard sans données inhabituelles, et pratiques si personne dans l'équipe ne veut apprendre un nouvel outil. L'arbitrage est l'opacité : quand quelque chose casse, la visibilité diagnostique est limitée comparée à Matrixify, et vous dépendez du calendrier de support du fournisseur.

Shopify Store Importer est l'option gratuite fournie par Shopify. Elle marche pour les boutiques les plus simples. Elle abandonne silencieusement les produits qu'elle ne peut pas gérer, elle time out sur les gros exports XML, et elle ne donne pas de messages d'erreur clairs quand elle échoue. Pour tout ce qui dépasse un petit catalogue, évitez-la. Le prix "gratuit" se paie plus tard en corrections de catalogue.

Le pattern de décision : catalogue complexe, metafields non triviaux, données custom, B2B ou abonnements → Matrixify avec pilotage d'ingénierie. Catalogue standard, pas de données custom, petite équipe sans profondeur technique → Cart2Cart ou LitExtension. Tout petit catalogue sous 100 produits → CSV manuel est souvent le plus propre. Store Importer pour des migrations en production n'est pas une vraie option pour des boutiques qui valent la peine d'être migrées correctement.

Construisez la carte des URLs avant d'importer

C'est là que la plupart des migrations vivent ou meurent pour le SEO. La carte de redirections 301 doit être construite avant que le catalogue s'importe, pas après, parce qu'elle dépend de connaître à la fois l'ancien pattern d'URL et le nouveau, et que les nouvelles URLs sont déterminées par les règles de slug Shopify.

WooCommerce utilise typiquement des URLs comme /produit/chemise-coton-bleue/ et /categorie-produit/chemises/. Shopify utilise /products/chemise-coton-bleue et /collections/chemises. La conversion n'est pas littérale ; vous devez mapper chaque ancienne URL vers son équivalent Shopify.

Pour les produits, le pattern le plus propre est de paramétrer les handles produit Shopify pour qu'ils correspondent aux anciens slugs WooCommerce quand c'est possible, puis de construire une redirection pour chaque ancienne URL vers la nouvelle. Pour les catégories converties en collections, la même approche fonctionne. Pour les articles de blog, la structure de blog Shopify diffère légèrement de WordPress (/blogs/news/post-slug versus /blog/post-slug), donc chaque URL d'article a besoin d'une redirection.

# Carte de redirections d'exemple (CSV) pour import Matrixify
Path,Target
/produit/chemise-coton-bleue/,/products/chemise-coton-bleue
/categorie-produit/chemises/,/collections/chemises
/2024/03/15/titre-article-blog/,/blogs/news/titre-article-blog
/?p=12345,/products/nom-produit-legacy
/boutique/,/collections/all

Construisez cette carte en crawlant le site WooCommerce avec Screaming Frog (qui capture chaque URL réelle que Google peut avoir indexée), en exportant la liste, et en écrivant la logique de mappage. Pour la plupart des boutiques, les règles de mappage sont programmatiques : une regex peut transformer 95 pour cent des URLs, et les 5 pour cent restants ont besoin d'une revue manuelle.

Les redirections s'uploadent via Matrixify en bulk, ou via la fonctionnalité native URL Redirects de Shopify pour les cartes plus petites. Elles doivent être en ligne à l'instant où vous basculez le DNS, pas ajoutées dans les jours qui suivent ; cet écart est quand Google voit des 404 sur des URLs qui se classaient avant, et récupérer de cela est bien plus dur que le prévenir.

Préservez la surface SEO

Au-delà des redirections, plusieurs éléments spécifiques doivent migrer ou risquent une perte de trafic.

Page titles et meta descriptions, par produit et par collection. Matrixify les emmène ; Cart2Cart et LitExtension généralement ; Store Importer souvent pas. Validez que chaque produit sur la nouvelle boutique a le titre et la meta description de l'ancien.

Schema markup. Le schema côté WooCommerce, souvent généré par des plugins SEO comme Yoast ou RankMath, ne se transfère pas. Shopify génère son propre Product schema, mais le jeu de propriétés est bien plus petit que ce que les agents IA lisent désormais. Prévoyez d'ajouter un schema complet dans le cadre du build du thème, pas après.

Alt text des images. Fréquemment perdu dans les outils de migration qui se concentrent sur les données produit. Validez cela explicitement post-import.

Tags canoniques. Shopify gère bien les canonicals par défaut, mais une migration est une opportunité d'introduire des doublons par accident, en particulier à travers des URLs de collection qui affichent les mêmes produits qu'une vue tag ou filtre.

Sitemap. Shopify génère son propre sitemap.xml automatiquement. Soumettez-le à Google Search Console immédiatement au lancement. N'attendez pas la découverte naturelle.

Lancez un import dry-run

Matrixify supporte les imports dry-run qui vous montrent exactement ce qui changerait sans committer. Utilisez cela. Lancez la migration complète des données en dry run, examinez le rapport, corrigez les problèmes qui surgissent, puis lancez pour de vrai. Cette seule discipline est la différence entre une migration propre et une semaine à corriger au fur et à mesure.

Le dry run attrape les dépassements de limite de variantes, les champs requis manquants, les clients avec emails mal formés, les produits avec des URLs d'image qui n'ont pas transféré, et les références de commande qui pointent vers des produits supprimés. Tout cela est plus facile à corriger dans la source que dans Shopify après import.

La réalité des mots de passe clients

Un point qui surprend chaque marchand : les mots de passe clients sont chiffrés dans WooCommerce et ne peuvent pas être migrés vers Shopify. Les clients seront invités à réinitialiser leur mot de passe à la première connexion.

Ce n'est pas une limitation d'outil ; c'est une propriété de sécurité de comment les mots de passe sont stockés partout. Il n'y a pas de contournement. Le bon pattern est d'utiliser la fonctionnalité "Customer Invitation" de Shopify pour envoyer à tous les clients migrés un email amical sur la nouvelle boutique et un lien de réinitialisation de mot de passe dans le même flux. Positionnez-le comme une communication de relancement, pas un inconvénient de sécurité.

Résidence des données UE, si cela compte

Pour les marchands avec des clients UE, la question de où vivent les données pendant et après la migration est une question RGPD qui mérite réflexion. Les outils de migration traitent tous les données à travers leur propre infrastructure. Pour une boutique typique, c'est correct et couvert par leurs accords de traitement des données. Pour certains marchands avec des données clients sensibles ou des exigences strictes de résidence, le choix de l'outil, les emplacements de traitement temporaires et l'hygiène des données post-migration ont besoin d'une attention explicite. Confirmez vos spécificités avec votre DPO si vous en avez un.

Phase 4 : lancement et validation post-lancement

La première semaine après le lancement est là où les migrations calmes et les bruyantes divergent.

Checklist du jour de lancement

Bascule DNS avec la carte de redirections déjà en ligne. Sitemap soumis à Google Search Console immédiatement. Analytics et pixels de tracking validés via de vrais événements de conversion, pas seulement des déclenchements de tag. Le site WooCommerce original reste en ligne derrière un header noindex jusqu'à ce que les redirections aient été vérifiées fonctionnelles en production pendant au moins quelques jours ; ne démontez jamais l'ancien site avant que le nouveau soit confirmé capter chaque URL.

La passe de validation de deux semaines

La plupart des "catastrophes" de migration sont en fait de petits problèmes qui se sont composés silencieusement pendant deux semaines parce que personne ne vérifiait. La passe de validation qui les attrape est mécanique et vaut la peine d'être faite que votre équipe ou une agence la fasse.

• Crawlez le nouveau site avec Screaming Frog. Comparez à l'ancien crawl. Identifiez les URLs qui ne redirigent pas, les 404, les erreurs 5xx.
• Vérifiez Google Search Console quotidiennement les deux premières semaines. Surveillez les pics d'erreurs de crawl, les baisses d'impressions, les changements du nombre de pages indexées. Enquêtez immédiatement.
• Spot-checkez 5 pour cent des produits au hasard. Titre correct, description complète, images présentes, variantes justes, prix juste, schema qui rend, metafields remplis. Les outils abandonnent parfois silencieusement 10 à 20 pour cent des produits sans erreur ; cela l'attrape.
• Validez l'historique des commandes pour au moins les 60 derniers jours. "Où est ma commande du mois dernier" est l'incendie support post-lancement le plus courant.
• Testez l'email d'invitation client de bout en bout. Envoyez-le à une adresse de test. Cliquez le lien de réinitialisation. Confirmez que la réinitialisation fonctionne.
• Monitorez les logs serveur pour des 404 inattendus, surtout la première semaine. Les anciennes URLs que vous avez oublié de mapper surgiront ici avant d'apparaître dans Search Console.
• Vérifiez le schema markup avec le Rich Results Test de Google sur les meilleurs produits et collections. Le pattern de génération de schema du build du thème doit fonctionner de manière cohérente.
• Revoyez l'intégration email marketing. Chaque client migré a-t-il été synchronisé vers le nouvel outil email ? Les listes de suppression sont-elles préservées ? Les segments reconstruits ?

La règle 30, 60, 90 jours : le trafic organique baisse typiquement brièvement les deux à quatre premières semaines pendant que Google re-crawle et ré-évalue, puis récupère. Une migration propre avec des redirections complètes, des métadonnées préservées et un schema correct devrait être de retour au niveau de base ou meilleur d'ici le jour 60. Une migration qui a perdu les redirections ou les métadonnées ne récupérera pas sans intervention manuelle.

Ce que ce travail coûte honnêtement

Une boutique WooCommerce mid-market typique, 1 000 à 10 000 SKU, sans abonnements ni complexité B2B, une refonte propre du thème, une migration SEO complète avec redirections exhaustives, et une passe de validation de deux semaines : un projet à cinq chiffres réalistement, sur quatre à huit semaines. Les migrations d'abonnements, les portails B2B complexes, les intégrations ERP ou les gros catalogues poussent à partir de là.

La chose qui ne vaut pas la peine d'être faite : dépenser la moitié du budget sur une migration outil rapide puis essayer de corriger l'aftermath SEO et intégrations en interne. L'aftermath coûte toujours plus que de bien faire du premier coup, et le trafic perdu est rarement entièrement récupérable.

FAQ

Combien de temps prend une migration WooCommerce vers Shopify ?

Un catalogue standard de quelques milliers de SKU sans abonnements ni personnalisation lourde tourne en quatre à huit semaines de bout en bout. Les catalogues plus gros, les données d'abonnement, les portails B2B ou une intégration ERP profonde poussent à douze à seize semaines. Le déplacement des données en lui-même prend des jours ; l'essentiel du calendrier est le build du thème, les intégrations et la validation.

Vais-je perdre des classements SEO en migrant ?

Pas si vous faites le mappage des redirections et la préservation des métadonnées correctement. Une migration propre voit typiquement une brève baisse de deux à quatre semaines pendant que Google re-crawle, puis un retour au niveau de base au jour 60. Les migrations qui sautent le travail de redirections ou utilisent des outils qui abandonnent silencieusement les métadonnées peuvent perdre 30 à 60 pour cent du trafic organique et récupèrent rarement complètement.

Puis-je garder mes mots de passe clients ?

Non. Les mots de passe sont chiffrés partout et ne peuvent pas être migrés. Utilisez la fonctionnalité Customer Invitation de Shopify pour envoyer à tous les clients migrés un message de relancement avec un lien de réinitialisation dans le même flux. La plupart des clients complètent la réinitialisation à la première connexion sans se plaindre si le message est bien cadré.

Qu'arrive-t-il à mon historique de commandes ?

Il migre. Matrixify, Cart2Cart et LitExtension déplacent tous les données historiques de commandes. Validez les 60 derniers jours soigneusement parce que c'est là que se concentrent les questions du service client. Les commandes plus anciennes comptent pour l'analytics et le reporting ; spot-checkez plutôt que de lire chacune.

Et le contenu de mon blog WordPress ?

Il migre. Articles, pages, catégories et tags se transfèrent vers la structure de blog Shopify, même si le blogging Shopify est plus limité que WordPress et que vous pourriez avoir besoin d'une app d'amélioration de blog pour des fonctionnalités plus riches. Crucialement, chaque ancienne URL de blog a besoin d'une redirection 301 ; les structures d'URL de blog WordPress et Shopify diffèrent.

Mes avis vont-ils migrer ?

Le contenu des avis lui-même migre typiquement si vous paramétrez bien l'import côté Shopify, mais le lien du schema markup vers les produits spécifiques a besoin d'être rétabli. Les avis stockés dans des plugins natifs WooCommerce comme WooCommerce Product Reviews ont besoin d'un chemin d'export-import explicite ; les avis stockés dans des apps tierces comme Yotpo ou Judge.me sont plus faciles parce que les deux côtés supportent le même fournisseur.

Devrais-je utiliser Matrixify ou Cart2Cart ?

Matrixify pour les catalogues complexes, les données custom ou n'importe où vous voulez une visibilité totale sur ce qui se déplace. Cart2Cart ou LitExtension pour les catalogues standard et les équipes sans profondeur technique. Évitez le Store Importer gratuit de Shopify pour tout ce qui dépasse un tout petit catalogue de test parce qu'il abandonne silencieusement des produits et time out sur les gros exports.

Dois-je passer à Shopify Plus ?

Seulement si la complexité de votre catalogue, vos exigences B2B ou votre volume de transactions le justifient. Le plafond Plus à 2 000 variantes résout le piège des variantes pour les boutiques qui l'atteignent, mais Plus est un engagement annuel plus gros et mérite sa propre décision. La plupart des boutiques WooCommerce migrent vers Shopify standard ou Advanced, pas Plus.

Comment gérer les pages Elementor ?

Vous les reconstruisez en sections Shopify, manuellement. Aucun outil ne convertit les blocs de page builder en sections Shopify de manière fiable. C'est l'une des plus grosses lignes d'un vrai budget de migration et cela doit être cadré en amont, pas découvert en cours de projet.

Puis-je le faire moi-même ou ai-je besoin d'une agence ?

Les petits catalogues avec données simples, sans abonnements, sans B2B, et une équipe à l'aise avec Matrixify peuvent mener une migration en interne. Tout ce qui a des données non triviales, des abonnements, une intégration ERP, des prix B2B ou un trafic organique significatif à protéger bénéficie généralement d'un support d'agence, parce que les modes d'échec sont prévisibles mais chers à récupérer.

Pour aller plus loin

Si vous êtes au début d'une décision WooCommerce vers Shopify, l'audit est la bonne prochaine étape. Même un audit d'une demi-journée vous dit si votre catalogue tape la limite de variantes, à quoi va ressembler votre vraie carte de redirections, quelles intégrations ont besoin de chemins de migration explicites, et quel est le coût et le calendrier réalistes. La plupart des marchands trouvent l'audit assez clarifiant pour que le reste de la décision devienne direct.

Si vous voulez que nous fassions l'audit et la migration, contactez-nous. Nous commençons chaque migration avec le plan en quatre phases ci-dessus, livrons la carte de redirections et la passe de validation comme livrables nommés, et restons engagés à travers la fenêtre de monitoring post-lancement. Vous pouvez en savoir plus sur notre service de migration Shopify et notre travail d'ingénierie SEO technique, qui couvre le côté SEO de tout projet de replatforming.

Pour des lectures associées : metaobjects et metafields Shopify pour les décisions d'architecture de données à prendre pendant le build du thème, migration Shopify Scripts vers Functions pour la pièce de personnalisation checkout si vous avez une logique de remise complexe sur WooCommerce qui doit migrer, et Hydrogen versus Next.js pour la décision headless si vous envisagez de passer à un storefront Shopify headless dans le cadre du replatforming.