Migrer PrestaShop 1.7 vers 8 ou 9 : la méthode

Votre boutique tourne sous PrestaShop 1.7, elle vend, et une question revient : faut-il passer à la version 8 ou à la 9, et comment le faire sans rien casser ? Une migration, c'est-à-dire le passage de la boutique à une nouvelle version, se prépare en quatre temps : l'inventaire de ce dont la boutique dépend, le travail sur une copie, les tests, puis la bascule vers la nouvelle version. Chaque étape s'appuie sur des projets que j'ai menés, jusqu'à la nouvelle boutique d'Interstoves, en ligne depuis le 1er avril 2026.

Faut-il migrer maintenant ?#

Le projet PrestaShop avait annoncé que la version 1.7 ne serait plus maintenue à la sortie de PrestaShop 9 (annonce de janvier 2023). PrestaShop 9 est sorti le 10 juin 2025 (annonce de PrestaShop 9). La 1.7 n'est donc plus maintenue : elle ne reçoit plus de correctifs.

Elle dépend aussi d'anciennes versions de PHP, le langage dans lequel PrestaShop est écrit : aucune version 1.7 n'est compatible avec PHP 8 (tableau de compatibilité de la 1.7). Or le projet PHP ne maintient plus que les versions 8.2 et suivantes (versions maintenues) : la 8.1 elle-même n'est plus maintenue depuis le 31 décembre 2025 (versions arrêtées). Une boutique 1.7 continue de fonctionner, mais sur un logiciel et une version de PHP qui ne reçoivent plus de correctifs.

Reste le choix entre 8 et 9. La version 8.2 ne reçoit plus que des correctifs de sécurité, jusqu'à la sortie de PrestaShop 10, et la 9 est la version principale du projet (point mensuel de février 2026). La 8.2 accepte PHP 7.2 à 8.1 (exigences de PrestaShop 8). La 9 demande PHP 8.1 au moins. PrestaShop prévient aussi que certains modules et thèmes peuvent devoir être mis à jour pour fonctionner avec la 9 (annonce de PrestaShop 9). Les modules ajoutent des fonctions à la boutique, les thèmes décident de son apparence. Le choix dépend donc d'abord de vos modules et de votre thème : c'est l'inventaire qui le tranche.

PrestaShop n'en est pas à son premier grand changement de version. J'ai déjà mené une migration de ce type, de la 1.6 à la 1.7, pour Jardideco : commencée en juillet 2023, elle s'est conclue par la mise en ligne du nouveau site le 10 novembre 2023. Dans son avis sur Malt, le client parle d'un « site plus performant que par le passé ». En 2025, j'ai aussi refait en 8.2 une boutique encore en 1.6, avec un design sur mesure.

L'inventaire : modules, thème, surcharges, PHP#

Avant de toucher à la boutique, je liste ce dont elle dépend. Chaque élément de cette liste peut bloquer la migration s'il ne suit pas la nouvelle version.

• Les modules. Ils ajoutent par exemple un moyen de paiement, un transporteur, un formulaire de devis. Pour chacun, je pose deux questions : sert-il encore, et existe-t-il pour la version visée ? Le tri se fait avec vous, et les modules qui ne suivent plus sont remplacés ou adaptés. Pour Zerosix, j'ai rendu un module de fidélité compatible de la 1.7 à la 8.2.
• Le thème. Il règle la mise en page, les couleurs, les polices. Un thème écrit pour la 1.7 se vérifie lui aussi sur la version visée.
• Les surcharges. Une surcharge (en anglais, override) remplace une partie du code de PrestaShop par une version modifiée. Elle a été écrite pour le code de la 1.7 : si ce code change, elle peut provoquer des erreurs ou ne plus faire ce qu'elle faisait. Chaque surcharge se relit donc avant la migration.
• PHP. Chaque version de PrestaShop n'accepte que certaines versions de PHP. Passer de la 1.7 à la 9, c'est aussi passer de PHP 7 à PHP 8 : chaque module doit suivre, et le serveur doit proposer la bonne version.

Les écarts entre versions sont concrets : je les ai rencontrés en développant Orbit Cache, mon module de cache pour PrestaShop. Certains hooks, ces points d'accroche où PrestaShop laisse un module intervenir, n'existent qu'à partir de la 1.7.7. Des fonctions de PrestaShop ne répondent plus de la même façon dans la 9. Et pour fonctionner de la 1.7.6 à la 9.2, le module doit tourner sur PHP 7.2 à 8.4.

Tout faire sur une copie de la boutique#

Une copie de la boutique est une seconde installation, sur le serveur, que vos clients ne voient pas. La migration s'y prépare et s'y teste de bout en bout : votre boutique en ligne continue de vendre pendant ce temps, et rien ne change pour vos clients tant que vous n'avez pas validé. C'est aussi ma règle pour mes autres développements.

Certains hébergements ne permettent pas d'installer une copie. Sans elle, chaque essai se fait sur le site en ligne, devant vos clients. L'hébergement PrestaShop Orbit en comprend une, qui sert aussi après la migration, pour chaque mise à jour.

Pour la migration elle-même, deux voies existent. La première est possible, mais je ne la pratique jamais et je ne vous la conseille pas.

