Migrer un site WordPress sans casse : DB, fichiers, DNS

Si vous avez déjà vu un site “migré” qui affiche des images cassées, des redirections étranges ou un écran blanc au moment de basculer le DNS, vous avez déjà rencontré les trois vrais ennemis d’une migration WordPress : les URLs, la sérialisation et le timing DNS.

Ce qu’on va construire

Vous allez mettre en place une migration WordPress complète (WordPress 6.9.4, PHP 8.1+) : export/import de base de données, transfert des fichiers, ajustement de wp-config.php, remplacement d’URLs sans casser les données sérialisées, puis bascule DNS avec un minimum d’indisponibilité.

Ce pas-à-pas vise les sites “classiques” : blog, site vitrine, WooCommerce léger à moyen, avec ou sans page builder (Divi 5, Elementor, Avada). Pour un WooCommerce très actif (beaucoup de commandes par heure), je vous donne plus bas une alternative plus sûre.

À la fin, vous saurez :

préparer un nouveau serveur propre (PHP, DB, SSL) et reproductible ;
migrer fichiers + base en gardant l’encodage et les permissions ;
faire un search/replace d’URLs sans corruption ;
basculer le DNS proprement (TTL, double-serve, validation) ;
diagnostiquer les 5 pannes les plus fréquentes post-migration.

Résumé rapide

Abaissez le TTL DNS 24–48h avant la bascule (sinon vous “subissez” les caches).
Sauvegardez fichiers + DB, puis testez la restauration sur un environnement de staging.
Transférez tout : wp-content, mais aussi .htaccess (ou règles Nginx), wp-config.php, et les uploads.
Importez la base, puis faites un remplacement d’URL avec WP-CLI search-replace (gestion de la sérialisation).
Avant le DNS : testez via le fichier hosts et vérifiez SSL, permaliens, cron, mails sortants.

Quand utiliser cette solution

Vous changez d’hébergeur, de serveur, ou vous passez d’un mutualisé à un VPS.
Vous gardez la même URL (même domaine) mais changez d’IP.
Vous changez de domaine et vous êtes prêt à gérer redirections + SEO (possible avec ce guide).
Vous avez accès à SSH (idéal), ou au minimum à phpMyAdmin + SFTP.

Quand ne PAS utiliser cette solution

WooCommerce avec trafic/commandes en continu : un simple export/import peut perdre des commandes pendant la fenêtre de migration.
Sites multisites complexes : les migrations demandent des étapes spécifiques (tables, domaines mappés, uploads).
Vous n’avez pas les accès nécessaires (pas de DB, pas de fichiers, pas de DNS) : récupérez-les d’abord.
Vous voulez “profiter” de la migration pour changer 15 choses (thème, builder, structure d’URL, plugins) : séparez les chantiers, sinon le diagnostic devient impossible.

Avant de commencer (prérequis)

Pré-requis techniques

WordPress : 6.9.4 (ou plus récent) sur l’ancien et le nouveau serveur.
PHP : 8.1 minimum recommandé (8.2/8.3 souvent plus confortable selon l’hébergeur).
Accès : DNS (registrar/zone), fichiers (SFTP/SSH), base de données (MySQL/MariaDB).
Outils recommandés : WP-CLI, rsync, mysqldump (si vous avez SSH).

Sauvegarde et environnement de test

Ne testez pas “directement en prod”. J’ai souvent vu des migrations se transformer en incident parce que quelqu’un a fait un search/replace sur la mauvaise base.

Créez un staging (sous-domaine, ou serveur temporaire) pour valider la restauration.
Faites une sauvegarde complète avant chaque manipulation lourde (export DB, transfert fichiers, search/replace).

Précautions de sécurité

Manipuler une base de données implique des données sensibles : limitez les accès, chiffrez si possible, et supprimez les dumps après usage.
Évitez d’envoyer un .sql par e-mail ou via un lien public.
Si vous modifiez wp-config.php, faites-le via un canal sûr (SSH/SFTP), et vérifiez les permissions.

