Migration PrestaShop 1.6 vers 8 : reprendre les données, remplacer ce qui ne suit pas

Une boutique PrestaShop 1.6 rejoint la 8 par deux routes : le module officiel de mise à jour, en deux passes sur la boutique en place, ou une 8 neuve qui reçoit les données. Au 14 octobre 2026, la cible se discute : la version 8 plafonne à PHP 8.1, sans correctif de php.net depuis le 31 décembre 2025.

• Deux routes mènent une boutique PrestaShop 1.6 à la 8 : le module ou la boutique neuve
• Vers la 8, les données d’une boutique PrestaShop 1.6 passent par l’import, la base ou la main
• Les mots de passe des clients PrestaShop 1.6 survivent par le transfert de la table en base
• Le thème et les modules PrestaShop 1.6 se remplacent un par un
• Trois livrables à exiger avant la bascule vers PrestaShop 8
• Le devis d’une migration 1.6 vers 8 varie avec les modules, le thème et les données
• Trois écarts au guide de migration à éviter en reprise PrestaShop 1.6 vers 8
• La 8 reste une cible : son PHP 8.1 n’est plus corrigé par php.net depuis le 31 décembre 2025
• Sources consultées
• Foire aux questions

Deux routes mènent une boutique PrestaShop 1.6 à la 8 : le module ou la boutique neuve

D’après le dépôt du module officiel de mise à jour, la version 4.14.3 fait passer une 1.6 en 1.7, puis la version courante atteint la cible. Les plages de PHP de chaque version se lisent dans le tableau de la migration vers la 9 ; monter la version de PHP sans arrêter la boutique traite le changement chez l’hébergeur.

La seconde route est celle que l’éditeur recommande pour une version majeure : une 8 neuve reçoit les données de l’ancienne. Le guide « How to migrate to PrestaShop 8 » compare une base 1.6.1.18 à une 1.7.3.2 : le relevé de structure se refait entre votre 1.6 et la 8 installée.

Lecture du site, que l’éditeur ne formule pas :

• Module : peu de modules sans version 8, ni surcharge ni modification du cœur (code de base), des tables d’anciens modules que la base garde telles quelles ; il désinstalle par défaut les modules incompatibles (README d’autoupgrade).
• Boutique neuve : de nombreux modules sans version 8, des surcharges ou des modifications du cœur, un historique à nettoyer.

Prérequis de la 8, à demander par écrit à l’hébergeur : MySQL 5.7 minimum ou MariaDB 10.2 minimum, PHP 7.2.5 à 8.1 (8.1 recommandé), un minimum recommandé de 256 Mo de mémoire par script PHP (« memory_limit »).

Vers la 8, les données d’une boutique PrestaShop 1.6 passent par l’import, la base ou la main

Le guide procède en trois temps : extraire, adapter, importer. Les tables sont les tableaux de la base de données de la boutique.

Fondement : « guide » décrit par le guide, « code » montré par le code de PrestaShop, « déduit » pour le reste. Le guide cite les commandes sans procédure propre ; paniers et stocks manquent à sa liste d’import, mais la quantité d’un produit s’importe avec lui. L’export complet passe par phpMyAdmin, l’outil de gestion de la base que fournit l’hébergeur : les listes du back-office n’exportent que les colonnes affichées. Hacher, c’est transformer un mot de passe en empreinte, qui ne se déchiffre pas.

Le guide demande que les identifiants de langue de la boutique neuve coïncident avec ceux de la 1.6. Les langues se réinstallent dans la 8 (« International > Localization > Import a localization pack », libellés anglais du guide) ; les trous de numérotation se reproduisent en installant puis en supprimant des langues.

Décrire mon besoin →

Les mots de passe des clients PrestaShop 1.6 survivent par le transfert de la table en base

D’après le code de PrestaShop, les mots de passe survivent au transfert de la table des clients en base, empreintes intactes, clé de la 1.6 reprise. La 1.6.1.24 stocke une empreinte tirée du mot de passe et d’une clé secrète écrite à l’installation dans « config/settings.inc.php ». La 8.2 vérifie encore ce format avec la clé du paramètre « cookie_key » de « app/config/parameters.php ».

L’outil d’import traite la colonne « passwd » comme un mot de passe en clair et le hache : par bcrypt, la méthode de hachage actuelle, en 8.2.x, par empreinte à clé en 1.6.1.24. Des empreintes de la 1.6 importées par cet outil sont hachées deux fois ; reporter la clé n’y change rien, et chaque client passe par « Mot de passe oublié ». Par le module, la base reste en place et le sujet ne se pose pas. Le guide ne dit rien des mots de passe : ces chemins se déduisent du code et de la base laissée en place.

Avant l’export, créez un compte client de test dans la 1.6. Testez sa connexion sur la préproduction, la copie de travail de la 8 que vos clients ne voient pas, par le canal que le plan prévoit pour les clients.

Le thème et les modules PrestaShop 1.6 se remplacent un par un

Un thème 1.6 n’est pas compatible avec la 1.7 et les suivantes (« Keep PrestaShop up-to-date ») : il se remplace dans les deux routes, par un thème acheté pour la 8 ou une création.

