Written by Si vous gérez encore une boutique sous PrestaShop 1.6 ou 1.7, vous avez probablement déjà entendu parler de la nécessité de migrer. PrestaShop 1.6 n’est plus maintenu depuis plusieurs années, et PrestaShop 1.7 a officiellement atteint sa fin de vie. Entre-temps, PrestaShop 8 s’est stabilisé et PrestaShop 9 vient de sortir avec une architecture Symfony 6.4 et PHP 8.3. La question n’est donc plus « faut-il migrer ? » mais « comment faire sans tout casser ? »
Voici ce que personne ne vous dit vraiment avant de démarrer le chantier.
Ce qui attend les boutiques PrestaShop 1.6 non migrées
Une boutique PrestaShop 1.6 encore en production en 2026, c’est une boutique qui tourne sur PHP 7.x au maximum, avec des modules souvent non maintenus et un thème qui date. Les risques sont concrets : incompatibilités croissantes avec les serveurs modernes, failles de sécurité non corrigées, et surtout des prestataires qui commencent à refuser de toucher à ces installations.
Ce n’est pas une catastrophe imminente, mais c’est une bombe à retardement. Et plus on attend, plus le coût de la migration augmente, parce que l’écart technique entre PS 1.6 et PS 9 grandit chaque mois.
Les trois chemins possibles
Des modules comme MigrationPro ou LitExtension permettent de transférer les données (produits, clients, commandes, catégories) d’une version de PrestaShop à une autre. C’est la solution la moins chère sur le papier, et elle fonctionne bien dans un cas précis : une boutique avec un thème standard, des modules natifs uniquement, et un volume de données modéré. Les limites apparaissent vite dès qu’on sort de ce cadre. Ces modules migrent les données, mais ils ne gèrent pas les redirections SEO. Or les structures d’URL entre PS 1.6 et PS 8 sont très différentes. Sans un plan de redirections 301 exhaustif mis en place avant le Go-Live, vous pouvez perdre 30 à 50% de votre trafic organique en quelques semaines, et le récupérer prend des mois.
Faire appel à un prestataire spécialisé, c’est l’option qui fait peur sur le budget mais qui est souvent la plus rentable sur le total. Un prestataire apporte une chose que les modules ne peuvent pas : l’expérience des cas qui dérapent. Un module cassé silencieusement (un calcul de TVA erroné, une remise qui ne s’applique plus, un email transactionnel qui ne part plus) peut coûter bien plus qu’une prestation de migration si on le découvre trois semaines après le Go-Live. La clé est de choisir quelqu’un qui travaille sur un serveur miroir, jamais directement en production, et qui intègre une phase de recette exhaustive avant la bascule, redirections 301 incluses.
Pour les boutiques avec beaucoup de données mais peu de personnalisation, l’approche hybride est aussi une option : un module pour la migration des données, un développeur pour le thème et les redirections. C’est valable, à condition de bien coordonner les deux intervenants et de ne pas sous-estimer la partie SEO.
Le coût réel d’une migration : ce qui fait exploser les budgets
Quand un marchand reçoit un devis de migration et qu’il le trouve élevé, c’est souvent parce qu’il n’a pas intégré tous les postes. La migration des données en elle-même n’est qu’une partie du travail.
Le thème est le premier poste sous-estimé. Un thème PrestaShop 1.6 ne fonctionne pas sur PS 8 ou PS 9, l’architecture étant incompatible. Il faut soit le reconstruire pour la nouvelle version, soit saisir l’occasion pour en créer un nouveau. Dans les deux cas, c’est du développement front-end qui s’ajoute à la migration des données, et ça se chiffre en jours de travail.
Le deuxième facteur d’explosion de budget, ce sont les modules personnalisés. Un module acheté sur PrestaShop Addons a souvent une version compatible PS 8, mais si ce module a été modifié en interne pour s’adapter à votre boutique, la version standard ne reprendra pas ces personnalisations. Il faut les re-développer. Un audit de compatibilité des modules avant de commencer permet d’éviter les mauvaises surprises et de chiffrer correctement le projet.
Les redirections SEO restent le poste le plus souvent oublié. Pour une boutique avec 500 références et quelques dizaines de catégories, établir une table de redirections exhaustive et la tester prend plusieurs jours de travail. C’est pourtant ce qui protège l’investissement SEO des années précédentes.
PS 8 ou PS 9 : comment choisir ?
La règle pratique : si vous avez plus de cinq modules personnalisés ou un thème entièrement sur mesure, préférez PS 8.2. La migration est plus rapide, la compatibilité modules est meilleure (95% des modules PS 1.7 passent sans réécriture), et la version est mature et stable en production.
PS 9 est le bon choix si vous faites une refonte complète en même temps : nouveau thème, stack technique propre, souhait de profiter de Symfony 6.4 et PHP 8.3 sur le long terme. L’architecture est meilleure sur cinq ans, mais le coût d’adaptation est plus conséquent. Depuis PS 1.6 spécifiquement, migrer directement vers PS 9 peut s’avérer très coûteux à cause de l’écart architectural. Une étape intermédiaire via PS 8.2 est souvent plus rapide et moins risquée.
Par où commencer concrètement
Avant de contacter le moindre prestataire ou de télécharger un module de migration, le travail préalable le plus utile est de lister tous vos modules et de vérifier leur statut sur PrestaShop Addons : existe-t-il une version PS 8/9 compatible, et ce module a-t-il été modifié en interne ? C’est ce travail qui permet de chiffrer correctement un projet et d’éviter les mauvaises surprises en cours de route. Dans le même temps, faire crawler votre boutique actuelle avec un outil comme Screaming Frog permet de cartographier toutes les URLs indexées, ce qui servira de base au plan de redirections 301. Ce travail doit être fait avant la migration, pas après.
Si vous voulez une évaluation rapide de votre situation (version actuelle, modules, risques), migration-prestashop.com propose un audit en ligne gratuit avec une estimation indicative immédiate.
Guillaume MEYERZ est spécialiste de la migration PrestaShop. Il accompagne les marchands français dans leurs migrations PS 1.6/1.7 vers PS 8 et PS 9, avec un protocole intégrant audit de compatibilité, redirections SEO, migration sur serveur miroir et monitoring post-Go-Live.