Sources officielles utiles (vous y reviendrez)

Étape 1 : Auditer l’existant (et éviter les surprises)

Le but : savoir ce que vous migrez réellement (taille, dépendances, règles serveur). Une migration “ratée” vient souvent d’un point ignoré : un cache serveur, une règle Nginx oubliée, un cron externe, un SMTP, ou un plugin qui écrit hors de wp-content.

1) Relever les versions et la taille

Si vous avez WP-CLI :

# Version WordPress
wp core version

# Infos environnement (utile pour comparer ancien/nouveau)
wp --info

# Liste plugins et thèmes (vous repérerez les suspects)
wp plugin list
wp theme list

Sans WP-CLI, notez au minimum :

Version WordPress (Tableau de bord > Mises à jour)
Version PHP (Outils > Santé du site > Info)
Taille du dossier wp-content/uploads (souvent le plus lourd)

2) Repérer les règles serveur et fichiers “invisibles”

Sur Apache, vérifiez .htaccess. Sur Nginx, vérifiez la conf du vhost. Beaucoup de problèmes de permaliens après migration viennent de là.

Relevez les redirections (HTTP->HTTPS, www/non-www, anciennes URLs).
Relevez les règles de cache serveur (FastCGI cache, varnish, etc.).

3) Lister ce qui dépend du domaine/IP

SMTP (plugin type WP Mail SMTP), API externes (reCAPTCHA, Stripe, etc.).
Webhooks, CRON externes, tâches planifiées côté serveur.
CDN (Cloudflare, Bunny, etc.) : notez les réglages.

Résultat attendu

Vous avez une checklist : versions, taille, règles serveur, dépendances. Vous savez si la migration est “simple” ou si elle nécessite une fenêtre de maintenance.

Étape 2 : Sauvegarder proprement la base de données et les fichiers

Méthode A (recommandée) : SSH + WP-CLI + mysqldump

Je préfère mysqldump à certains exports phpMyAdmin sur des grosses bases : c’est plus stable et scriptable.

1) Mettre le site en mode maintenance (optionnel mais conseillé)

Si votre site bouge (commentaires, commandes), activez une page maintenance courte, le temps du dump final.

Avec WP-CLI :

# Active la maintenance
wp maintenance-mode activate

2) Export DB

# Export DB avec WP-CLI (pratique et souvent suffisant)
wp db export ~/backup-avant-migration.sql

# Alternative : mysqldump (utile si vous voulez contrôler plus finement)
# Remplacez DB_NAME / DB_USER / DB_HOST si besoin
mysqldump --single-transaction --quick --routines --triggers 
  -u "DB_USER" -p "DB_NAME" > ~/backup-avant-migration.sql

3) Sauvegarde fichiers

Le plus fiable : un tar + rsync.

# Archive complète (inclut fichiers cachés si vous le faites depuis la racine du site)
cd /var/www/votre-site
tar -czf ~/backup-files-avant-migration.tar.gz .

# Ou au minimum : wp-content + wp-config.php + règles serveur
tar -czf ~/backup-min-avant-migration.tar.gz wp-content wp-config.php .htaccess

Méthode B : sans SSH (phpMyAdmin + SFTP)

phpMyAdmin : exportez la base en SQL (gzip si possible).
SFTP : téléchargez tout le site, ou au minimum wp-content + wp-config.php + .htaccess.

Erreur fréquente : ne télécharger que wp-content et oublier que certains hébergeurs ont des mu-plugins dans wp-content/mu-plugins (ou des fichiers dans wp-content/advanced-cache.php).

Résultat attendu

Vous avez 2 artefacts : un dump SQL et une archive des fichiers (ou un dossier complet). Stockez-les hors serveur (local ou stockage privé).

Étape 3 : Préparer le nouveau serveur (PHP 8.1+, DB, vhost, SSL)

