Migration PrestaShop vers Shopify : méthode, risques et checklist
Sommaire
Migrer un catalogue PrestaShop vers Shopify n’est jamais un simple export/import. La vraie complexité se situe dans la modélisation de la hiérarchie catalogue et dans la reconstruction des flux fournisseurs, qui sur PrestaShop étaient souvent gérés à la main ou via des modules introuvables sur Shopify.
Voici la méthode, illustrée par un projet réel : 440 catégories PrestaShop migrées vers Shopify pour un e-commerce meubles et décoration, sans perdre le trafic organique accumulé depuis des années.
Le point de départ
Le site tournait sur PrestaShop depuis longtemps, avec un catalogue riche en profondeur : 440 catégories organisées en plusieurs niveaux de hiérarchie, des dizaines de fournisseurs, et des flux de commande spécifiques à chaque partenaire. La maintenance devenait chronophage, la sécurité du CMS demandait une vigilance constante, et le hosting montrait ses limites face à la volumétrie du catalogue.
L’objectif : passer sur Shopify pour l’admin et le checkout, avec un storefront Hydrogen custom pour garder la richesse du catalogue meubles, sans rien perdre du référencement existant.
Quelles données migrer ?
C’est la première question à trancher, et elle mérite mieux qu’un « tout ». Sur un replatforming PrestaShop, l’inventaire porte généralement sur :
- les produits : références, descriptions, prix, déclinaisons devenues variantes Shopify, attributs, images ;
- les catégories : libellés, arborescence complète, métadonnées SEO, position dans l’arbre ;
- les URLs : chaque URL indexée doit être recensée avant toute décision de structure ;
- les clients : comptes, adresses, historique, en tenant compte du fait que les mots de passe ne se migrent pas (ils devront être réinitialisés) ;
- les commandes : historique à conserver pour le service client et la comptabilité, parfois importé en lecture seule ;
- les contenus éditoriaux : pages CMS, articles de blog, guides d’achat, qui portent souvent une part importante du trafic organique ;
- les données spécifiques : stocks, règles de prix, relations fournisseurs, champs custom issus de modules PrestaShop.
Le point d’attention le plus fréquent : les champs custom créés par des modules PrestaShop n’ont pas d’équivalent direct dans Shopify. Il faut décider pour chacun s’il devient un metafield, s’il est abandonné, ou s’il migre dans un système externe.
La contrainte principale : la hiérarchie de catégories
PrestaShop et Shopify ne modélisent pas les catégories de la même façon. PrestaShop gère une arborescence native profonde. Shopify fonctionne par collections, plus plates par défaut. Reproduire fidèlement 440 catégories avec leurs relations parent/enfant demandait une couche supplémentaire.
La solution retenue : un système de metafields avec un type collection_reference permettant de reconstruire la hiérarchie parent au niveau de chaque collection Shopify. Chaque collection connaît sa position exacte dans l’arborescence d’origine, ce qui permet de reproduire à l’identique le fil d’Ariane et la navigation, deux éléments critiques pour le SEO d’un catalogue profond.
L’architecture mise en place
Le projet ne se limitait pas au storefront. Un ERP custom a été construit pour gérer ce que Shopify ne couvre pas nativement dans un contexte multi-fournisseurs :
Base de données Supabase structurée autour de plusieurs tables clés : fournisseurs, variantes produit, imports de catalogue fournisseur, file de synchronisation Shopify, commandes.
Synchronisation événementielle plutôt que par cron. Plutôt qu’un job planifié qui tourne toutes les X minutes, l’architecture repose sur une file de synchronisation déclenchée par événement via des Server Actions Next.js. Un changement chez un fournisseur déclenche immédiatement la mise à jour côté Shopify, sans attendre le prochain passage du cron.
Une vingtaine de fournisseurs intégrés avec leurs propres templates de commande et leurs spécificités de flux, chacun avec ses règles propres de formatage et de fréquence d’import.
Automatisation n8n pour orchestrer les tâches récurrentes entre les différents systèmes (import catalogue, alertes stock, relances fournisseurs).
Comment conserver le SEO ?
Avec 440 catégories, la moindre approximation dans le plan de redirections peut faire perdre un pan entier du trafic organique. La méthode suivie, applicable à tout replatforming PrestaShop :
- Export complet de l’arborescence PrestaShop avec toutes les métadonnées associées (title, description, URL, position dans l’arbre).
- Mapping systématique de chaque catégorie PrestaShop vers sa collection Shopify correspondante, avec conservation du slug d’URL quand c’était possible.
- Plan de redirections 301 pour les URLs qui ne pouvaient pas être conservées à l’identique, testé avant bascule et non après.
- Reconstruction des metafields de hiérarchie pour que la navigation et le fil d’Ariane reflètent exactement l’ancienne structure.
- Vérification manuelle des catégories à fort trafic avant bascule, en priorité : ce sont elles qui portent l’essentiel du chiffre d’affaires organique.
À cela s’ajoutent les vérifications classiques mais indispensables : balises title et meta description reprises page par page, URLs canoniques, données structurées produit et fil d’Ariane, sitemap régénéré, robots.txt, et surtout un suivi Search Console renforcé les semaines suivant la bascule pour détecter immédiatement les erreurs d’indexation.
Le piège le plus courant sur PrestaShop : les URLs générées par des modules (filtres à facettes, pages de recherche, variantes d’affichage) qui se sont indexées au fil des années. Il faut décider ce qui doit être redirigé, ce qui doit être laissé en 410 et ce qui doit simplement disparaître de l’index.
Que faire de l’ERP et des flux existants ?
C’est le poste que les migrations sous-estiment le plus. Sur PrestaShop, une partie de la logique métier vit souvent dans des modules, des scripts maison ou des exports manuels accumulés pendant des années.
Avant de toucher au code, il faut répondre à quelques questions structurantes :
- quelle plateforme est la source de vérité pour les stocks et les prix ?
- où sont calculées les règles de prix spécifiques (remises fournisseur, tarifs pro) ?
- comment les données arrivent dans Shopify, et à quelle fréquence ?
- quels flux doivent être synchrones et lesquels peuvent être différés ?
- que se passe-t-il quand un fournisseur ou un service externe ne répond plus ?
Sur le projet meubles, la réponse a été de construire un ERP dédié plutôt que d’empiler des apps : les contraintes croisées (une vingtaine de fournisseurs, formats d’import hétérogènes, synchronisation temps réel) ne se modélisaient proprement dans aucune solution du marché. Ce choix n’est pas systématique, mais il doit être posé explicitement au moment de l’audit, pas découvert en cours de développement.
Combien de temps prévoir ?
Un replatforming PrestaShop vers Shopify est plus long qu’une simple refonte de storefront, parce qu’il cumule deux chantiers : la migration des données et la reconstruction du front.
En ordre de grandeur :
- catalogue standard, peu de flux externes : 6 à 8 semaines ;
- catalogue profond avec historique SEO à préserver : 8 à 12 semaines ;
- catalogue multi-fournisseurs avec ERP et synchronisation temps réel : 12 à 16 semaines, comme sur le projet décrit ici.
La phase qui s’allonge n’est presque jamais le développement des templates, ce sont la modélisation du catalogue et la reconstruction des flux. J’ai détaillé le découpage phase par phase dans combien de temps prévoir pour une migration Hydrogen.
Liquid ou Hydrogen après PrestaShop ?
Quitter PrestaShop ne veut pas dire passer automatiquement en headless. Les deux options sont valables, et le choix dépend de ce qui posait problème sur l’ancien site.
Un thème Liquid suffit généralement quand le catalogue redevient standard une fois migré, que la navigation peut se simplifier sans perte, et que les équipes veulent garder la main sur le contenu via le Theme Editor. C’est aussi le scénario le plus rapide et le moins coûteux.
Hydrogen se justifie quand la richesse du catalogue PrestaShop est précisément ce qu’il faut préserver : hiérarchie profonde, navigation spécifique, filtres métier, ou besoin d’interroger un ERP depuis le front. C’était le cas sur ce projet : reproduire 440 catégories avec leur arborescence et leur fil d’Ariane dépassait ce qu’un thème standard modélise proprement.
Le comparatif détaillé des deux architectures est ici : Shopify Liquid vs Hydrogen. Si l’architecture headless est l’option retenue, le parcours de migration Shopify vers Hydrogen détaille comment le storefront est construit en parallèle de la migration des données.
Ce qui a été préservé
Au final, la hiérarchie de collections et les metafields ont été conservés dans leur intégralité pour un catalogue meubles particulièrement riche, avec une synchronisation ERP tournant en temps réel plutôt qu’en batch.
Ce qu’il faut retenir
Un replatforming PrestaShop vers Shopify se joue sur deux fronts : la modélisation de la hiérarchie catalogue et la reconstruction des flux fournisseurs. C’est ce travail de modélisation, fait avant la première ligne de code, qui détermine si le SEO survit à la migration ou non.
Si votre catalogue est dans ce cas de figure, le parcours de migration CMS vers Shopify détaille comment l’audit de structure et la reconstruction de la hiérarchie sont menés avant toute bascule.