Une migration PrestaShop réussie est invisible : les clients ne remarquent rien, Google non plus, et le marchand découvre simplement un back-office plus rapide et des possibilités qu'il n'avait pas. Une migration ratée, à l'inverse, se voit immédiatement : chiffre d'affaires en baisse, positions Google perdues, commandes ou comptes clients disparus.
La différence entre les deux ne tient ni à la chance ni au budget, mais à la méthode. Ce guide rassemble ce que nous appliquons sur chaque migration depuis 2020 : quelle version viser en 2026, combien cela coûte réellement, quels sont les vrais risques SEO et comment basculer sans couper la boutique.
Pourquoi 2026 est l'année où il ne faut plus attendre
Beaucoup de boutiques françaises tournent encore sur PrestaShop 1.6 ou 1.7. Elles fonctionnent, encaissent, et c'est précisément ce qui rend la décision difficile : pourquoi toucher à quelque chose qui marche ?
Trois raisons, concrètes et datées.
La sécurité d'abord. PrestaShop 1.6 n'est plus maintenu depuis juin 2019, et la branche 1.7 ne reçoit plus de correctifs. Chaque faille découverte depuis reste ouverte sur votre boutique. Les vagues d'attaques automatisées qui ciblent les vieilles versions de PrestaShop ne relèvent pas de la théorie : elles injectent des skimmers de cartes bancaires dans le tunnel de paiement, et le marchand ne s'en aperçoit souvent qu'après les premiers signalements de clients débités frauduleusement. Sur un site qui manipule des données de paiement, exploiter une version abandonnée est aussi un risque juridique au regard du RGPD.
PHP ensuite. Les versions de PHP compatibles avec PrestaShop 1.6 et 1.7 (5.6 à 7.4) sont toutes en fin de vie depuis des années, comme le montre le calendrier officiel des versions PHP. Les hébergeurs les retirent progressivement de leurs offres : le jour où votre hébergeur coupe PHP 7.4, votre boutique s'arrête, et la migration se fait alors dans l'urgence, c'est-à-dire dans les pires conditions possibles.
L'écosystème enfin. Les éditeurs de modules et de solutions de paiement concentrent leurs développements sur PrestaShop 8 et 9. Les modules critiques (paiement, transport, facturation) cessent un à un d'être mis à jour pour les vieilles branches. Vous ne le voyez pas au quotidien, jusqu'au jour où votre PSP annonce une évolution d'API obligatoire que votre version de module ne suivra pas.
Autrement dit : le coût d'une migration est connu et planifiable. Le coût de l'immobilisme est inconnu, mais il tombe toujours au pire moment.
Quelle version cible en 2026 : PrestaShop 9, sans débat
La question ne se pose plus vraiment. PrestaShop 9, sorti en 2025, est la version activement développée. Voici la situation des branches en 2026 :
| Version | Sortie | Statut en 2026 | PHP |
|---|---|---|---|
| 1.6 | 2014 | Abandonnée depuis 2019 | 5.6 à 7.1 |
| 1.7 | 2016 | Fin de support | 7.1 à 7.4 |
| 8.x | 2022 | Maintenance, fin de cycle | 7.2 à 8.1 |
| 9.x | 2025 | Version active | 8.1 minimum |
Migrer vers PrestaShop 8 en 2026 serait une erreur stratégique : vous paieriez le prix d'une migration pour atterrir sur une version dont le cycle se termine, avec une seconde migration à financer d'ici deux ou trois ans. PrestaShop 9 apporte par ailleurs des fondations qui comptent pour la suite :
- PHP 8.1+ et Symfony 6.4 : des performances serveur nettement supérieures aux branches précédentes et un socle maintenu pour des années.
- Un one page checkout natif : la dernière version de PrestaShop 9 intègre enfin un tunnel de commande sur une seule page, là où les anciennes versions imposaient un module tiers pour y arriver. C'est loin d'être un détail : sur les boutiques dont nous mesurons le tunnel, chaque étape supprimée entre le panier et le paiement se lit directement dans le taux de conversion. Migrer, c'est aussi récupérer ce checkout moderne sans surcoût.
- La nouvelle API d'administration : elle change la donne pour connecter un ERP, un PIM ou n'importe quel outil métier proprement, sans les webservices bricolés de l'époque 1.6.
- Un back-office modernisé : moins spectaculaire sur le papier, mais vos équipes y passent leurs journées.
C'est la version que nous déployons sur tous nos projets, en création comme en migration PrestaShop.
Combien coûte réellement une migration PrestaShop
C'est la question que tout le monde pose et à laquelle presque personne ne répond avec des chiffres. Voici les fourchettes que nous constatons en 2026, pour un travail sérieux (pas un import de données lancé sans vérification) :
| Scénario | Fourchette | Ce qui est compris |
|---|---|---|
| 1.7 récente vers 9, thème compatible | 3 000 à 6 000 € | Montée de version, audit modules, recette complète, bascule |
| 1.7 vers 9 avec refonte du thème | 6 000 à 15 000 € | Idem + nouveau thème sur mesure ou adaptation lourde |
| 1.6 vers 9 | 5 000 à 12 000 € | Installation neuve, migration des données, remplacement thème et modules |
| WooCommerce, Magento ou Shopify vers 9 | 6 000 à 15 000 € | Migration complète des données, mapping catalogue, redirections, thème |
| Boutique complexe (ERP, multiboutique, gros catalogue) | 12 000 à 30 000 €+ | Idem + reprise des intégrations, scripts de migration spécifiques |
Trois facteurs expliquent l'essentiel des écarts :
- Les modules. Chaque module de l'ancienne boutique doit être audité : existe-t-il en version compatible PrestaShop 9 ? Faut-il racheter une licence, trouver un équivalent, ou redévelopper ? Une boutique 1.6 chargée de 80 modules accumulés en dix ans coûte plus cher à migrer que son catalogue ne le laisse penser. C'est aussi une opportunité : sur la plupart des migrations que nous menons, un tiers des modules ne sert plus à rien et disparaît purement et simplement.
- Le thème. Un thème 1.6 ou 1.7 n'est jamais réutilisable tel quel sur PrestaShop 9. Il faut soit acheter et adapter un thème du marché, soit développer sur mesure. C'est le poste le plus visible du budget, et le bon moment pour corriger ce que l'ancien design faisait mal.
- Les données et intégrations. Migrer 500 produits est trivial. Migrer 40 000 références avec déclinaisons, historiques de commandes sur dix ans, avoirs, points de fidélité et une synchronisation ERP demande des scripts spécifiques et des recettes minutieuses.
Méfiez-vous des devis très en dessous de ces fourchettes : ils signifient généralement qu'un point critique (redirections SEO, recette des données, modules) n'a pas été chiffré, et vous le paierez après la mise en ligne, au prix fort.
Le vrai risque d'une migration, c'est le SEO
Perdre des données se voit tout de suite et se corrige. Perdre son référencement se voit six semaines plus tard, quand le trafic organique a décroché, et se répare en plusieurs mois. C'est le risque numéro un d'une migration, et il se neutralise presque entièrement en préparation.
Les URLs, d'abord et avant tout
Chaque plateforme et chaque version génère ses propres formats d'URLs. Une fiche produit /12-nom-du-produit.html en 1.6 ne sera pas servie à l'identique par PrestaShop 9 sans configuration, et une migration depuis WooCommerce ou Shopify change la totalité des chemins.
La méthode est connue mais rarement appliquée jusqu'au bout :
- Inventaire exhaustif des URLs existantes avant migration : crawl complet du site, export Search Console (toutes les pages qui reçoivent des impressions), logs serveur pour attraper les URLs historiques qui reçoivent encore du trafic.
- Table de correspondance ancienne URL vers nouvelle URL, page par page. Pas de redirection générique vers la home : une redirection 301 doit envoyer vers la page équivalente, sinon Google la traite comme une soft 404.
- Redirections 301 au niveau serveur (Nginx ou Apache), pas via un module : c'est plus rapide, plus fiable, et cela survit aux mises à jour.
- Code 410 assumé pour les pages volontairement supprimées, plutôt qu'un 404 ambigu : Google désindexe plus vite et arrête de gaspiller son budget de crawl.
Ce qui disparaît avec l'ancien thème
Les balises title et meta description travaillées au fil des ans, les données structurées (Product, Offer, avis), le maillage interne construit dans les descriptions : tout cela vit en partie dans le thème et les modules SEO de l'ancienne boutique. Si personne ne fait l'inventaire avant, personne ne remarque la perte après, sauf Google. L'audit SEO pré-migration doit lister exactement ce qui existe, pour tout reconstruire à l'identique ou en mieux.
La performance, juge de paix
Une migration vers PrestaShop 9 bien exécutée améliore mécaniquement les Core Web Vitals : PHP 8 est plus rapide, et un thème neuf est l'occasion de repartir sur des bases saines (images au bon format, CSS et JavaScript maîtrisés). Mais l'inverse est vrai aussi : un thème du marché surchargé de fonctionnalités peut dégrader les temps de chargement par rapport à l'ancienne boutique. Nous mesurons systématiquement avant et après, sur les mêmes pages types (home, catégorie, produit), et la nouvelle boutique ne part pas en production si elle est plus lente que l'ancienne.
Les semaines qui suivent la bascule
Le travail SEO ne s'arrête pas le jour de la mise en ligne. Pendant quatre à six semaines, il faut surveiller la Search Console : erreurs de couverture, pages 404 imprévues, chute d'indexation sur un segment. Détectée dans la semaine, une anomalie se corrige sans dégât. Découverte deux mois après, elle a déjà coûté des positions.
La méthode zéro downtime, étape par étape
Une inquiétude légitime des marchands : combien de temps la boutique sera-t-elle fermée ? La réponse, avec une méthode sérieuse : quelques minutes, en heures creuses. Voici le déroulé que nous appliquons.
1. Audit et cadrage
Inventaire complet de l'existant : versions, modules et leur devenir, thème, intégrations (ERP, logistique, paiement, flux marketplaces), volumétrie des données, inventaire SEO (URLs, positions, balisage). C'est ce document qui rend le devis fiable et le planning tenable.
2. Construction en préproduction
PrestaShop 9 est installé sur un environnement de préproduction, avec le nouveau thème et les modules retenus. Les données (catalogue, clients, commandes, avoirs, historiques) sont migrées une première fois avec des scripts rejouables. Ce point est décisif : la migration des données doit pouvoir être relancée à volonté, car elle sera exécutée une dernière fois le jour de la bascule.
3. Recette complète
On teste comme un client et comme un gestionnaire : commande de bout en bout avec chaque moyen de paiement, calculs de frais de port sur les cas réels, comptes clients migrés (connexion, historiques), règles de promotion, factures, exports comptables, synchronisation ERP. Puis recette SEO : les redirections 301 sont testées sur l'inventaire complet d'URLs, en préproduction, avant la bascule, jamais après.
4. Bascule
Programmée en heures creuses. L'ancienne boutique passe en lecture seule quelques minutes, le temps de resynchroniser les commandes et clients créés depuis la dernière migration de données. Le trafic bascule ensuite vers la nouvelle boutique (changement de configuration serveur ou de DNS selon l'infrastructure). L'ancienne boutique reste intacte et redémarrable : c'est le plan de retour arrière, qui rassure tout le monde et ne sert presque jamais.
5. Surveillance renforcée
Les deux premières semaines : logs serveur, taux d'erreur, tunnels de commande, Search Console, temps de réponse. Les anomalies détectées à ce stade se corrigent en heures.
Et après la bascule : mesurer, pas supposer
Une migration change tout en même temps : plateforme, thème, parcours d'achat. Si le chiffre d'affaires bouge dans les semaines qui suivent, il faut pouvoir dire pourquoi. C'est une des raisons pour lesquelles nous avons construit Sqalie, notre outil d'analytics pour PrestaShop : brancher la mesure directement sur les données de la boutique (chiffre d'affaires, marge, canaux, conversion) permet de comparer l'avant et l'après migration sur des chiffres fiables, sans dépendre d'un tracking GA4 qui a justement été chamboulé par la refonte. Quel que soit l'outil, le principe demeure : figez vos indicateurs de référence avant la migration, et comparez sur au moins un mois complet après.
Les cas particuliers : d'où venez-vous ?
Depuis PrestaShop 1.6 ou 1.7
Le cas le plus fréquent en France. Depuis une 1.7 récente, une montée de version outillée est possible ; depuis une 1.6, l'écart technique impose une installation neuve de PrestaShop 9 avec migration des données. Dans les deux cas, la vraie charge de travail est dans les modules et le thème, pas dans les données. Nous y consacrerons un article dédié.
Depuis WooCommerce
Motivation classique : la boutique a grandi et WordPress montre ses limites (performances sous charge, gestion multi-transporteurs, comptabilité, déclinaisons complexes). La migration porte sur le mapping du catalogue (les attributs WooCommerce vers les déclinaisons et caractéristiques PrestaShop), la reprise des clients avec leurs mots de passe invalidés proprement, et un plan de redirections total puisque toutes les URLs changent.
Depuis Magento
Souvent une question de coût de possession : Magento (Adobe Commerce) exige des budgets d'infrastructure et de maintenance que PrestaShop divise nettement, pour un périmètre fonctionnel comparable sur la plupart des catalogues.
Depuis Shopify
Le mouvement inverse de celui que le marché raconte. Les marchands qui quittent Shopify le font pour reprendre le contrôle : commissions et abonnements qui grimpent avec le volume, dépendance aux apps mensualisées, personnalisation limitée, données hébergées chez un tiers. PrestaShop 9 en auto-hébergé rend la maîtrise du coût total et des données. Le point de vigilance est le SEO : Shopify impose ses formats d'URLs (/products/, /collections/), et le plan de redirections doit être irréprochable.
Les cinq erreurs qui coûtent le plus cher
Après une vingtaine de migrations, ce sont toujours les mêmes :
- Migrer sans inventaire SEO. L'erreur la plus coûteuse et la plus fréquente. Les redirections improvisées après la bascule, quand le trafic a déjà décroché.
- Reproduire l'existant à l'identique, dette comprise. Une migration est le seul moment où faire le tri ne coûte presque rien : modules inutiles, catégories vides, contenus obsolètes. Les remigrer, c'est payer pour conserver ses problèmes.
- Recetter sur un échantillon. Les dix produits testés fonctionnent, le produit 8 412 avec sa déclinaison exotique casse le tunnel. Les recettes de données doivent être exhaustives et scriptées, pas manuelles.
- Basculer sans plan de retour arrière. Même inutilisé, il change tout : les décisions du jour J se prennent sereinement au lieu de se prendre dans la panique.
- Considérer la mise en ligne comme la fin du projet. Les six semaines de surveillance qui suivent font partie de la migration. C'est là que se joue la conservation du référencement.
Comment choisir qui fera votre migration
Quelques questions simples permettent de trier rapidement les prestataires :
- Demandez le plan de redirections. Si la réponse est vague ou si le sujet n'apparaît pas dans le devis, le risque SEO n'est pas maîtrisé.
- Demandez comment se passe la bascule. La bonne réponse décrit une préproduction, une resynchronisation finale et un retour arrière possible. La mauvaise réponse parle d'un site en maintenance pendant plusieurs jours.
- Demandez des migrations comparables à la vôtre, avec les problèmes rencontrés. Un prestataire qui raconte ce qui s'est mal passé et comment il l'a géré est plus crédible qu'un portfolio sans accroc.
- Vérifiez que PrestaShop est son métier, pas une ligne parmi douze CMS. Les pièges d'une migration PrestaShop sont spécifiques : quelqu'un qui en fait régulièrement les connaît déjà.
Chez Acencia, la migration est un de nos deux métiers principaux avec la création de boutiques. Si vous préparez la vôtre, parlons-en : le premier échange sert à évaluer honnêtement la complexité de votre cas, et repartir avec un avis clair ne vous engage à rien.
