# Migrer votre boutique PrestaShop vers 1.7, 8 ou 9 > Passer de PrestaShop 1.6 à 1.7, 8 ou 9 n’est pas une mise à jour classique : le moteur de thème change complètement, le back-office bascule progressivement sur Symfony, et une bonne partie des modules 1.6 ne fonctionne plus telle quelle. - Source canonique : [https://allaux.fr/prestashop/migration](https://allaux.fr/prestashop/migration) - Langue : FR - Dernière mise à jour : 2026-09-30 ## Réponse directe > Relevez d’abord votre version exacte dans Paramètres avancés > Informations, puis la version de PHP disponible chez votre hébergeur : ces deux chiffres décident seuls de la version d’arrivée atteignable. Dupliquez ensuite fichiers et base sur un environnement de test et menez la migration là, jamais sur la boutique en ligne. ## Pourquoi ce n’est pas une simple mise à jour PrestaShop 1.6 utilise un système de thème basé entièrement sur Smarty et des templates .tpl classiques. À partir de 1.7, une partie de l’administration et certains contrôleurs front reposent sur le framework Symfony, avec une nouvelle arborescence (src/, var/) et un système d’override différent. Le thème par défaut change aussi de nom (Classic à la place de Default), ce qui veut dire concrètement qu’un thème 1.6, même personnalisé, ne s’installe pas tel quel sur 1.7 ou 8 : il faut le reconstruire ou l’adapter template par template. Côté modules, chaque module doit déclarer sa compatibilité avec la version cible dans son fichier de configuration. Un module qui fonctionne parfaitement en 1.6 peut être totalement absent du marché pour 1.7/8, ou nécessiter une version payante différente chez son éditeur. C’est souvent le point qui fait le plus dérailler un budget de migration mal estimé au départ. La structure de la base de données évolue aussi entre les versions majeures (nouvelles tables, colonnes renommées), ce qui impose un script de migration de données plutôt qu’un simple export-import SQL brut. ## Comment je conduis une migration 1. **Audit de l’existant** — Je liste les modules installés, leurs versions, et je vérifie lesquels ont un équivalent compatible avec la version cible. 2. **Migration sur environnement de test** — Je réalise la migration une première fois sur une copie de la boutique, jamais directement en production, pour identifier tous les blocages avant de toucher au site réel. 3. **Reconstruction du thème** — Selon l’écart entre les versions, j’adapte le thème existant ou je le reconstruis sur la base du thème par défaut de la version cible, en conservant l’identité visuelle. 4. **Remplacement des modules incompatibles** — Je trouve des équivalents fonctionnels aux modules qui ne migrent pas, ou je réécris les fonctionnalités spécifiques en module sur mesure si besoin. 5. **Bascule en production** — Une fois la version de test validée avec vous, je programme la bascule à un moment de faible trafic pour limiter l’impact sur les commandes en cours. ## 1.7, 8 ou 9, selon votre situation - **PrestaShop 1.7** — Palier intermédiaire, rarement une cible en soi : c’est la version qu’il faut atteindre avant de continuer vers 8 ou 9 quand on part d’une 1.6, l’outil de mise à jour ne sautant aucun palier. ([/prestashop/migration/1-6-vers-1-7](/prestashop/migration/1-6-vers-1-7)) - **PrestaShop 8** — Cible raisonnable quand l’écosystème de modules de la boutique n’est pas encore déclaré compatible 9, ou quand l’hébergement ne fournit pas encore une version de PHP acceptée par la 9. ([/prestashop/migration/1-7-vers-8](/prestashop/migration/1-7-vers-8)) - **PrestaShop 9** — Dernière branche majeure : back-office entièrement Symfony/Twig, contrôleurs legacy supprimés, exigences PHP plus élevées. Cible naturelle d’un projet neuf, à condition de vérifier module par module. ([/prestashop/migration/8-vers-9](/prestashop/migration/8-vers-9)) - **Rester en 1.6 avec vigilance** — Envisageable à court terme pour une boutique stable, mais 1.6 n’est plus maintenue par l’éditeur, ce qui expose à des failles de sécurité non corrigées. ([/prestashop/migration/1-6-vers-9](/prestashop/migration/1-6-vers-9)) - **Depuis PrestaShop 1.5** — Aucun outil ne fait ce saut : la boutique se reconstruit en 8 et les données sont reprises. Un chantier à cadrer comme une refonte. ([/prestashop/migration/1-5-vers-8](/prestashop/migration/1-5-vers-8)) ## Ce qu'il faut vérifier en amont - **Checklist avant migration** — Sauvegardes, inventaire des modules, version de PHP, plan de retour arrière : ce qui doit être en place avant de toucher à la boutique. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration)) - **Modules incompatibles** — Le poste qui fait dériver le budget : comment savoir lesquels de vos modules ne suivront pas, avant de commencer. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles)) - **Migrer sans perdre le référencement** — Le plan de redirections et les points de contrôle qui évitent de payer la migration en trafic perdu. ([/guides/migrer-sans-perdre-referencement](/guides/migrer-sans-perdre-referencement)) - **Modules qui ne s’installent plus** — Après la montée de version, le module refuse de s’installer ou disparaît du back-office : les causes et les correctifs. ([/prestashop/problemes/module-refuse-installation](/prestashop/problemes/module-refuse-installation)) - **Moyen de paiement disparu après la mise à jour** — Le symptôme le plus coûteux d’une migration mal recettée, et comment le traiter. ([/prestashop/problemes/moyen-paiement-disparait-apres-maj](/prestashop/problemes/moyen-paiement-disparait-apres-maj)) - **Migrer ou refaire ?** — Quand la montée de version coûte presque autant qu’une reconstruction, la question mérite d’être posée franchement. ([/creation/refonte-ou-reparation](/creation/refonte-ou-reparation)) ## Ne migrez jamais directement en production > Une migration se teste toujours sur une copie de la boutique. Ça permet de chiffrer précisément le travail nécessaire sur les modules et le thème avant de m’engager sur un délai ferme. ## FAQ ### Vais-je perdre mes commandes, mes clients ou mon catalogue pendant la migration ? Non, la migration se fait sur une copie de la boutique. Les données de production restent intactes jusqu’à la bascule finale, qui reprend les commandes passées entre-temps. ### Combien de temps dure une migration ? Ça dépend surtout du nombre de modules et de la complexité du thème. Une boutique simple se migre en quelques jours ; une boutique avec des modules sur mesure ou un thème très personnalisé peut demander plusieurs semaines. ### Est-ce que mon référencement va être impacté ? Si les URLs et la structure des pages sont conservées, l’impact est limité. Je fais attention aux redirections et à la structure des balises pour ne pas perdre le référencement acquis. ### Que se passe-t-il si un module n’a pas d’équivalent sur la nouvelle version ? Je cherche d’abord un module équivalent chez un autre éditeur. Si aucune solution du marché ne convient, je développe la fonctionnalité en module sur mesure adapté à la nouvelle architecture. ### Quels accès dois-je vous fournir ? Un accès FTP ou SSH, un accès à la base de données, et l’accès au back-office actuel pour établir l’inventaire des modules et de la configuration.