La décision de migrer de PrestaShop vers Shopify part rarement d'un caprice technologique. Elle part d'une accumulation de petites frictions qui finissent par coûter plus cher qu'elles ne rapportent : une mise à jour de module qui tourne mal, un pic de trafic qui fait tomber le serveur, des développeurs qui passent plus de temps à maintenir l'infrastructure qu'à améliorer le produit. À un moment donné, la question n'est plus « est-ce qu'on migre ? » mais « comment on fait ça bien ? ».
Ce guide est là pour répondre à la deuxième question. Pas pour vous vendre un rêve sur la facilité de l'opération, parce que ça ne l'est pas toujours. Mais avec une préparation sérieuse, une migration PrestaShop vers Shopify permet de repartir sur des bases saines, et souvent de récupérer rapidement la valeur investie.
PrestaShop ou Shopify : clarifier la décision avant de s'engager
Avant d'aborder la méthode, un point d'honnêteté s'impose : PrestaShop reste une plateforme solide pour certains profils de marchands. Si vous avez une équipe technique PHP dédiée qui maîtrise votre stack, un catalogue avec des règles de gestion très spécifiques codées sur mesure, ou des contraintes d'hébergement réglementaires que seul un serveur dédié peut satisfaire, la migration vers Shopify n'est peut-être pas votre priorité du moment.
En revanche, pour les marques DTC et les e-commerçants dont le cœur de métier n'est pas la gestion d'infrastructure, PrestaShop finit souvent par générer un coût de maintenance qui dépasse sa valeur. Les conflits entre modules s'accumulent avec les montées de version, l'hébergement, la sécurité et la supervision serveur restent entièrement à la charge du marchand, et la performance front-end se dégrade progressivement si personne ne s'en occupe activement.
Shopify résout ces problèmes structurellement : infrastructure cloud gérée, mises à jour transparentes, et un écosystème d'apps qui couvre la majorité des besoins sans développement custom. La contrepartie, c'est moins de liberté sur certains points techniques, un modèle SaaS avec des coûts récurrents, et une dépendance à l'écosystème Shopify pour les évolutions futures.
Ce que vous pouvez migrer, et ce qui demande de l'attention
Les données qui migrent sans friction majeure : fiches produits avec leurs déclinaisons et leurs images, métadonnées, données clients, historique de commandes, pages CMS et articles de blog. Sur des catalogues de plusieurs centaines de références, des outils comme Matrixify permettent d'industrialiser l'import via fichiers CSV ou Excel structurés.
Crédit : Matrixify
Les éléments qui demandent plus d'attention : les avis clients, les points de fidélité accumulés, et surtout les fonctionnalités développées sur mesure. Tout module custom codé spécifiquement pour votre boutique PrestaShop devra être ré-imaginé dans l'écosystème Shopify.
Un point sur les mots de passe : pour des raisons de sécurité, les hashages sont incompatibles entre les deux plateformes. Vos clients devront réinitialiser leur accès lors de leur première connexion.
Le SEO, le sujet qui génère le plus d'inquiétudes (et à raison)
Une migration mal gérée peut faire chuter le trafic organique de 30 à 50 % en quelques semaines. Une migration bien préparée permet de conserver l'essentiel du référencement, voire de l'améliorer.
Le cœur du sujet, c'est la structure d'URL. PrestaShop laisse une liberté totale sur la construction des chemins. Shopify impose ses propres conventions : /products/ pour les fiches produits, /collections/ pour les catégories. Si une URL indexée disparaît sans redirection, Google interprète la page comme supprimée.
La solution, c'est un plan de redirections 301 exhaustif, préparé avant le go-live. Sur 500 produits, comptez environ une demi-journée de travail pour construire et vérifier ce mapping. Sur des milliers de références, des scripts d'automatisation deviennent nécessaires.
Les balises title et meta description ne se transfèrent pas automatiquement depuis PrestaShop. Il faut exporter, nettoyer, et réimporter chaque métadonnée.
Le maillage interne pose aussi problème : tous les liens pointant vers vos anciennes pages se retrouvent cassés. Un crawl post-migration avec Screaming Frog ou Ahrefs permet de les corriger.
Les données structurées méritent aussi une vérification. Google Search Console vous confirmera rapidement après le lancement si quelque chose cloche.
Les grandes étapes d'un projet de migration bien piloté
Audit et cadrage. Avant d'écrire une ligne de code, il faut inventorier taille du catalogue, intégrations tierces, spécificités métier et fonctionnalités custom à reconstruire.
Mapping et préparation des données. Export, nettoyage, structuration au format Shopify, et construction du plan de redirections 301. La phase la plus chronophage sur les gros catalogues.
Développement et intégration. Thème Shopify, fonctionnalités spécifiques, connexion des apps et intégrations, sur un environnement de staging isolé du site live.
Tests et validation. Redirections, tunnel d'achat complet, flux vers les intégrations tierces, tests de charge si une campagne est prévue à court terme.
Go-live et suivi post-migration. Monitoring Search Console à J+7, J+14, J+30 pour détecter les anomalies d'indexation avant qu'elles ne s'installent.
Sur des projets standard (200 à 1 000 produits), comptez entre 2 et 4 mois.
Questions fréquentes avant de se lancer
Va-t-on perdre notre référencement Google ?
Avec un plan de redirections 301 complet et un suivi post-migration sérieux, les pertes sont généralement limitées et temporaires. Notre expérience suggère une récupération entre 80 et 95 % du trafic dans les deux mois suivant le lancement.
Peut-on coupler la migration avec une refonte graphique ?
Oui, et c'est souvent la bonne décision opérationnelle. La migration et la refonte partagent une grande partie du même travail de préparation.
Nos données clients et historiques de commandes seront-ils préservés ?
Oui, via des outils dédiés comme Matrixify. Les mots de passe clients ne peuvent pas être transférés pour des raisons de sécurité : vos clients devront réinitialiser leur accès.
Quelle est la bonne période pour lancer la migration ?
À éviter absolument : Black Friday, soldes, fêtes de fin d'année. Planifiez le go-live sur une période creuse, avec un plan de rollback documenté.
Faut-il forcément passer à Shopify Plus ?
Pour la majorité des marques DTC avec une boutique unique, Shopify Advanced suffit. Plus devient pertinent avec le multi-boutiques natif, un checkout personnalisé, ou du B2B avancé.
PrestaShop vers Shopify : le tableau de correspondance
C'est la partie que la plupart des guides sautent, et c'est pourtant celle qui décide du budget. Chaque notion PrestaShop a un équivalent Shopify — ou n'en a pas.
- Déclinaisons et combinaisons d'attributs deviennent des variantes. Shopify accepte trois axes par produit. Un catalogue qui combine taille, couleur, matière et finition doit être repensé avant l'import : fusion d'axes, éclatement en produits distincts, ou passage par des métachamps.
- Catégories et sous-catégories deviennent des collections. Les collections automatiques, pilotées par des règles de tags, remplacent l'arborescence profonde et se maintiennent seules quand le catalogue bouge.
- Caractéristiques produit deviennent des métachamps, affichés où vous le décidez dans le thème.
- Modules deviennent des applications, des fonctions natives ou du code de thème. Sur une boutique de cinq ans, un tiers des modules installés ne sert plus, et une bonne part de ce qui reste est devenu natif chez Shopify.
- Templates Smarty et overrides deviennent du Liquid. Aucune conversion automatique : le thème est refait.
- Groupes de clients et prix par groupe deviennent des comptes entreprise B2B, des marchés ou des règles de prix, selon votre plan Shopify.
- Multiboutique devient soit plusieurs marchés d'une même boutique, soit plusieurs boutiques. Le critère est organisationnel, pas technique : qui gère quoi, et sur quelle donnée.
Le plan de redirections, ligne par ligne
PrestaShop construit des adresses à identifiant — /12-nom-du-produit, /3-categorie — quand Shopify utilise /products/, /collections/, /pages/ et /blogs/. Toutes vos adresses changent, sans exception. La question n'est donc pas « allons-nous perdre du SEO ? » mais « le plan de redirections est-il complet ? ».
Ce qu'il faut produire, dans cet ordre :
- L'export exhaustif des adresses existantes : produits, déclinaisons indexées, catégories, pages CMS, articles, filtres indexés. Une extraction depuis la base, recoupée avec la Search Console et les journaux du serveur, pour ne pas oublier les adresses que seul Google connaît encore.
- La table de correspondance : ancienne adresse, nouvelle adresse, statut. Les produits supprimés au passage pointent vers leur collection, pas vers l'accueil.
- Le chargement des redirections avant la bascule, puis un test en masse juste après : un contrôle automatique des codes de réponse sur l'ensemble des anciennes adresses.
- La surveillance pendant les semaines suivantes : erreurs 404 dans la Search Console, positions des vingt requêtes qui comptent, et correction des oublis au fil de l'eau.
Une migration correctement redirigée produit une oscillation de quelques semaines, le temps de la réindexation, puis revient à son niveau. Une migration sans plan de redirections perd durablement le trafic acquis, et c'est irrattrapable à bon compte.
Ce que vous ne pourrez pas reprendre
Autant le savoir avant de signer.
Les mots de passe clients. Ils sont chiffrés par PrestaShop et ne se transfèrent pas. Les comptes et l'historique, eux, se reprennent. À la première connexion, le client reçoit un lien pour définir un nouveau mot de passe : cela s'annonce dans l'e-mail de lancement, sinon le service client passe sa première semaine à l'expliquer.
Le code sur mesure. Overrides, modules maison, scripts de synchronisation : rien ne se transpose. Ce qui compte vraiment est réécrit, le reste disparaît — et c'est souvent une bonne nouvelle.
L'accès au serveur. Plus de FTP, plus de base à requêter directement. Tout passe par l'administration, les applications et l'API. Pour une équipe habituée à PrestaShop, c'est le vrai changement de culture : en échange, les mises à jour cessent d'être un projet.
Combien de temps, et dans quel ordre
Une migration PrestaShop se compte en semaines, pas en jours. L'ordre que nous suivons :
- Semaines 1 à 2 — cadrage. Inventaire des modules, arbitrage des attributs, choix de la structure de collections, cartographie des flux (ERP, logistique, comptabilité), liste des contenus à reprendre.
- Semaines 2 à 6 — construction. Thème, gabarits, imports successifs sur une boutique de test : produits, stocks et prix, clients, commandes, contenus.
- Semaines 6 à 8 — recette. Parcours d'achat complet, cas particuliers (produit en lot, remise, commande partiellement remboursée), tests de charge, plan de redirections vérifié.
- Bascule. Jamais un vendredi, jamais la veille d'un pic commercial. Gel du catalogue la veille, dernier import différentiel, bascule du domaine le matin, contrôles dans la foulée.
- Semaines suivantes — surveillance. 404, positions, taux de conversion, et corrections immédiates.
Le facteur limitant n'est presque jamais le catalogue : ce sont les modules à remplacer, les règles commerciales à reconstruire et les contenus à reprendre.
Migration ou refonte : ce n'est pas la même chose
Les deux mots circulent ensemble, ils ne désignent pas le même projet. Une migration change de plateforme : les données déménagent, les adresses changent, le SEO est en jeu. Une refonte change le site : design, parcours, contenus, sans forcément changer de plateforme.
Quitter PrestaShop pour Shopify impose la migration. La question est de savoir si vous en profitez pour refondre en même temps.
Faire les deux d'un coup évite de payer deux fois le travail d'intégration et de vivre deux périodes d'instabilité. C'est le choix de la plupart des marques : on ne reconduit pas sur Shopify un design qu'on trouvait déjà daté.
Séparer les deux a un mérite : si le trafic baisse après la bascule, vous savez à quoi l'attribuer. Avec une migration et une refonte simultanées, la cause d'une variation est toujours discutable. C'est le choix des marques dont le SEO pèse très lourd dans l'acquisition.
Les questions que vos équipes vont poser
Une migration n'est pas qu'un projet technique. Les trois questions qui reviennent, et ce qu'il faut préparer :
- Le service client : « comment je retrouve une commande passée avant la bascule ? » L'historique est repris, donc la réponse est « au même endroit » — à condition d'avoir importé les commandes, et pas seulement les clients. C'est un arbitrage à prendre tôt.
- Le marketing : « qu'est-ce qui casse dans mes campagnes ? » Les flux produits vers Google et les places de marché se refont, les liens des e-mails automatiques pointent vers d'anciennes adresses — redirigées, mais autant les mettre à jour — et les identifiants de mesure se reposent.
- La logistique : « est-ce que les commandes arrivent toujours dans mon outil ? » C'est le flux à tester en premier sur la boutique de test, et à surveiller en double les premiers jours.
Les trente premiers jours après la bascule
La mise en ligne n'est pas la fin du projet, c'est le début de la période où les erreurs se voient encore.
Semaine 1 : surveillance quotidienne des erreurs 404, des commandes qui remontent dans les outils, des e-mails transactionnels réellement reçus, et du taux de conversion comparé à la même période de l'année précédente.
Semaines 2 et 3 : contrôle de l'indexation — pages indexées, redirections prises en compte, plan du site envoyé — et remise en route progressive des budgets publicitaires, qu'on n'augmente pas le jour de la bascule.
Semaine 4 : premier bilan chiffré. Positions sur les requêtes principales, trafic par canal, conversion par appareil. C'est le moment de corriger ce qui a été laissé de côté pendant la course, avant que ça devienne l'habitude.
Notre méthode, étape par étape
Tout ce qui précède décrit le projet en général. Voici comment nous le menons chez Moon Moon, dans l'ordre où les choses se passent réellement. La méthode repose sur trois principes : la rigueur technique, la transparence sur les arbitrages, et l'autonomie de vos équipes à la fin du projet.
1. L'audit, avant la moindre ligne de code
Nous commençons par cartographier l'existant : structure technique, contenus, données, connexions avec les outils tiers, contraintes propres à votre commerce. Concrètement, nous listons les systèmes qui détiennent la donnée — CMS, ERP, PIM, CRM — les typologies à reprendre (produits, collections, clients, commandes, pages, articles, réductions, règles de fidélité) et les particularités de chaque base : champs personnalisés, structures imbriquées, formats de date ou de prix.
Cet inventaire produit le plan de migration, où chaque champ est mis en correspondance un par un avec son équivalent Shopify. Parfois il faut fusionner — « description courte » et « description longue » deviennent une seule description produit. Parfois il faut séparer : un champ « caractéristiques techniques » composite éclate en plusieurs métachamps, plus simples à gérer au quotidien. Les cas particuliers se décident à ce moment-là, avec vous et, si nécessaire, vos autres prestataires : produits configurables, déclinaisons complexes, multi-stock, ventes B2B, règles de TVA spécifiques.
2. Le mapping, puis la migration des données
Les données sont extraites de la source — CMS ou base SQL — et nettoyées avant l'import : normalisation des dates et des prix, suppression du HTML parasite dans les descriptions, réorganisation des catégories, élimination des doublons et des données mortes.
Nous testons toujours sur un échantillon avant l'import global : une cinquantaine de produits, de clients et de commandes, puis comparaison ligne à ligne entre la source et la destination. Ce va-et-vient est ce qui garantit que les champs, les relations et les contenus arrivent intacts — pas la taille du script.
3. Les cas particuliers et les intégrations
Chaque boutique a ses exceptions : programme de fidélité, prix dégressifs, abonnements, lots dynamiques, connecteur ERP. Elles sont identifiées pendant l'audit, et nous décidons ensemble de la façon de les transposer — une application spécialisée quand elle fait le travail, un ajustement de la structure de données ou un développement sur mesure quand elle ne le fait pas.
Chaque arbitrage est consigné dans un document technique partagé. Six mois plus tard, quand une question revient, la réponse et sa raison sont écrites quelque part.
4. La migration quand il y a aussi une refonte
La migration n'est presque jamais isolée. Nous travaillons en parallèle de la conception design et avant l'intégration front, pour que les maquettes soient intégrées dans un environnement alimenté en vraies données — pas en contenu de démonstration qui masque les cas limites.
- Audit et cadrage technique : l'existant et les flux de données.
- Cartographie et mapping : comment chaque donnée sera transposée.
- Migration test : un premier import sur un environnement de test.
- Design en parallèle : pendant la migration, les maquettes se conçoivent.
- Migration complète : après validation, l'intégralité des données.
- Intégration front : les maquettes sur la base de la donnée migrée.
- Recette et mise en ligne : vérifications, DNS, redirections, tests fonctionnels.
5. Le SEO et les redirections
Le plan de redirections est construit pendant le projet, pas la veille de la bascule : export exhaustif des anciennes adresses, table de correspondance, chargement avant la mise en ligne, contrôle en masse des codes de réponse juste après. C'est le point détaillé plus haut, et c'est celui sur lequel se joue la conservation du trafic acquis.
6. La bascule
Le jour J tient en trois gestes : bascule du DNS vers Shopify, vérification des certificats SSL, activation des redirections préparées. Selon votre organisation, la manipulation est faite par votre DSI ou par nous. Une fois la boutique accessible, nous reprenons le site à la main : parcours d'achat complet, liens internes, fiches produits, contenus éditoriaux, formulaires.
7. La formation, et ce qui vient après
Notre mission ne s'arrête pas à la mise en ligne. Nous tenons à rendre les équipes autonomes : créneaux de formation adaptés aux métiers (e-commerce, marketing, produit), tutoriels vidéo enregistrés sur votre configuration réelle, documentation partagée. Dans les semaines qui suivent, nous restons disponibles pour les questions, les ajustements et la stabilité de la boutique.
Chaque migration est co-construite : nous centralisons, documentons et exécutons la partie technique, en gardant le lien avec vos équipes internes et vos prestataires — SEO, CRM, logistique, ERP. C'est cette coordination qui évite les zones d'ombre, là où les données se perdent.