1) Créer la base et l’utilisateur

Sur MySQL/MariaDB, créez une base dédiée et un utilisateur dédié (pas root).

# Exemple SQL (à exécuter dans un client MySQL)
# Adaptez nom de base, user, mot de passe et host
CREATE DATABASE wp_prod CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'motdepasse-tres-fort';
GRANT ALL PRIVILEGES ON wp_prod.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;

2) Préparer le répertoire web

Créez un dossier vide pour le site, puis prévoyez le propriétaire correct (souvent www-data sur Debian/Ubuntu).

mkdir -p /var/www/votre-site
chown -R www-data:www-data /var/www/votre-site

3) Installer WordPress (option staging)

Deux approches :

Soit vous copiez votre WordPress existant (ce qu’on fait dans ce guide).
Soit vous installez un WordPress “neuf” puis vous remplacez wp-content et importez la DB. Ça peut aider à valider que le serveur est sain.

Avec WP-CLI (optionnel) :

cd /var/www/votre-site
wp core download --locale=fr_FR

4) SSL et HTTPS

Activez HTTPS avant la bascule DNS si possible. Sinon, vous allez tester un site en HTTP puis basculer en HTTPS plus tard, et vous multipliez les variables.

Si vous utilisez Let’s Encrypt, vérifiez que le challenge est possible (DNS pas encore basculé : utilisez un challenge DNS si votre outil le permet, ou testez après bascule).

Résultat attendu

Le serveur est prêt : PHP 8.1+, base créée, dossier web prêt, et vous savez comment vous allez activer SSL.

Étape 4 : Transférer les fichiers WordPress (et préserver les permissions)

Méthode A (recommandée) : rsync

Rsync évite de re-copier ce qui n’a pas changé et conserve mieux les attributs.

# Depuis l'ancien serveur vers le nouveau (exemple)
# Adaptez user, host, chemins
rsync -avz --delete 
  /var/www/votre-site/ 
  user@nouveau-serveur:/var/www/votre-site/

Note : --delete supprime sur la destination ce qui n’existe plus à la source. Très pratique, mais dangereux si vous vous trompez de chemin.

Méthode B : tar + upload

# Sur l'ancien serveur
cd /var/www/votre-site
tar -czf ~/site.tar.gz .

# Sur le nouveau serveur
cd /var/www/votre-site
tar -xzf ~/site.tar.gz

Permissions recommandées (général)

Les permissions exactes dépendent de votre stack, mais en pratique :

dossiers : 755
fichiers : 644
wp-config.php : 640 ou 600 si possible

# Exemple : ajustement basique (à adapter à votre hébergeur)
find /var/www/votre-site -type d -exec chmod 755 {} ;
find /var/www/votre-site -type f -exec chmod 644 {} ;
chmod 640 /var/www/votre-site/wp-config.php
chown -R www-data:www-data /var/www/votre-site

Résultat attendu

Les fichiers sont présents sur le nouveau serveur, avec des permissions cohérentes. Le site n’est pas encore “fonctionnel” tant que la DB et la config ne sont pas alignées.

Étape 5 : Migrer la base de données (export/import + encodage)

1) Importer le dump

Avec WP-CLI :

# Placez le .sql sur le nouveau serveur, puis :
cd /var/www/votre-site
wp db import ~/backup-avant-migration.sql

Ou avec MySQL :

mysql -u "wp_user" -p "wp_prod" < ~/backup-avant-migration.sql

2) Vérifier l’encodage (utf8mb4)

La plupart des sites modernes sont en utf8mb4. Si vous migrez depuis un vieux site, vous pouvez tomber sur un mélange d’encodages. Ne “forcez” pas au hasard : vérifiez.

# Vérifie le charset par défaut de la base
mysql -u "wp_user" -p -e "SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME='wp_prod';"

Résultat attendu

La base est importée sur le nouveau serveur, et vous avez confirmé un charset/collation cohérents (idéalement utf8mb4).

