Migration PrestaShop 1.6 vers 1.7, 8 ou 9 : ce qui se migre et ce qui se refait

Migrer une boutique de PrestaShop 1.6 vers 1.7, 8 ou 9 n'est pas une mise à jour : il s'agit de transférer les données (produits, clients, commandes, catégories) vers une nouvelle installation et de refaire le thème, les modules et les développements sur mesure, car ceux de la 1.6 ne fonctionnent pas dans les versions actuelles. Cela se prépare sur une copie, se répète et se bascule un jour de faible trafic.

Beaucoup de boutiques restent en 1.6 parce qu'elles fonctionnent et parce que, chaque fois que quelqu'un pose la question de la migration, la réponse fait peur. Cet article explique ce que cela implique vraiment, ce qui peut être conservé et ce qui ne peut pas l'être, et comment le faire sans perdre de ventes ni de positions dans Google. Si votre boutique est déjà en 1.7, le chemin est différent et plus court.

Quel risque à rester sur PrestaShop 1.6

La branche 1.6 ne reçoit plus de maintenance depuis des années. Concrètement, cela signifie :

• Aucun correctif de sécurité. Chaque faille découverte dans le cœur ou dans un ancien module reste ouverte pour toujours, et les attaques automatisées ciblent justement ces boutiques.
• PHP sans support. La 1.6 ne fonctionne qu'avec des versions de PHP qui ne reçoivent plus de mises à jour. L'hébergeur finit par les retirer, et alors la boutique ne démarre plus ou vous oblige à rester sur un vieux serveur.
• Modules abandonnés. Passerelles de paiement, transporteurs et connecteurs cessent de publier des versions pour la 1.6. Le jour où votre banque change son système d'encaissement, il se peut qu'aucun module ne le prenne en charge.
• Performances et mobile. Les thèmes de l'époque ne sont pas pensés pour les exigences actuelles de vitesse, et cela se ressent sur la conversion et dans les moteurs de recherche.

Pendant que vous préparez la migration, une boutique 1.6 peut être maintenue avec quelques précautions minimales : sauvegardes quotidiennes hors du serveur, employés vérifiés avec des mots de passe uniques, modules inutilisés retirés du disque, alertes sur les changements de configuration des paiements et surveillance des erreurs. C'est un pansement pour gagner du temps, pas une solution.

Pourquoi il n'y a pas de bouton de 1.6 à 9

Entre la 1.6 et la 1.7, PrestaShop a changé presque tout ce qui se voit et une bonne partie de ce qui ne se voit pas : le système de thèmes, la structure des modules, le back-office (qui a commencé à migrer vers Symfony) et la façon de brancher du code personnalisé. Les versions 8 et 9 ont poursuivi dans cette voie et exigent des versions de PHP bien plus récentes.

C'est pourquoi un thème 1.6 ne peut pas s'installer en 1.7 ou au-delà, pas plus que la plupart des modules 1.6. L'assistant de mise à jour officiel sert à monter de version sur un chemin pris en charge, mais il ne convertit pas un thème et ne réécrit pas un module. Ce qui survit, c'est ce qui se trouve dans la base de données.

Ce qui se migre et ce qui se refait

Deux voies : mettre à jour par paliers ou migrer les données

Par paliers (1.6 → 1.7 → 8 → 9)

On met à jour l'installation étape par étape avec l'assistant de mise à jour, en changeant la version de PHP à chaque palier. C'est pertinent quand la boutique est propre, avec peu de modules et presque aucune modification du cœur. À chaque saut, il faut vérifier que la base de données est correcte, et le thème et les modules doivent de toute façon être remplacés.

Nouvelle installation et migration des données

On installe la version cible de zéro, avec son thème et ses modules, puis on importe les données de la 1.6. C'est la voie qui donne généralement les meilleurs résultats sur les boutiques qui ont des années d'historique : elle n'entraîne pas de tables de modules disparus, de configurations oubliées ni de fichiers dont personne ne connaît l'utilité. Elle exige de bien préparer la correspondance des données et de refaire le chargement le jour de la bascule avec les nouvelles commandes et les nouveaux clients.

