Migrer de PrestaShop 1.7.8 vers PrestaShop 9
Le saut est important : quatre versions majeures, un changement de framework (Symfony 4.4 → 6.4) et la suppression de plusieurs API historiques. Voici le chemin sûr, les prérequis techniques et les points qui font échouer la plupart des migrations trop rapides.
Pas de saut direct en confiance depuis une 1.7.8
Le module officiel Update Assistant (autoupgrade) sait techniquement mettre à jour depuis n'importe quelle 1.7.x vers une version supérieure en une passe. Mais avec l'âge d'une 1.7.8 (2019-2021), la compatibilité des modules, du thème et des surcharges (override) n'est presque jamais garantie sur un saut aussi large.
Le chemin recommandé passe par une étape intermédiaire en 8.x, qui laisse le temps de corriger les modules avant d'affronter les changements plus profonds de la version 9 (suppression des Helpers legacy, nouveau back-office en Twig).
Prérequis serveur pour PrestaShop 9
À faire valider par votre hébergeur avant toute tentative de mise à jour.
| Composant | Exigence |
|---|---|
| PHP | 8.1 minimum — 8.4 recommandé (8.5 supporté sur les dernières 9.x) |
| Base de données | MySQL 5.7+ ou MariaDB 10.2+ |
| Serveur web | Apache 2.4+ (recommandé) ou Nginx 1.0+ |
| Mémoire PHP | memory_limit ≥ 512M |
| Extensions PHP | curl, dom, fileinfo, gd, iconv, intl, json, mbstring, openssl, pdo_mysql, simplexml, zip |
| Configuration | allow_url_fopen = On |
Deux stratégies possibles
Le bon choix dépend surtout de l'état des modules et du thème actuels de la boutique.
Mise à jour progressive
Via le module Update Assistant, en passant par la 8.x avant la 9.
- Thème proche du standard, modules officiels ou courants
- Conserve historique, configuration et commandes sans ressaisie
- Coût principal : temps de test à chaque palier
Installation neuve + reprise de données
PS9 installé à blanc, données (produits, clients, commandes) réimportées.
- Thème très personnalisé, code legacy lourd, refonte prévue
- Repart sur une base saine, sans dette technique
- Coût principal : travail de développement plus important
Parcours détaillé (voie progressive)
Chaque palier se joue d'abord sur un environnement de test, jamais directement en production.
Auditer modules et thème
Lister chaque module non natif et contacter son éditeur pour une confirmation explicite de compatibilité PS9 — ne jamais supposer. Repérer les override dans /override et les Helpers/AdminController legacy dans les modules maison.
Sauvegarde complète
Base de données (mysqldump) et fichiers (tar) sur un stockage externe au serveur de production, avec un point de restauration testé.
Créer un environnement de test
Copie complète (fichiers + BDD) sur un sous-domaine ou serveur de staging. Toute la suite du parcours s'exécute d'abord ici.
Mettre à jour vers la dernière 1.7.8.x
Via le module Update Assistant en back-office, pour partir d'une base 1.7 totalement à jour avant de viser la 8.
Migrer vers PrestaShop 8.1 / 8.2
Désactiver les modules non natifs pendant la mise à jour, puis les réactiver un par un pour isoler les conflits.
Sauvegarde complète avant lancementStabiliser 1 à 2 semaines
Faire vivre la boutique en 8.x (staging puis, idéalement, production) pour repérer les régressions avant d'ajouter la couche de changements suivante.
Migrer vers PrestaShop 9
Mode maintenance avec IP autorisée, exécution pendant une période de faible trafic, puis vidage des caches et réactivation méthodique des modules.
Vérifications post-migration
Parcours d'achat complet, moyens de paiement, transporteurs, emails transactionnels, tâches cron, back-office. Surveiller les logs d'erreur pendant 48h.
Ce qui fait échouer une migration
Trois points de vigilance à traiter avant de lancer quoi que ce soit en production.
Modules utilisant les API legacy
HelperForm et les AdminController classiques ont été retirés au profit des formulaires Symfony. Testez en priorité les modules de paiement : ce sont eux qui pilotent le chiffre d'affaires.
Surcharges de code (override)
PS9 remplace les templates d'admin legacy par du Twig : les surcharges Smarty côté back-office ne sont plus fiables. Préférez les hooks ou les décorateurs de service Symfony.
Thème Classic vs Hummingbird
Le nouveau thème par défaut, Hummingbird, repose sur Bootstrap 5 et des propriétés CSS personnalisées : convertir un thème Classic personnalisé représente un vrai chantier.
Check-list finale
À cocher avant de considérer la migration terminée.