Étape 6 : Ajuster wp-config.php (URLs, salts, debug, proxy)

En migration, le wp-config.php est votre point de contrôle : DB, debug, et parfois forçage d’URL pour éviter les boucles de redirection pendant les tests.

1) Mettre à jour les identifiants DB

Dans /var/www/votre-site/wp-config.php (via SFTP/SSH), ajustez :

<?php
// ... fichier existant ...

/** Nom de la base de données de WordPress */
define( 'DB_NAME', 'wp_prod' );

/** Identifiant de la base de données */
define( 'DB_USER', 'wp_user' );

/** Mot de passe de la base de données */
define( 'DB_PASSWORD', 'motdepasse-tres-fort' );

/** Adresse de l’hébergement de la base de données */
define( 'DB_HOST', 'localhost' );

// Encodage recommandé (souvent déjà présent)
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

2) Activer un debug “propre” le temps de la migration

Sur un serveur de test, je mets presque toujours un log. Sur prod, évitez d’afficher les erreurs à l’écran.

<?php
// À placer dans wp-config.php, avant "/* That's all, stop editing! */"

// Active le debug WordPress (ne pas laisser sur true en production longtemps)
define( 'WP_DEBUG', true );

// Évite l'affichage public des erreurs
define( 'WP_DEBUG_DISPLAY', false );

// Log dans wp-content/debug.log (vérifiez que le fichier n'est pas exposé publiquement)
define( 'WP_DEBUG_LOG', true );

3) Forcer temporairement l’URL (utile pour tests avant DNS)

Quand vous testez via /etc/hosts ou une URL temporaire, WordPress peut rediriger vers l’ancienne URL stockée en base. Vous pouvez forcer :

<?php
// Forçage temporaire pendant la migration.
// À retirer après la bascule DNS si vous revenez à l'URL normale.
define( 'WP_HOME', 'https://www.exemple.com' );
define( 'WP_SITEURL', 'https://www.exemple.com' );

Anti-pattern courant : laisser ces constantes en place alors que vous avez changé de domaine. Résultat : redirections en boucle, ou impossibilité de se connecter à l’admin.

Résultat attendu

Le WordPress du nouveau serveur pointe vers la bonne base et peut être debuggué proprement. Les redirections “fantômes” sont sous contrôle.

Étape 7 : Remplacer les URLs sans casser les données sérialisées

C’est ici que beaucoup de migrations “semblent marcher” puis cassent : widgets, builders, options de thème, champs ACF… Une recherche/remplacement SQL naïve casse les chaînes sérialisées (longueurs incorrectes).

Méthode recommandée : WP-CLI search-replace

WP-CLI sait gérer la sérialisation. Référence officielle : developer.wordpress.org.

1) D’abord, un dry-run

cd /var/www/votre-site

# Exemple : passage de http à https
wp search-replace 'http://www.exemple.com' 'https://www.exemple.com' --dry-run

2) Puis exécution réelle

cd /var/www/votre-site

wp search-replace 'http://www.exemple.com' 'https://www.exemple.com' 
  --all-tables 
  --precise 
  --recurse-objects

Pourquoi ces options :

–all-tables : utile si des plugins ont créé des tables custom.
–precise : plus lent, mais réduit les surprises (j’ai vu des faux positifs sur des contenus volumineux).
–recurse-objects : aide sur certains objets sérialisés complexes.

Cas “changement de domaine”

Faites au minimum :

ancien domaine -> nouveau domaine (http)
ancien domaine -> nouveau domaine (https)
www vs non-www selon votre canonique

# Exemple : exemple-ancien.com vers exemple-nouveau.com
wp search-replace 'https://www.exemple-ancien.com' 'https://www.exemple-nouveau.com' --all-tables --precise --recurse-objects
wp search-replace 'http://www.exemple-ancien.com'  'https://www.exemple-nouveau.com' --all-tables --precise --recurse-objects