Il n'y a pas de réponse universelle. C'est l'état de la boutique qui décide : combien de modules elle a, combien de code sur mesure, à quel point le cœur a été modifié et quel volume de données elle contient.

URL et SEO : ce qu'on ne peut pas perdre

• Liste des URL actuelles. Avant de toucher à quoi que ce soit, extrayez toutes les URL qui reçoivent des visites ou des liens : produits, catégories, CMS, marques, et images si elles sont positionnées.
• Mêmes identifiants et mêmes URL simplifiées chaque fois que c'est possible. Si les modèles d'URL changent entre versions, on les ajuste pour qu'ils correspondent ou on prépare des redirections 301.
• Méta-titres et descriptions migrés avec les produits et les catégories, pas régénérés.
• Langues : si la boutique est multilingue, chaque langue conserve ses URL et ses balises de langue alternative.
• Après la bascule : explorer la nouvelle boutique à la recherche d'erreurs 404, soumettre le plan du site et surveiller la Search Console pendant quelques semaines.

Délais et répétition sur une copie

Les délais dépendent de la taille et du thème, mais l'ordre est toujours le même :

1. Inventaire : version, modules avec leur usage réel, overrides, intégrations (ERP, marketplaces, transporteurs) et tâches planifiées.
2. Copie de la boutique dans un environnement de test, protégé et non indexé, avec l'e-mail détourné pour ne pas écrire à de vrais clients.
3. Montage de la nouvelle version avec son thème et ses modules, et premier chargement des données.
4. Tests complets : inscription et connexion d'un ancien client, commandes avec chaque moyen de paiement en mode test, e-mails, factures, transporteurs, recherche et filtres.
5. Répétition du jour de la bascule, chronométrée, pour savoir combien de temps la boutique sera en maintenance.
6. Bascule : chargement final des données, redirections, changement de domaine ou de serveur et vérification immédiate du checkout.

Sauter la répétition, c'est ce qui transforme une migration d'une journée en une semaine d'incidents.

Comment le résoudre dans PrestaShop

Chez Rekire, nous réalisons la migration et la mise à jour de PrestaShop sur une copie de votre boutique, jamais sur la production : inventaire, montage de la nouvelle version, chargement des données, revue des URL et répétition avant le jour de la bascule. Le travail se fait avec des forfaits d'heures : le forfait de 20 heures de support PrestaShop sert à l'inventaire et aux petites boutiques, et le forfait de 50 heures aux migrations avec plus de modules ou de code sur mesure. Avant de commencer, nous vous indiquons le nombre d'heures estimé, et seul le temps réellement travaillé est décompté. Se renseigner avant que l'hébergeur ne retire votre version de PHP coûte bien moins cher que de migrer dans l'urgence.

Questions fréquentes

Peut-on mettre à jour PrestaShop 1.6 directement vers la 9 ?

Pas en une seule étape. Soit on monte par paliers en passant par les branches intermédiaires, soit on installe la 9 de zéro et on migre les données. Dans les deux cas, le thème et les modules sont remplacés.

Est-ce que je perds les commandes et les clients en migrant ?

Non, si c'est bien fait : commandes, factures, clients et adresses sont transférés avec leurs identifiants. Ce qu'il faut vérifier, c'est que les anciens clients peuvent se connecter et que la numérotation des factures se poursuit.

Vaut-il mieux passer à la 1.7 ou directement à la 8 ou à la 9 ?

Si vous faites l'effort de refaire thème et modules, le plus raisonnable est d'aller vers une version supportée. La 1.7 est elle aussi dépassée, et s'y arrêter vous obligerait à migrer de nouveau d'ici peu.

Combien de temps la boutique reste-t-elle fermée ?

Cela dépend du volume de données, mais si tout a été répété, la coupure dure généralement quelques heures, à un moment de faible trafic. La répétition sert justement à connaître cette durée à l'avance.