Migrer une boutique PrestaShop recouvre deux réalités : changer de version (quitter une 1.7 en fin de vie pour la 8.2 ou la 9) ou changer de serveur (nouvel hébergeur, machine plus puissante, passage chez un infogéreur). Bonne nouvelle : la méthode manuelle est la même dans les deux cas, à quelques variantes près que nous signalons au fil du guide.
C’est la méthode que nous appliquons sur les boutiques clients quand les outils automatiques ne suffisent plus, et c’est la seule qui donne un contrôle total sur chaque fichier et chaque table.
Avant de vous lancer, sachez qu’il existe deux alternatives outillées : le module officiel Update Assistant pour une simple montée de version (nous les comparons dans notre guide passer à la version 8 ou 9) et MigrationPro pour transférer les données vers une installation neuve.
Si votre boutique est customisée, interfacée ou simplement précieuse, la méthode manuelle reste la voie royale. La voici, étape par étape, commandes comprises.
En bref
-
Une seule méthode pour deux cas : montée de version et changement de serveur suivent les mêmes étapes.
-
Sauvegarde d’abord : fichiers via SFTP ou rsync, base via mysqldump, et une restauration de test pour valider le tout.
-
Les modules sont le vrai point de friction : audit de compatibilité avant, pas pendant.
-
Jamais de bascule sans recette : commande test, paiement, emails, puis mise en production.
Avant de commencer : manuel, Update Assistant ou MigrationPro ?
Le choix de la méthode dépend de l’état de votre boutique. Une boutique proche du standard, avec un thème enfant propre et des modules à jour, se met à jour très bien avec l’Update Assistant. Une boutique dont la base est saine mais dont l’installation traîne trop de dette technique gagnera à repartir d’une installation neuve alimentée par MigrationPro. La migration manuelle s’impose dans les autres cas : overrides nombreux, modules maison, interfaçages (ERP, comptabilité, flux marketplace), ou tout simplement un changement de serveur, que les modules de migration ne couvrent pas.
Côté prérequis, vérifiez l’environnement cible avant tout : PrestaShop 8.2 fonctionne de PHP 7.2 à 8.1, PrestaShop 9 exige PHP 8.1 minimum, avec MySQL 5.6+ ou MariaDB. Sur un changement de serveur, contrôlez aussi les extensions PHP requises (intl, gd, zip, curl) et les limites mémoire : un memory_limit à 256 Mo minimum vous évitera des imports qui échouent silencieusement.
Pour les durées, voici ce que nous constatons sur les boutiques clients, phase de tests comprise :
| Profil de boutique | Durée réaliste |
|---|---|
| Standard, catalogue modeste, changement de serveur simple | 1 à 3 jours |
| Montée de version avec quelques modules à mettre à jour | 1 à 2 semaines |
| Boutique customisée, overrides, intégrations tierces | 3 à 6 semaines |
Si ces fourchettes vous semblent hors de portée en interne, c’est un travail que vous pouvez déléguer : notre article sur le choix d’un prestataire PrestaShop détaille ce qu’un devis sérieux doit contenir.
Étape 1 : la sauvegarde complète (fichiers + base)
Rien ne commence avant d’avoir une copie complète et vérifiée de la boutique. Une sauvegarde n’existe vraiment qu’une fois restaurée avec succès : avant ça, ce n’est que de la pensée positive au format .zip.
Les fichiers d’abord. Vous pouvez passer par un client SFTP comme FileZilla (téléchargez l’intégralité du répertoire de la boutique), mais en ligne de commande, c’est plus rapide et vérifiable :
<h1>Archiver l’intégralité de la boutique, horodatée</h1>
tar -czf boutique-$(date +%F).tar.gz /var/www/boutique/
<h1>Ou copier directement vers une autre machine (reprise possible si coupure)</h1>
rsync -avz –progress /var/www/boutique/ utilisateur@serveur-cible:/var/www/boutique/
La base ensuite, avec mysqldump plutôt que phpMyAdmin, qui atteint vite ses limites (timeouts, fichiers trop lourds) sur un vrai catalogue :
<h1>Export complet, cohérent même si la boutique tourne encore</h1>
mysqldump -u utilisateur -p –single-transaction –default-character-set=utf8mb4 nom_base > base-boutique-$(date +%F).sql
Stockez fichiers et base hors du serveur d’origine, puis testez la restauration sur un environnement local ou un sous-domaine : montez la base dans une base vide, déposez les fichiers, vérifiez que la boutique s’affiche. Dix minutes qui transforment une promesse en garantie.
Étape 2 : préparer la cible (nouvelle version ou nouveau serveur)
Montée de version : téléchargez la version cible sur le site officiel de PrestaShop (8.2 ou 9.1, les deux branches stables en 2026) et installez-la dans un répertoire séparé ou sur un sous-domaine de test, avec sa propre base de données. N’y installez ni thème ni modules pour l’instant : les données d’abord.
Changement de serveur : préparez la machine cible (vhost, PHP à la bonne version avec les bonnes extensions, base de données vide, certificat SSL prêt). Dans les deux cas, le principe est identique : on ne travaille jamais directement sur la boutique en production. L’environnement de test est le filet de sécurité de toute l’opération, et il servira de préproduction pour la recette de l’étape 5.
Étape 3 : migrer la base de données et les fichiers
L’import de la base se fait en une commande :
Importer le dump dans la base de la cible
mysql -u utilisateur -p nom_base_cible < base-boutique-2026-07-30.sql [/pf_code]
Sur un simple changement de serveur à version identique, la base est importée telle quelle. Sur une montée de version, c’est le mécanisme de mise à jour de PrestaShop qui adaptera la structure des tables : l’approche fiable consiste à restaurer d’abord la boutique à l’identique sur la cible, puis à y dérouler la montée de version de façon contrôlée, plutôt que de bricoler les tables à la main.
Côté fichiers, transférez ensuite ce qui appartient à votre boutique : le répertoire /img (toutes les images produits et catégories), vos modules, votre thème, et les fichiers d’upload. Reste à connecter la boutique à sa nouvelle base : depuis PrestaShop 1.7, la configuration ne se trouve plus dans config/settings.inc.php mais dans app/config/parameters.php. Mettez-y à jour l’hôte, le nom de la base, l’utilisateur et le mot de passe. Enfin, si l’URL de la boutique change (sous-domaine de test, nouveau domaine), pensez à la table ps_shop_url et videz le cache (var/cache/) : c’est la cause numéro un des boucles de redirection après migration.
Étape 4 : modules et thème, le vrai chantier
C’est l’étape qui fait échouer les migrations improvisées, et celle qui justifie la méthode manuelle. Dressez la liste exhaustive de vos modules et traitez-les un par un, dans cet ordre de priorité : les modules critiques d’abord (paiement, transporteurs, TVA), puis les modules métier, puis le confort.
Pour chaque module, trois issues possibles : une mise à jour existe pour votre version cible (souvent via un rachat de licence chez l’éditeur), un remplacement par un module équivalent maintenu, ou une adaptation du code pour les modules maison. Les modules abandonnés sans équivalent doivent être identifiés avant la migration, pas découverts pendant : c’est toute la valeur de l’audit préalable. Même logique pour le thème : vérifiez sa compatibilité avec la version cible, et profitez de l’occasion pour supprimer les overrides devenus inutiles, chaque fichier dans /override/ étant un conflit potentiel.
Sur une migration de serveur récente, tout fonctionnait en préproduction, puis la boutique s’est mise à boucler en redirection infinie une fois basculée. La cause : la table ps_shop_url contenait encore l’URL de préproduction, et le cache Symfony servait l’ancienne configuration. Deux minutes de correction quand on sait où chercher, une demi-journée de panique quand on l’ignore. Depuis, la vérification de ps_shop_url et la purge de var/cache/ font partie de notre checklist de bascule, systématiquement.
Étape 5 : la recette avant bascule
Aucune bascule sans une session de tests complète sur l’environnement de préproduction, dans la peau d’un client puis dans celle d’un gestionnaire :
- Commande test de bout en bout : panier, compte client, choix du transporteur, paiement (en mode sandbox), email de confirmation reçu.
- Moyens de paiement : chaque passerelle active (CB, PayPal, virement) testée individuellement.
- Transporteurs et frais de port : les règles de calcul par zone et par poids donnent les bons montants.
- Comptes clients existants : connexion avec un compte migré, historique de commandes visible, adresses conservées.
- Back-office : création d’un produit, génération d’une facture, exports comptables et flux (ERP, marketplaces) opérationnels.
- URLs et SEO : la structure d’URL est identique à la production, les redirections nécessaires sont prêtes, robots.txt et sitemap sont corrects.
Ne cochez pas cette liste de mémoire : déroulez-la réellement, une ligne à la fois. Chaque case cochée en préproduction est un incident évité en production.
Étape 6 : la mise en production
Planifiez la bascule sur un créneau creux (tôt le matin en semaine plutôt qu’un vendredi soir) et gelez les modifications en back-office pendant l’opération : toute commande ou changement de stock survenu entre la dernière synchronisation et la bascule devra être reporté à la main.
Montée de version sur le même serveur : passez brièvement la boutique en maintenance, resynchronisez la base et les fichiers récents, puis basculez les répertoires (l’ancien devient boutique-old, le nouveau prend sa place) ou le vhost. Changement de serveur : abaissez le TTL de vos enregistrements DNS quelques jours avant (300 secondes), puis le jour J, faites pointer le domaine vers la nouvelle machine ; la propagation est alors quasi immédiate. Vérifiez le certificat SSL, la table ps_shop_url et videz le cache une dernière fois.
Les jours suivants, surveillez trois choses : les erreurs 404 et le rapport d’indexation dans la Search Console, les logs d’erreurs PHP du serveur, et les commandes réelles (montants, emails, paiements encaissés). L’ancien environnement reste en sommeil deux à quatre semaines, prêt à servir de point de retour, avant d’être archivé.
FAQ
De 1 à 3 jours pour un changement de serveur sur une boutique standard, de 1 à 6 semaines pour une montée de version selon le nombre de modules à traiter et le niveau de customisation. L’essentiel du temps part dans l’audit des modules et la recette, pas dans le transfert lui-même.
Pas si la méthode est respectée : sauvegarde complète testée par une restauration, travail exclusivement sur un environnement de préproduction, resynchronisation juste avant la bascule et conservation de l’ancien environnement plusieurs semaines. Les pertes de données arrivent sur les migrations menées directement en production, sans sauvegarde vérifiée.
Oui, et c’est même le cas le plus simple : mêmes étapes (sauvegarde, préparation de la cible, transfert base + fichiers, tests, bascule), sans la partie montée de version et audit de compatibilité des modules. Les points d’attention spécifiques sont la version de PHP sur la nouvelle machine, la table ps_shop_url, le certificat SSL et la bascule DNS.
Menée avec méthode, une migration manuelle de PrestaShop n’a rien d’un saut dans le vide : c’est une suite d’étapes vérifiables, chacune protégée par la précédente. Sauvegarde testée, environnement de préproduction, audit des modules, recette complète, bascule surveillée : suivez cet ordre et votre boutique traversera le déménagement sans perdre ni une commande ni une position. Et si vous préférez garder les mains sur votre activité pendant que quelqu’un d’autre garde les mains dans la base, c’est exactement ce que nous faisons.
Commentaires