Vérifier home/siteurl

wp option get home
wp option get siteurl

Résultat attendu

Les URLs en base correspondent au nouveau contexte. Les pages builder, widgets et options ne sont pas corrompus.

Étape 8 : Basculer DNS sans coupure (TTL, A/AAAA, CNAME)

Le DNS est simple techniquement, mais impitoyable sur le timing. Le piège classique : changer l’IP sans avoir baissé le TTL. Vous passez ensuite 6–24h à répondre “chez moi ça marche”.

1) 24–48h avant : baisser le TTL

Dans la zone DNS (registrar ou DNS manager), baissez le TTL des enregistrements concernés (A/AAAA/CNAME) à 300s (5 min) si possible.

2) Tester le nouveau serveur avant la bascule (fichier hosts)

Avant de toucher au DNS public, testez localement en pointant le domaine vers la nouvelle IP.

Sur macOS/Linux :

# Éditez /etc/hosts (avec sudo) et ajoutez :
# 203.0.113.10   www.exemple.com exemple.com

sudo nano /etc/hosts

Sur Windows, le fichier est dans C:WindowsSystem32driversetchosts.

Ensuite :

Testez le front, puis /wp-admin.
Vérifiez que le SSL présente le bon certificat (sinon, normal si pas encore émis).

3) Jour J : basculer A/AAAA/CNAME

Si vous changez d’hébergeur : modifiez l’enregistrement A (IPv4) vers la nouvelle IP.
Si vous avez AAAA (IPv6), mettez-le aussi à jour (sinon une partie des visiteurs ira ailleurs).
Si votre cible est un host (ex: proxy.exemple.net), mettez à jour le CNAME.

4) Garder l’ancien serveur en “filet de sécurité”

Ne coupez pas l’ancien serveur tout de suite. Gardez-le 48–72h, le temps que les caches DNS se vident vraiment (et que vous ayez identifié les clients “bloqués” sur l’ancienne IP).

Résultat attendu

Le trafic bascule progressivement vers le nouveau serveur. Vous pouvez comparer logs et métriques entre les deux.

Étape 9 : Post-migration WordPress (permaliens, cache, cron, mails)

1) Régénérer les permaliens

Après migration, c’est une action simple qui répare beaucoup de 404.

Admin WordPress > Réglages > Permaliens
Sans rien changer, cliquez “Enregistrer les modifications”

Avec WP-CLI :

wp rewrite flush --hard

2) Vider les caches

J’ai souvent croisé des “bugs” qui étaient juste un cache : plugin cache, cache serveur, cache CDN, cache navigateur.

Videz le cache de votre plugin (si présent).
Si vous avez un CDN (Cloudflare, etc.), purge.
Videz l’OPcache côté serveur si vous avez la main (ou redémarrez PHP-FPM).

3) Vérifier WP-Cron

Si votre ancien hébergeur avait un cron système, vous devez le recréer. Sinon, WordPress retombe sur WP-Cron “visiteur-dépendant”.

Référence : developer.wordpress.org (WP-Cron).

4) Vérifier les e-mails sortants

Après migration, les e-mails peuvent tomber en spam (IP différente) ou ne plus partir (SMTP non configuré). Faites un test de formulaire et un reset de mot de passe.

5) Désactiver la maintenance

wp maintenance-mode deactivate

Résultat attendu

Le site répond sans 404 anormales, les caches sont cohérents, et les tâches planifiées/e-mails fonctionnent.

Le résultat complet

Si vous voulez tout rejouer d’un coup (sur un environnement de test), voici un script “checklist” en shell. Adaptez les variables et exécutez étape par étape. Ne lancez pas ça en aveugle sur une prod.

# Variables (à adapter)
OLD_PATH="/var/www/votre-site"
NEW_PATH="/var/www/votre-site"
DUMP_PATH="$HOME/backup-avant-migration.sql"

OLD_URL="http://www.exemple.com"
NEW_URL="https://www.exemple.com"