Un module est présumé incompatible tant que le contraire n’est pas prouvé, et chaque module réinstallé se reconfigure à la main. Dressez la liste depuis Modules et services, avec une décision par ligne : nouvelle version, remplacement, développement ou abandon. Ajoutez une colonne pour les données gardées dans les tables du module, points de fidélité ou avis : l’outil d’import les ignore.

Les surcharges, fichiers du dossier « override » qui modifient le cœur, se réécrivent pour la 8 ou disparaissent.

Trois livrables à exiger avant la bascule vers PrestaShop 8

Trois pièces : la table de décision des modules, le plan de correspondance des données (canal par type, exclusions, canal des clients) et le rapport de répétition, une migration complète jouée sur la préproduction. Comparez les totaux de produits, clients et commandes affichés en tête de chaque liste, puis passez une commande de test avec chaque moyen de paiement et chaque transporteur.

La bascule suit un plan écrit : un créneau sans commande, un dernier transfert des clients et commandes du jour, l’ouverture de la 8, la 1.6 gardée intacte pour un retour arrière. Faites écrire qui décide ce retour, qui en paie le temps, et combien de jours le prestataire corrige sans facturer les défauts de reprise.

Décrire mon besoin →

Le devis d’une migration 1.6 vers 8 varie avec les modules, le thème et les données

Il dépend aussi du catalogue, des années de commandes à reprendre, des langues, des données propres aux modules et du nombre de répétitions.

Trois écarts au guide de migration à éviter en reprise PrestaShop 1.6 vers 8

Installer la 8 avec ses données de démonstration. Le guide demande de cocher « dont install demo data », ou de vider les tables avant import : des identifiants identiques remplacent les données existantes.

Oublier l’index de recherche. Les produits importés restent introuvables du site tant qu’ils n’y sont pas ajoutés, depuis Shop parameters > Search > Indexing, libellés anglais du guide.

Écraser ce que la boutique neuve contient déjà : le guide fait ignorer la table « configuration » et demande de décocher « Delete all … before import » dès le deuxième fichier du même type.

La 8 reste une cible : son PHP 8.1 n’est plus corrigé par php.net depuis le 31 décembre 2025

D’après l’annonce du 4 juillet 2025, la 8.2 ne reçoit que des correctifs critiques et de sécurité, jusqu’à la sortie de PrestaShop 10, non datée.

Règle de décision, lecture du site que l’éditeur ne formule pas : un module sans lequel la boutique ne vend pas n’existe-t-il que pour la 8 ? Alors la 8 se justifie, avec la date de passage à la 9 écrite au contrat. Sinon, la 9 évite une seconde migration, comme le détaille la migration de la 1.6 vers la 9. Faites nommer la version mineure livrée et le PHP du serveur : selon ses règles de contribution, l’éditeur n’accepte plus de correctif pour une version mineure à la sortie de la suivante, sauf rares exceptions.

Sources consultées

• PrestaShop, « 1.6.1.x : what’s next », consulté le 14 octobre 2026.
• PrestaShop, documentations développeur 1.7 et 8, « System requirements », tableaux de compatibilité PHP et prérequis, consulté le 14 octobre 2026.
• php.net, « Unsupported Branches », consulté le 14 octobre 2026.
• PrestaShop, dépôt « autoupgrade », fichier README, consulté le 14 octobre 2026.
• PrestaShop, documentation développeur 9, « Keep PrestaShop up-to-date », section « Migrating PrestaShop », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur 9, « How to migrate to PrestaShop 8 », consulté le 14 octobre 2026.
• PrestaShop, code source, « controllers/admin/AdminImportController.php » (versions 1.6.1.24 et 8.2.x), « classes/Tools.php » (version 1.6.1.24), « classes/ImageManager.php », « src/Core/Crypto/Hashing.php » et « config/bootstrap.php » (branche 8.2.x), consulté les 14 et 15 octobre 2026.
• PrestaShop, « PrestaShop 8.2.x is now in the extended support phase », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur 9, « Supported branches », consulté le 14 octobre 2026.
• CNIL, texte du règlement (UE) 2016/679, articles 5 et 28, consulté le 14 octobre 2026.

Foire aux questions

La boutique 1.6 reste-t-elle en ligne pendant la migration ?

Par la boutique neuve, oui, par déduction : la 1.6 vend jusqu’au créneau de bascule. Par le module, la boutique en place est mise à jour : faites jouer les deux passes d’abord sur une copie.

Faut-il racheter les modules achetés sur la place de marché de PrestaShop ?

Cela dépend du module : l’éditeur demande de vérifier la plage de compatibilité des modules de la place de marché avant toute réinstallation.

La migration peut-elle se faire chez le même hébergeur ?

Oui, par déduction, si l’hébergeur ouvre un second espace sous un PHP accepté par la 8, ou change le PHP entre les deux passes du module.

Les adresses des pages restent-elles les mêmes après la migration ?

Rien ne le garantit. Exigez du prestataire la liste des adresses de l’ancienne boutique et la correspondance de chacune avec la nouvelle, avant la bascule. Les redirections qui en découlent se préparent avec le SEO de migration.

Faut-il reprendre les clients inactifs depuis des années ?

Le RGPD borne la conservation : son article 5, paragraphe 1, point e, ne permet de garder des données identifiantes que le temps nécessaire aux finalités. Un prestataire qui reprend la base agit en général pour votre compte, en sous-traitant au sens de l’article 28, qui exige un contrat. Triez avant le transfert.