# Migrer une boutique PrestaShop avec DataFirefly Server Migration
> Présentation DataFirefly Server Migration déplace toute une boutique PrestaShop, fichiers et base de données, vers un nouveau serveur, un nouveau domaine ou un sous-dossier. Le back-office vous guide en cinq…
- Page:
- Langue: fr
- Mis à jour le: 2026-11-02
- Autres langues: [en](https://www.datafirefly.com/en/documentation/dfservermigration/index.md), [pt](https://www.datafirefly.com/pt/documentation/dfservermigration/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfservermigration/index.md), [it](https://www.datafirefly.com/it/documentation/dfservermigration/index.md), [es](https://www.datafirefly.com/es/documentation/dfservermigration/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfservermigration/index.md), [de](https://www.datafirefly.com/de/documentation/dfservermigration/index.md)
- Index:
## Présentation
DataFirefly Server Migration déplace toute une boutique PrestaShop, fichiers et base de données, vers un nouveau serveur, un nouveau domaine ou un sous-dossier. Le back-office vous guide en cinq étapes : **Vérifications**, **Package**, **Transfert**, **Restauration** et **Mise en ligne**. Sur le nouveau serveur, un installeur autonome restaure la boutique et réécrit tout ce qui dépend de l'ancien serveur.
Votre boutique actuelle est seulement lue : les fichiers sont ouverts en lecture seule et la base de données est exportée par des requêtes de lecture. Le module n'écrit que dans son propre dossier de stockage.
Le module fonctionne sur PrestaShop 1.7.8 à 9.x avec PHP 7.1 à 8.5. Le back-office et l'installeur sont traduits en anglais, français, espagnol, allemand, italien, polonais, néerlandais et portugais.
## Installation
1. Dans **Modules > Gestionnaire de modules**, cliquez sur **Installer un module** et déposez le fichier `dfservermigration-2.0.1.zip`.
2. Ouvrez **Paramètres avancés > Migration de serveur**.
Seuls les super administrateurs peuvent utiliser le module : un package contient toute la base de données de la boutique.
## Étape 1 : vérifications
La première étape analyse la boutique et le serveur. Les quatre tuiles du haut indiquent les fichiers à copier, la base de données, le package estimé (compressé, avec le pire des cas sans compression) et l'espace disque libre. Un bandeau résume le résultat : tout est prêt, points à surveiller ou points bloquants.
Vérifications préalables et analyse de la taille.
### Vérifications préalables
- **Version et extensions PHP** : pdo_mysql est obligatoire ; zlib, cURL et OpenSSL sont recommandés (compression, transfert direct, chiffrement du mot de passe HTTP).
- **max_execution_time** et **memory_limit** : le travail est découpé en étapes de quelques secondes, toute limite de temps convient donc.
- **upload_max_filesize / post_max_size** : sans incidence sur cette boutique. Sur le nouveau serveur, l'installeur adapte la taille des blocs de transfert à ses propres limites.
- **Stockage des packages** : hors de la racine web quand l'hébergement le permet. Sinon, un dossier aléatoire protégé par des règles d'interdiction, et votre navigateur vérifie qu'aucun package ne peut être téléchargé depuis le web.
- **Espace disque libre** : comparé au package estimé. Si votre hébergeur désactive `disk_free_space()`, un avertissement remplace la mesure : vérifiez l'espace dans votre panneau d'hébergement.
- **Serveur de base de données** : version et max_allowed_packet.
### Analyse de la taille
Les dossiers et les tables les plus volumineux sont listés avec un bouton **Exclure**. Si une autre installation PrestaShop est détectée dans un sous-dossier (copie de préproduction, ancienne boutique), un message vous propose de l'exclure.
## Étape 2 : le package
### Que faut-il inclure ?
- **Fichiers + base de données** : la migration complète.
- **Base de données uniquement** : la synchronisation finale des commandes et des clients juste avant la bascule.
- **Fichiers uniquement** : thèmes, images, modules.
Les caches, les journaux, les sauvegardes de 1-Click Upgrade et les dossiers Git sont exclus par défaut. Vous pouvez aussi exclure les miniatures générées (à régénérer ensuite dans **Apparence > Images**), ajouter vos propres motifs (un par ligne, `*` à l'intérieur d'un dossier, `**` à travers plusieurs dossiers) et ignorer les fichiers au-delà d'une certaine taille. L'option **Base de données allégée** exporte les statistiques visiteurs et les journaux sous forme de tables vides.
**Liens symboliques** : les liens qui pointent à l'intérieur de la boutique sont recréés comme des liens. Les liens qui pointent hors de la boutique, par exemple un dossier uploads stocké ailleurs, sont copiés comme de vrais dossiers : le nouveau serveur ne possède pas leur cible. Les liens cassés, les boucles et les dossiers système sont écartés et listés dans le rapport. Vous pouvez désactiver ce comportement avec l'option **Copier le contenu des liens symboliques qui pointent hors de la boutique**.
Options du package et estimation.
### Créer le package
Cliquez sur **Créer le package**. Le panneau affiche les phases (analyse, export de la base de données, empaquetage, vérification), les compteurs, la vitesse, le temps restant et le journal. Vous pouvez quitter la page : à votre retour, la création reprend là où elle s'était arrêtée. Le journal est téléchargeable à tout moment.
Création en cours.
À la fin, le package est vérifié puis listé avec son contenu, sa taille, l'espace nécessaire sur le nouveau serveur et sa date de suppression automatique (3 jours par défaut, réglable dans les paramètres avancés).
Package prêt.
## Espace disque
Avant de démarrer, le module compare l'espace libre au package estimé. Si le package ne tient pas, le démarrage est refusé, chiffres et solution à l'appui. Vous pouvez tout de même lancer la création : elle est protégée.
Espace insuffisant pour le package estimé.
Pendant la création, le module garde au moins 128 Mo libres pour que la boutique en ligne continue de fonctionner. Si l'espace vient à manquer, la création se met en pause et indique combien d'espace il faut encore et que faire. Libérez de l'espace ou excluez des dossiers, puis cliquez sur **Réessayer** : la création reprend là où elle s'était arrêtée. **Supprimer les fichiers partiels** l'annule proprement.
Création mise en pause avant que le disque soit plein.
## Étape 3 : transfert
### Placer l'installeur sur le nouveau serveur
Téléchargez `dfsm-installer.php` et envoyez-le dans le dossier qui hébergera la boutique (en général `public_html` ou `www`). Le nouveau serveur a besoin de PHP et d'une base de données vide, pas de PrestaShop. Chaque installeur est valable 3 jours par défaut et protégé par la **clé de migration** affichée à côté du bouton.
### Transfert direct (recommandé)
1. Saisissez l'adresse de l'installeur sur le nouveau serveur. Avant la bascule du DNS, utilisez l'adresse temporaire fournie par le nouvel hébergeur.
2. Cliquez sur **Tester la connexion** : le module vérifie la version de l'installeur, la version de PHP adaptée à votre version de PrestaShop, l'espace libre pour ce package et l'accès en écriture.
3. Choisissez le package et cliquez sur **Envoyer vers le nouveau serveur**.
Le package voyage en blocs signés en HMAC-SHA256. Un transfert interrompu reprend à partir du dernier octet confirmé, et **Arrêter** supprime le fichier partiel sur le nouveau serveur. Pour un dossier protégé ou un serveur sans certificat valide, ouvrez **Authentification HTTP et SSL**.
Contrôles de compatibilité et transfert terminé.
### Télécharger et envoyer par FTP
Téléchargez le package depuis la liste et envoyez-le à côté de `dfsm-installer.php`, en mode binaire. L'installeur le trouve tout seul et refuse un fichier tronqué.
## Étape 4 : restaurer avec l'installeur
1. Ouvrez `dfsm-installer.php` dans votre navigateur, choisissez votre langue et saisissez la clé de migration.
2. Choisissez le package reçu ou déposé.
3. Vérifiez le nouveau serveur : PHP comparé aux versions prises en charge par votre version de PrestaShop, extensions, espace libre comparé au package, accès en écriture, limites, site existant dans le dossier.
4. Saisissez la nouvelle base de données et testez la connexion. L'installeur compare le serveur à la source, vérifie max_allowed_packet et compte les tables qui utilisent déjà le préfixe.
5. Vérifiez les domaines : une ligne par URL de boutique, avec le nouveau domaine, le nouveau domaine SSL et le dossier de base. Vous pouvez aussi changer le préfixe des tables.
6. Cliquez sur **Lancer la restauration**.
Vérifications, base de données et domaines dans l'installeur.
La restauration extrait les fichiers, recrée les liens symboliques de PrestaShop 9, importe la base de données, met à jour `ps_shop_url` et les paramètres de domaine de chaque boutique, remplace les anciennes URL dans toutes les tables (données sérialisées comprises, adresses e-mail intactes), écrit `app/config/parameters.php`, laisse PrestaShop régénérer le `.htaccess` et vide les caches. Gardez la page ouverte ; si elle se ferme, rouvrez l'installeur et la restauration reprend.
Restauration en cours.
### Après la restauration
Le dernier écran affiche les chiffres de la restauration, les vérifications automatiques (connexion à la base de données, URL principale de la boutique, .htaccess, dossier du back-office, dossiers accessibles en écriture, page d'accueil) et une checklist de mise en ligne. Le package et le mot de passe de la base de données sont déjà supprimés du serveur. Cliquez sur **Supprimer l'installeur maintenant** une fois la boutique vérifiée ; sinon, il se supprime de lui-même 24 heures plus tard.
Migration terminée.
## Étape 5 : mise en ligne
La checklist du back-office garde la trace des dernières tâches : tester la nouvelle boutique, figer l'ancienne et synchroniser les dernières données avec un package base de données uniquement, DNS, certificat SSL, tâches cron, e-mails, cache, webhooks de paiement, SEO et nettoyage.
Checklist de mise en ligne.
Pour ne perdre aucune commande : testez la nouvelle boutique, activez la maintenance sur l'ancienne, créez un package **Base de données uniquement** et restaurez-le avec un nouvel installeur. Les accès à la base de données de la boutique déjà restaurée sont préremplis ; laissez le mot de passe vide pour conserver l'actuel.
## Sécurité
- Les packages sont stockés hors de la racine web quand c'est possible, et supprimés automatiquement après la durée de conservation.
- Le mot de passe HTTP du nouveau serveur est chiffré dans la configuration.
- L'installeur exige la clé de migration, refuse les requêtes non signées, scelle le mot de passe de la base de données et l'efface à la fin, puis se supprime 24 heures après la restauration ou à son expiration.
- **Nouvelle clé**, à l'étape 3, invalide tous les installeurs téléchargés auparavant.
## Dépannage
### Les packages PEUVENT être téléchargés depuis le web
Votre serveur ignore le `.htaccess` (Nginx). Ajoutez une règle qui interdit l'accès à `/modules/dfservermigration/var/` avant de créer un package.
### Le nouveau serveur refuse la connexion ou demande un identifiant
Vérifiez l'adresse de l'installeur (http ou https, www). En cas d'erreur HTTP 401, remplissez les champs d'authentification HTTP. En cas d'erreur HTTP 413, réduisez la taille des blocs de transfert dans les paramètres avancés.
### L'installeur a refusé la clé de migration
Une nouvelle clé a été générée depuis le téléchargement de l'installeur, ou les horloges des deux serveurs ont plus de 15 minutes d'écart. Téléchargez à nouveau l'installeur.
### Erreur SQL pendant l'import
L'installeur indique la table et le détail de l'erreur. Pour max_allowed_packet, demandez à votre hébergeur de le porter à 16 Mo ou plus, puis cliquez sur **Réessayer** : la table en cours est réimportée.
### Le .htaccess n'a pas pu être régénéré
Le domaine y a tout de même été mis à jour. Enregistrez une fois la page **Paramètres de la boutique > Trafic et SEO** dans le nouveau back-office.