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

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Migrer une boutique PrestaShop 1.6 vers 9

Migrer une boutique PrestaShop 1.6 directement vers la 9 n’existe pas avec l’outil officiel : c’est l’écart le plus large du catalogue, avec un back-office désormais entièrement basé sur Symfony, un minimum PHP 8.1, et un thème comme des modules presque tous à reconstruire. Sur un tel écart, je recommande souvent une refonte plutôt qu’une migration pure.

Décrire mon problème Discuter sur WhatsApp

Pourquoi cette migration est la plus lourde du lot

PrestaShop 9.0 fait passer le back-office de Symfony 4.4 (branche 8.x) à Symfony 6.4 LTS, avec une administration désormais entièrement construite sur des contrôleurs Symfony et du templating Twig : les derniers contrôleurs « legacy » disparaissent. PrestaShop 9 introduit aussi une nouvelle API d’administration, basée sur API Platform avec authentification OAuth. Le PHP minimum passe à 8.1, avec prise en charge de 8.2, 8.3 et 8.4.

Comparée à ça, PrestaShop 1.6 tourne sur un framework legacy propriétaire, un templating Smarty seul, et fonctionne au mieux jusqu’à PHP 7.1 : il faut franchir trois générations d’architecture (1.7, 8, 9), deux changements de thème par défaut et un saut PHP de 7.1 à 8.1 minimum. Le thème Hummingbird apparaît en 9.0, mais Classic reste le thème par défaut à la sortie : ce n’est pas un choix imposé.

Comme pour toute migration PrestaShop, il n’existe pas de saut direct avec autoupgrade : il faut passer par la 1.7, et en pratique par la 8 aussi, avant d’atteindre la 9.

Ce qui casse typiquement dans un écart 1.6 vers 9

  • Un module de paiement écrit pour displayPayment (1.6) n’apparaît plus au tunnel de commande, ce hook ayant été remplacé par paymentOptions dès la 1.7.
  • La quasi-totalité des modules 1.6 utilisant l’ancienne syntaxe entre accolades (par exemple $array{0}) provoque des erreurs fatales sous PHP 8.1, supprimée depuis PHP 8.
  • Le thème 1.6, en Smarty seul et sur Bootstrap 3, n’a pas d’équivalent dans l’architecture de thème introduite en 1.7 et toujours en place en 9 : le front-office se reconstruit, il ne s’adapte pas.
  • Les intégrations sur l’ancienne API d’administration doivent être vérifiées face à la nouvelle Admin API, basée sur API Platform et OAuth, introduite en 9.

Comment j’aborde un tel écart de versions

  1. Audit complet et décision migration ou refonte

    Modules, thème, développements spécifiques, volume de reconstruction estimé : sur un tel écart, une refonte coûte parfois moins qu’une migration pas à pas.

  2. Sauvegarde complète, conservée en dehors des outils de migration

    Fichiers, base complète, liste des modules et versions, configuration des modules de paiement et transport, avant toute manipulation.

  3. Passage par les étapes intermédiaires (1.7, puis 8) si la migration est retenue

    Chaque étape testée sur une copie de la boutique, jamais en production, avec sa propre validation avant la suivante.

  4. Reconstruction du thème et de l’admin spécifique

    Thème reconstruit sur Classic (ou adapté si Hummingbird), développements back-office réécrits pour l’administration Symfony/Twig de la 9.

  5. Remplacement des modules incompatibles

    Équivalent fonctionnel pour chaque module qui ne migre pas, ou réécriture adaptée à la nouvelle architecture.

  6. Vérification puis bascule en production

    Bascule programmée à faible trafic une fois la version de test validée.

Migration ou refonte : comment je tranche

Une migration pas à pas signifie reconstruire le thème potentiellement plusieurs fois (une base Classic pour la 1.7 et la 8, puis vérifier sa compatibilité avec l’admin de la 9), et vérifier ou réécrire chaque module à chaque étape. Une refonte part d’une installation neuve en 9 et ne reprend que les données : catalogue, clients, commandes. Je la recommande quand le thème est déjà ancien, quand les modules spécifiques sont nombreux, ou quand le site n’a pas évolué visuellement depuis longtemps.

Dans les deux cas, je sauvegarde fichiers, dump de base, liste des modules avec versions, et configuration des modules de paiement et transport avant de commencer. Après la bascule finale, je vérifie que commandes, clients et produits correspondent à l’avant, que les URLs répondent avec le bon code, que les redirections fonctionnent, et je passe une commande de test complète pour confirmer paymentOptions.

config.xml
<compatibility>
  <min>1.7</min>
  <max>9.99.99</max>
</compatibility>

Pour préparer ou compléter cette migration

  • PHP 5.2 à 7.1 PrestaShop 1.6
  • PHP 8.1 minimum, jusqu’à 8.4 PrestaShop 9

devdocs.prestashop-project.org

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

Puis-je migrer directement de PrestaShop 1.6 à 9 ?
Non, pas en un seul lancement. autoupgrade enchaîne les paliers sans en sauter aucun, et la version du module capable de traiter une 1.6 s’arrête à la 1.7 : il faut atteindre la 1.7 d’abord, puis repartir de là vers la 8 et la 9.
Pourquoi recommandez-vous parfois une refonte plutôt qu’une migration pour un tel écart ?
Le thème doit être reconstruit plusieurs fois et la quasi-totalité des modules 1.6 est incompatible avec PHP 8.1 et l’administration Symfony de la 9 : reconstruire une fois en 9 coûte souvent moins cher que migrer étape par étape.
Quelle version de PHP faut-il pour PrestaShop 9 ?
8.1 minimum, avec prise en charge de PHP 8.2, 8.3 et 8.4.
Le nouveau thème Hummingbird est-il obligatoire sur PrestaShop 9 ?
Non. Hummingbird est introduit avec la 9.0, mais Classic reste le thème par défaut à la sortie de cette version.
Mes intégrations qui utilisent l’API actuelle fonctionneront-elles encore après la migration ?
PrestaShop 9 introduit une nouvelle API d’administration basée sur API Platform avec authentification OAuth. Toute intégration existante doit être vérifiée face à cette nouvelle API avant la migration.

Pages liées