• La mise à jour sur place. La boutique passe à la nouvelle version en gardant tout : ses données, mais aussi ses anciens modules, ses surcharges et ses réglages. Update Assistant, le module de mise à jour de PrestaShop, guide pour cela la sauvegarde, la mise à jour et le retour en arrière (annonce de PrestaShop 9). Ce que l'inventaire a signalé doit être corrigé avant.
• L'installation neuve. Une boutique neuve, dans la version visée, reçoit les données de l'ancienne : catalogue, clients, commandes. Seuls les modules retenus y reviennent, et le thème peut changer. La reprise des données devient alors le cœur du travail.

Je repars toujours d'une installation neuve. Une mise à jour sur place emporte dans la nouvelle version tout ce que la boutique a accumulé : les anciens modules, les surcharges écrites pour la 1.7, les anciens réglages, et les problèmes qui vont avec. Avec une boutique neuve, seules vos données et les modules retenus font le voyage : ce que l'inventaire a écarté reste derrière, et la nouvelle version démarre sur une base saine.

Ma prestation type de migration suit donc cette voie :

1. Je règle le serveur : PHP et la base de données, dans la limite de ce que l'hébergement permet.
2. J'installe une boutique PrestaShop neuve.
3. J'importe une première fois les données (les catégories, les produits, les clients) pour pouvoir régler la boutique.
4. J'installe le thème choisi et je reprends au plus près le menu principal, le logo et les blocs de la page d'accueil. Tous les thèmes n'affichent pas les mêmes blocs, et certains éléments restent à faire de votre côté, comme les images du carrousel d'accueil ou les encarts de réassurance, ceux qui rassurent l'acheteur.
5. J'installe les modules retenus lors du tri.
6. Je règle de nouveau les transporteurs et les moyens de paiement.
7. Je termine par une formation en visioconférence, pour que votre équipe prenne en main les nouveaux outils.

La recette#

La recette est la série de tests qui valide la copie avant la mise en ligne. La bascule n'a lieu qu'une fois que tout fonctionne et que vous avez validé.

• Le parcours d'achat. On passe une commande complète, du panier au paiement, avec les transporteurs et les moyens de paiement de la boutique.
• Les données. On vérifie les produits et leurs prix, les comptes clients et l'historique des commandes.
• Les erreurs. On active le mode debug, qui affiche les erreurs de PrestaShop, et on parcourt les pages de la copie. C'est le contrôle que j'ai fait sur Orbit Cache : aucune erreur sur les cinq versions de PrestaShop testées, de la 1.7.6 à la 9.1.
• Les e-mails. On vérifie les e-mails que la boutique envoie seule, comme la confirmation de commande. Chez Interstoves, ils ont été réglés et authentifiés.
• Les anciennes adresses. Si les adresses des pages changent, on vérifie que chacune mène à la nouvelle par une redirection 301 : une consigne qui indique aux navigateurs et aux moteurs de recherche qu'une page a déménagé pour de bon. Sans redirection, les liens vers l'ancienne adresse mènent à une page introuvable, et vous risquez de perdre la place acquise dans les moteurs de recherche, ce qu'on appelle le référencement.

Le jour de la bascule#

La bascule est le moment où la nouvelle version remplace l'ancienne devant vos clients. Si une boutique est malgré tout mise à jour sur place, elle est sauvegardée avant la mise à jour, et Update Assistant permet de la restaurer si besoin.

Avec une installation neuve, la voie que je suis, la nouvelle boutique prend la place de l'ancienne. Chez Interstoves, qui changeait aussi de serveur, la bascule s'est faite ainsi :

1. L'ancien site a été mis en maintenance.
2. Les données de l'ancien site ont été reprises sur la nouvelle boutique.
3. Le nom de domaine a été dirigé vers le nouveau serveur : c'est la bascule DNS (le DNS est l'annuaire qui relie un nom de domaine à un serveur).
4. Les liens ont été vérifiés.
5. Les paiements ont été testés en réel : de vrais paiements, et non des paiements de test.
6. L'ancien site a été gardé en archive, consultable.

Un exemple réel : Interstoves#

Interstoves vend des poêles à bois et à granulés. Son ancien site tournait déjà sous PrestaShop. La nouvelle boutique a pris la voie de l'installation neuve : PrestaShop 8.2 et un thème sur mesure, bâti sur le thème officiel de PrestaShop. C'était mon conseil, celui que je donne toujours : partir du thème officiel permet de rester au plus près du fonctionnement natif de PrestaShop, pour les mises à jour et pour le référencement.

Le catalogue a été réimporté avec l'aide de l'IA. Les clients et les commandes de l'ancien site ont été repris, et la numérotation des factures a été conservée. Les anciennes adresses ont été redirigées vers les nouvelles, pour garder le référencement acquis. Le plan du site, la liste des pages remise aux moteurs de recherche, a été refait, et tous les éléments importants pour le référencement ont été soigneusement pris en compte et optimisés.

La boutique est en ligne depuis le 1er avril 2026, à la date prévue. Le détail du projet est dans l'étude de cas de la boutique d'Interstoves.