# 1) (Ancien) Export DB
cd "$OLD_PATH"
wp maintenance-mode activate
wp db export "$DUMP_PATH"
wp maintenance-mode deactivate

# 2) (Ancien -> Nouveau) Transfert fichiers (exemple rsync)
# rsync -avz --delete "$OLD_PATH/" user@nouveau-serveur:"$NEW_PATH/"

# 3) (Nouveau) Import DB
cd "$NEW_PATH"
wp db import "$DUMP_PATH"

# 4) (Nouveau) Search/replace sécurisé
wp search-replace "$OLD_URL" "$NEW_URL" --all-tables --precise --recurse-objects

# 5) (Nouveau) Flush permaliens
wp rewrite flush --hard

Personnalisation utile

Si vous changez de domaine, faites plusieurs passes (http/https, www/non-www).
Si vous avez des tables très volumineuses (logs), vous pouvez exclure certaines tables avec --skip-tables (voir doc WP-CLI).
Si vous utilisez un reverse proxy, ajustez la détection HTTPS (voir section dépannage).

Adapter pour Divi 5 / Elementor / Avada

Divi 5

Divi stocke beaucoup de contenu sous forme de structures (souvent sérialisées/JSON selon les versions/modules). Un search/replace SQL brut est le meilleur moyen de casser des modules.

Faites le remplacement d’URL avec WP-CLI search-replace (pas avec un export/import “find replace” de texte).
Après migration : Divi > Options du thème > Builder > “Vider”/“Clear” (si options présentes) pour régénérer certains caches.

Elementor

Elementor propose un outil de remplacement d’URL dans son interface, mais je l’utilise plutôt en complément. Mon flux habituel : WP-CLI d’abord, puis outil Elementor si un widget garde une ancienne URL.

Elementor > Outils : Regenerate CSS & Data (selon libellés de version).
Vérifiez les polices/icônes si vous avez un CDN.

Avada (Fusion Builder)

Avada/Fusion a aussi des caches et des assets compilés. Après migration :

Purger/Regenerate les caches d’assets dans Avada > Performance (selon version).
Si vous avez changé de domaine, vérifiez les URLs dans les options du thème (logo, images globales).

Point commun : l’éditeur de blocs

Avec WordPress 6.9.4, beaucoup de contenus sont en blocs (HTML commenté). Un search/replace via WP-CLI fonctionne bien, mais surveillez les blocs “réutilisables” (synced patterns) si vous avez des URLs en dur.

Vérification finale

Checklist fonctionnelle (10 minutes)

Front : page d’accueil, 2–3 articles, une page, une recherche.
Admin : connexion, édition d’un article, médiathèque (upload + affichage).
Permaliens : pas de 404 sur les pages principales.
HTTPS : cadenas OK, pas de “mixed content” visible.
Formulaire : envoi + réception e-mail.
Tâches : une action planifiée s’exécute (ou au moins WP-Cron est actif).

Tableau de diagnostic (rapide)

Symptôme	Cause probable	Vérification	Solution
Redirection en boucle vers l’ancien domaine	`home/siteurl` ou `WP_HOME` forcé	`wp option get home`, inspecter `wp-config.php`	Corriger options ou retirer les constantes temporaires
Images cassées après migration	Search/replace incomplet, URLs en dur	Voir source HTML, chercher ancien domaine	Relancer `wp search-replace`, purger caches builder/CDN
404 sur toutes les pages sauf l’accueil	Règles de réécriture absentes (Apache/Nginx)	Tester `/index.php?p=123`, vérifier conf serveur	Flush permaliens + config vhost correcte
Écran blanc / erreur 500	Version PHP/extension manquante, plugin incompatible	Logs PHP-FPM/Apache/Nginx, `wp-content/debug.log`	Mettre PHP 8.1+, désactiver plugin fautif, corriger permissions
Certificat SSL invalide	Certificat non émis pour le domaine, SNI mal configuré	Tester avec navigateur + openssl s_client	Émettre/installer le bon certificat, vérifier vhost

