# Checklist avant une migration PrestaShop

> Une migration PrestaShop qui tourne mal est presque toujours une migration mal préparée en amont. Voici ce que je vérifie systématiquement avant de toucher au premier fichier, quelle que soit la version de départ ou d’arrivée.

- Source canonique : [https://allaux.fr/prestashop/migration/checklist-avant-migration](https://allaux.fr/prestashop/migration/checklist-avant-migration)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Avant de toucher au premier fichier, produisez trois inventaires : la liste des modules avec éditeur et numéro de version exact, le contenu du dossier override/, et les tâches cron enregistrées côté serveur. Sauvegardez ensuite la base entière et le dossier img/, puis restaurez cette sauvegarde ailleurs pour prouver qu’elle fonctionne vraiment.

## Pourquoi cette étape n’est pas optionnelle

Une migration se prépare avant de se lancer, pas pendant. Si l’inventaire est incomplet, on découvre les problèmes en cours de route, souvent au pire moment : un module dont on n’a plus la licence, une surcharge de code dont personne ne se souvient, une base de données dont la sauvegarde ne contenait finalement pas tout. Chacun de ces oublis coûte du temps, et parfois de la donnée irrécupérable.

Cette checklist s’applique à n’importe quel couple de versions PrestaShop, de la 1.5 à la 9. Ce qui change d’une migration à l’autre, c’est l’ampleur du travail de reconstruction ; ce qui ne change pas, c’est la nécessité de partir d’un inventaire complet et d’une sauvegarde fiable.

## Ce que j’inventorie et je sauvegarde

1. **Liste complète des modules installés** — Nom, éditeur et numéro de version exact de chaque module, y compris ceux désactivés mais encore présents. C’est la base pour vérifier ensuite lesquels ont un équivalent compatible avec la version cible.
2. **Inventaire des surcharges de code** — Tout ce qui se trouve dans le dossier override/, ainsi que les hooks personnalisés ajoutés en dehors des modules standards. Ces personnalisations sont les plus fragiles lors d’un changement de version majeure.
3. **Sauvegarde complète de la base de données** — Structure et contenu de toutes les tables, pas seulement les tables produits et commandes. Les tables de configuration, de traduction et de modules contiennent des réglages qu’on ne veut pas ressaisir à la main.
4. **Sauvegarde complète des fichiers** — Le code, le thème et les images du catalogue. Une base de données sans les fichiers images associés est inutilisable telle quelle.
5. **Version PHP cible chez l’hébergeur** — Je vérifie quelle version PHP est disponible chez l’hébergeur, et si elle correspond à ce qu’exige la version PrestaShop visée. C’est souvent la contrainte qui décide de la version d’arrivée possible.
6. **Tâches planifiées, clés API et traductions** — Les crons existants (relances panier, exports, synchronisations), les clés API de paiement et de transporteurs, ainsi que les modules de langue et les traductions personnalisées installés.
7. **Espace disque disponible** — Je vérifie qu’il y a assez de place pour stocker la sauvegarde complète et faire tourner une copie de test en parallèle du site en production.

## Toujours tester sur une copie, jamais en production directe

> Une migration se déroule d’abord sur une copie de la boutique. C’est ce qui permet de découvrir les blocages, de les résoudre, et de chiffrer le travail réel avant de m’engager sur un délai, sans jamais risquer le site en ligne.

## Pages liées

- **Modules incompatibles après une migration** — Pourquoi un module qui fonctionnait parfaitement casse après la mise à jour, et comment vérifier sa compatibilité avant de migrer. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles))
- **Migrer sans interrompre les ventes** — La méthode pour préparer une migration en parallèle du site en production, et basculer sans laisser la boutique hors ligne. ([/prestashop/migration/migrer-sans-interruption-de-vente](/prestashop/migration/migrer-sans-interruption-de-vente))
- **Passer PrestaShop à PHP 8** — Ce que ça implique quand un hébergeur retire PHP 7 de son offre et que la version PrestaShop visée exige PHP 8. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8))

## FAQ

### Combien de temps avant la migration dois-je faire cet inventaire ?

Je le fais en tout début de mission, avant d’estimer le délai et le périmètre. C’est cet inventaire qui permet de savoir combien de modules devront être remplacés ou de surcharges réécrites.

### Une sauvegarde de la base de données ne suffit-elle pas ?

Non, il faut aussi les fichiers, en particulier les images du catalogue qui ne sont pas stockées en base. Une base sans les fichiers associés est inexploitable pour restaurer la boutique.

### Que faire si je n’ai plus la licence ou l’accès à un module payant ?

C’est justement l’intérêt de l’inventaire fait en amont : le repérer avant la migration plutôt que pendant, pour avoir le temps de contacter l’éditeur ou de chercher une alternative.

### Pourquoi vérifier la version PHP de l’hébergeur avant de choisir la version PrestaShop cible ?

Parce que chaque version de PrestaShop exige une plage de versions PHP précise. Si l’hébergeur ne propose pas encore la version nécessaire, soit on change d’hébergeur, soit on adapte la version cible.

### Faut-il aussi sauvegarder les tâches planifiées (cron) ?

Oui, elles sont souvent oubliées alors qu’elles font tourner des fonctionnalités importantes comme les relances panier ou les exports automatiques. Il faut les relister pour les recréer après la migration.