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

Migrer votre boutique PrestaShop vers 1.7, 8 ou 9

Passer de PrestaShop 1.6 à 1.7, 8 ou 9 n’est pas une mise à jour classique : le moteur de thème change complètement, le back-office bascule progressivement sur Symfony, et une bonne partie des modules 1.6 ne fonctionne plus telle quelle.

Décrire mon problème Discuter sur WhatsApp

Pourquoi ce n’est pas une simple mise à jour

PrestaShop 1.6 utilise un système de thème basé entièrement sur Smarty et des templates .tpl classiques. À partir de 1.7, une partie de l’administration et certains contrôleurs front reposent sur le framework Symfony, avec une nouvelle arborescence (src/, var/) et un système d’override différent. Le thème par défaut change aussi de nom (Classic à la place de Default), ce qui veut dire concrètement qu’un thème 1.6, même personnalisé, ne s’installe pas tel quel sur 1.7 ou 8 : il faut le reconstruire ou l’adapter template par template.

Côté modules, chaque module doit déclarer sa compatibilité avec la version cible dans son fichier de configuration. Un module qui fonctionne parfaitement en 1.6 peut être totalement absent du marché pour 1.7/8, ou nécessiter une version payante différente chez son éditeur. C’est souvent le point qui fait le plus dérailler un budget de migration mal estimé au départ.

La structure de la base de données évolue aussi entre les versions majeures (nouvelles tables, colonnes renommées), ce qui impose un script de migration de données plutôt qu’un simple export-import SQL brut.

Comment je conduis une migration

  1. Audit de l’existant

    Je liste les modules installés, leurs versions, et je vérifie lesquels ont un équivalent compatible avec la version cible.

  2. Migration sur environnement de test

    Je réalise la migration une première fois sur une copie de la boutique, jamais directement en production, pour identifier tous les blocages avant de toucher au site réel.

  3. Reconstruction du thème

    Selon l’écart entre les versions, j’adapte le thème existant ou je le reconstruis sur la base du thème par défaut de la version cible, en conservant l’identité visuelle.

  4. Remplacement des modules incompatibles

    Je trouve des équivalents fonctionnels aux modules qui ne migrent pas, ou je réécris les fonctionnalités spécifiques en module sur mesure si besoin.

  5. Bascule en production

    Une fois la version de test validée avec vous, je programme la bascule à un moment de faible trafic pour limiter l’impact sur les commandes en cours.

1.7, 8 ou 9, selon votre situation

  • PrestaShop 1.7

    Palier intermédiaire, rarement une cible en soi : c’est la version qu’il faut atteindre avant de continuer vers 8 ou 9 quand on part d’une 1.6, l’outil de mise à jour ne sautant aucun palier.

  • PrestaShop 8

    Cible raisonnable quand l’écosystème de modules de la boutique n’est pas encore déclaré compatible 9, ou quand l’hébergement ne fournit pas encore une version de PHP acceptée par la 9.

  • PrestaShop 9

    Dernière branche majeure : back-office entièrement Symfony/Twig, contrôleurs legacy supprimés, exigences PHP plus élevées. Cible naturelle d’un projet neuf, à condition de vérifier module par module.

  • Rester en 1.6 avec vigilance

    Envisageable à court terme pour une boutique stable, mais 1.6 n’est plus maintenue par l’éditeur, ce qui expose à des failles de sécurité non corrigées.

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

Vais-je perdre mes commandes, mes clients ou mon catalogue pendant la migration ?
Non, la migration se fait sur une copie de la boutique. Les données de production restent intactes jusqu’à la bascule finale, qui reprend les commandes passées entre-temps.
Combien de temps dure une migration ?
Ça dépend surtout du nombre de modules et de la complexité du thème. Une boutique simple se migre en quelques jours ; une boutique avec des modules sur mesure ou un thème très personnalisé peut demander plusieurs semaines.
Est-ce que mon référencement va être impacté ?
Si les URLs et la structure des pages sont conservées, l’impact est limité. Je fais attention aux redirections et à la structure des balises pour ne pas perdre le référencement acquis.
Que se passe-t-il si un module n’a pas d’équivalent sur la nouvelle version ?
Je cherche d’abord un module équivalent chez un autre éditeur. Si aucune solution du marché ne convient, je développe la fonctionnalité en module sur mesure adapté à la nouvelle architecture.
Quels accès dois-je vous fournir ?
Un accès FTP ou SSH, un accès à la base de données, et l’accès au back-office actuel pour établir l’inventaire des modules et de la configuration.