Si le résultat n’est pas celui attendu

1) Vous avez une boucle de redirection (HTTP/HTTPS ou www/non-www)

Le problème vient souvent d’un doublon : redirection au niveau WordPress + redirection au niveau serveur + redirection CDN.

Vérifiez WP_HOME/WP_SITEURL dans wp-config.php.
Vérifiez home/siteurl en base : wp option get home.
Vérifiez les règles serveur (Apache/Nginx) et Cloudflare (si utilisé).

2) Vous voyez un écran blanc ou une erreur fatale

Activez les logs (WP_DEBUG_LOG) et consultez wp-content/debug.log.
Vérifiez la version PHP : une migration vers un serveur resté en PHP 7.4 arrive encore, et WordPress 6.9.4 + plugins modernes n’aiment pas ça.

Test rapide : désactiver tous les plugins via WP-CLI :

wp plugin deactivate --all

3) Les permaliens ne fonctionnent pas (404)

Flush permaliens (admin ou WP-CLI).
Sur Nginx, vérifiez que la règle “try_files” WordPress est correcte (sinon WordPress ne reçoit jamais la requête).

4) Les médias ne s’uploadent plus

Permissions sur wp-content/uploads.
Espace disque.
Chemin temporaire PHP (rare, mais déjà vu sur serveurs durcis).

5) “Chez moi ça marche, pas chez le client”

Propagation DNS : vérifiez l’IP résolue (dig/nslookup) depuis différents réseaux.
Cache navigateur : test en navigation privée.
Cache CDN : purge.

Pièges et erreurs courantes

Erreur	Cause	Solution
Faire un search/replace via SQL brut	Données sérialisées corrompues	Utiliser `wp search-replace` (WP-CLI) ou un outil qui gère la sérialisation
Oublier de baisser le TTL DNS	Propagation longue et incohérente	Baisser à 300s 24–48h avant, garder l’ancien serveur 48–72h
Copier le code au mauvais endroit dans wp-config.php	Erreur PHP, site HS	Placer les `define()` avant la ligne “stop editing”, vérifier les points-virgules
Tester directement en production sans sauvegarde	Retour arrière difficile	Staging + sauvegardes versionnées (DB + fichiers)
Permaliens cassés après migration	Règles serveur manquantes / rewrite non activé	Flush permaliens + vérifier conf Apache/Nginx
Snippet cassé par un plugin de snippets	Ordre de chargement ou PHP incompatible	Désactiver le snippet, remettre via `mu-plugins` si nécessaire, vérifier PHP 8.1+

Variante / alternative

Alternative 1 : migration “sans code” via plugin (pratique, mais à encadrer)

Pour des sites modestes, un plugin de migration peut être plus simple. Le risque : limites d’upload, timeouts, et parfois des archives incomplètes sur gros uploads.

Choisissez un plugin maintenu activement et compatible WordPress 6.9.4.
Vérifiez qu’il gère la sérialisation et les URLs.
Testez la restauration sur staging avant de toucher au DNS.

Alternative 2 (WooCommerce actif) : “freeze” + delta ou fenêtre maintenance

Si vous avez des commandes en continu, la méthode export/import simple peut perdre des données entre le dump et la bascule DNS.

Option la plus sûre : fenêtre maintenance courte (freeze), dump final, bascule.
Option avancée : réplication DB ou outils de synchronisation (selon hébergeur). Ça dépasse le cadre d’un tutoriel “intermédiaire”, mais c’est la direction à prendre.

Conseils sécurité, performance et maintenance

Sécurité

Regénérez les clés de sécurité si nécessaire (salts) via le service officiel, puis mettez à jour wp-config.php : WordPress.org salts.
Vérifiez les comptes admin et supprimez les comptes inutiles.
Assurez-vous que wp-content/debug.log n’est pas accessible publiquement (selon serveur).

