Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

Migrer une boutique PrestaShop 1.5 vers la version 8

PrestaShop 1.5, sortie en 2012, a une architecture qui n’a plus grand-chose à voir avec la version 8. Aucun outil officiel ne migre une 1.5 directement vers 8 : c’est un chantier de reconstruction avec récupération de données, pas une mise à jour au sens habituel.

Décrire mon problème Discuter sur WhatsApp

Pourquoi ce n’est pas une migration classique

PrestaShop 1.5 est sorti en 2012. Son architecture est plus ancienne encore que celle de la 1.6, qui nécessite déjà une reconstruction significative du thème pour atteindre la 1.7 ou la 8. Aucun outil officiel ne migre une boutique 1.5 directement vers 1.7, 8 ou 9 : le module autoupgrade est conçu pour des sauts de version bien plus resserrés, avec des scripts adaptés à chaque palier, pas pour franchir d’un coup un écart aussi large.

PrestaShop 1.5 n’est plus maintenue par l’éditeur depuis très longtemps, sans que je puisse avancer de date précise. Elle tourne aussi sur des versions de PHP anciennes, elles-mêmes non maintenues aujourd’hui par le projet PHP. Une boutique 1.5 encore en ligne cumule donc deux problèmes : un logiciel non maintenu, et un environnement d’exécution non maintenu.

Les deux méthodes réelles, et comment choisir

La première méthode consiste à enchaîner les migrations version par version : 1.5 vers 1.6, puis 1.7, puis 8, chaque étape testée séparément sur une copie. C’est la plus fiable pour conserver l’historique complet (catalogue, commandes, comptes clients) tel quel, mais aussi la plus longue, puisqu’elle multiplie les paliers et les corrections associées.

La seconde consiste à repartir d’une installation neuve de la version cible et à migrer uniquement les données utiles : catalogue, clients, historique de commandes, via un export-import ciblé plutôt qu’une restauration de base brute. En pratique, ça revient à une reconstruction plutôt qu’à une migration au sens classique.

Dans les deux cas, le thème et la quasi-totalité des modules doivent être refaits : aucune méthode n’évite cette étape. La vraie question n’est donc pas « comment migrer », mais « qu’est-ce que je tiens vraiment à conserver ». Un historique complet et un référencement ancien plaident pour la cascade. Un besoin de rapidité, avec catalogue et base clients repris proprement, plaide pour la reconstruction.

Cascade ou reconstruction

  • Migration en cascade

    1.5 vers 1.6, puis 1.7, puis 8, chaque étape testée séparément. Conserve l’historique complet mais demande le plus de temps.

  • Reconstruction avec reprise de données

    Installation neuve, catalogue et clients repris par export-import ciblé. Plus rapide, mais c’est une reconstruction, pas une migration au sens strict.

  • Rester en 1.5

    Non recommandé au-delà du très court terme : version non maintenue, sur un environnement PHP lui aussi ancien.

Comment j’aborde ce type de projet

  1. Audit de l’existant

    Je regarde ce qui reste exploitable : volume de catalogue, historique de commandes, comptes clients, et l’état réel du code (modules sur mesure, surcharges).

  2. Choix de la méthode avec vous

    Cascade ou reconstruction avec reprise de données, selon ce que vous tenez vraiment à conserver : historique complet, référencement ancien, ou simplement catalogue et clients.

  3. Sauvegarde complète de l’existant

    Avant toute opération, j’exporte l’intégralité des fichiers et de la base 1.5, même si elle ne sera pas restaurée telle quelle sur la version cible.

  4. Le point de non-retour

    C’est le moment où j’arrête d’alimenter l’ancienne boutique en nouvelles commandes pour basculer les clients vers la boutique reconstruite : après ce point, toute commande passée entre-temps doit être reprise manuellement.

  5. Reconstruction du thème et des modules

    Le thème et la quasi-totalité des modules d’une boutique 1.5 ne migrent pas : je les refais pour la version cible, cascade ou reconstruction.

  6. Vérification des données reprises

    Je compare les volumes entre ancienne et nouvelle boutique, nombre de produits, de clients, de commandes, pour m’assurer qu’aucune donnée n’a été perdue.

Pour aller plus loin

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Quelle est la version actuelle ?
Vers quelle version souhaitez-vous aller ?
Quelle est la taille du catalogue ?

C’est le premier facteur de durée d’une migration, avant même le nombre de modules.

La boutique utilise-t-elle beaucoup de modules tiers ou personnalisés ? (facultatif)

Chaque module non natif doit être vérifié, remplacé ou réécrit pour la version cible.

Qu’est-ce qui doit impérativement être conservé ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Pourquoi ne peut-on pas migrer directement d’une 1.5 vers une 8 ?
Parce qu’aucun outil officiel ne le fait : autoupgrade gère des paliers bien plus resserrés que l’écart entre 1.5 et 8. Il reste deux méthodes : la cascade, version par version, ou la reconstruction avec reprise ciblée des données.
Vais-je perdre mon thème actuel ?
Dans la quasi-totalité des cas, oui : le thème d’une boutique 1.5 doit être refait pour la version cible, quelle que soit la méthode. C’est une caractéristique de l’écart entre les versions, pas un point avec un raccourci fiable.
Quelle méthode choisir entre la cascade et la reconstruction ?
Ça dépend de ce que vous tenez à conserver. Un historique complet et un référencement ancien plaident pour la cascade. Un besoin de rapidité, avec catalogue et base clients repris proprement, plaide pour la reconstruction.
Combien de temps prend ce type de projet ?
Plus longtemps qu’une migration entre versions proches, car la reconstruction du thème et la remise à plat des modules sont incontournables dans les deux méthodes. Je donne une estimation après l’audit initial, pas avant.