Performance

Activez un cache de page adapté (plugin ou serveur). Ne faites pas ça avant d’avoir validé la migration, sinon vous diagnostiquerez du cache au lieu du fonctionnel.
Vérifiez la version de PHP et OPcache. PHP 8.2/8.3 + OPcache bien configuré fait une vraie différence.
Sur gros sites, évitez --precise en prod en heure de pointe : faites le search/replace sur staging, puis reproduisez hors trafic.

Maintenance

Documentez : nouvelle IP, accès, versions, emplacement des sauvegardes.
Mettez en place des sauvegardes automatiques et testez une restauration (au moins une fois).
Surveillez les logs 48h après la bascule (404, erreurs PHP, timeouts).

Pour aller plus loin

Automatiser la migration avec un script idempotent (Ansible, bash) et une checklist de validation.
Mettre en place un environnement de staging permanent (même stack que prod).
Ajouter des tests de monitoring externes (HTTP, SSL, DNS) et alertes.
Si vous changez de domaine : plan de redirections 301 + mise à jour Search Console.

Ressources

FAQ

Dois-je migrer tout WordPress ou seulement wp-content ?

Si vous copiez l’installation existante, migrez tout. Si vous réinstallez un core “neuf”, migrez au minimum wp-content, wp-config.php (ou ses valeurs), et importez la base. Dans les deux cas, n’oubliez pas les fichiers cachés et les règles serveur.

Pourquoi mes images ont encore l’ancien domaine après migration ?

Soit le search/replace n’a pas couvert toutes les tables, soit un builder garde des URLs dans une structure particulière, soit vous avez un CDN qui sert encore l’ancien contenu. Commencez par wp search-replace avec --all-tables, puis purge caches (builder/CDN).

Puis-je faire la migration sans WP-CLI ?

Oui, mais vous perdez l’outil le plus sûr pour la sérialisation. Si vous n’avez pas WP-CLI, utilisez un outil de remplacement d’URL qui gère explicitement la sérialisation (et faites une sauvegarde avant).

Qu’est-ce qui casse le plus souvent les migrations ?

Un remplacement d’URL “à la main”, un TTL DNS non abaissé, et des règles de rewrite serveur non recopiées (Apache/Nginx). Dans cet ordre, d’après ce que je vois le plus sur des sites clients.

Dois-je changer les salts WordPress après migration ?

Pas obligatoire, mais conseillé si vous soupçonnez une fuite (dump DB stocké au mauvais endroit, accès partagé, etc.). Changer les salts déconnecte toutes les sessions en cours.

Pourquoi /wp-admin redirige vers l’ancien serveur ?

Généralement : home/siteurl encore anciens, ou un WP_HOME/WP_SITEURL forcé dans wp-config.php. Vérifiez aussi un cache CDN qui garde une redirection.

Comment savoir si le DNS a vraiment basculé ?

Vérifiez la résolution depuis plusieurs réseaux (4G, VPN, serveur externe) avec dig/nslookup, et comparez l’IP. Sur votre machine, videz aussi le cache DNS si nécessaire.

Dois-je garder l’ancien serveur après la bascule ?

Oui, 48–72h est une bonne base. Vous évitez de “piéger” les visiteurs dont le DNS est encore sur l’ancienne IP, et vous pouvez comparer les logs.

Que faire si je change de domaine en plus d’hébergeur ?

Préparez un plan de redirections 301 (ancien -> nouveau), mettez à jour les URLs via wp search-replace, puis vérifiez les canonicals, le sitemap et la Search Console. Ne mélangez pas ça avec un changement de structure de permaliens le même jour.

Est-ce que WordPress 6.9.4 change quelque chose à la migration ?

Pas sur le principe. En revanche, l’écosystème plugins/builders stocke de plus en plus de données structurées : la règle “pas de search/replace SQL brut” est encore plus vraie en 2026.