Migrer WordPress vers un nouveau serveur avec WP-CLI et rsync

Migrer un site WordPress vers un nouveau serveur n’a pas besoin de ressembler à une opération à cœur ouvert pratiquée dans le noir. Avec WP-CLI, rsync et une méthode claire, vous pouvez déplacer un site proprement, vérifier chaque étape, puis basculer le DNS sans croiser les doigts trop fort.

Ce guide montre comment migrer WordPress vers un nouveau serveur avec WP-CLI : export de la base, transfert des fichiers, import SQL, remplacement des URLs, permissions, HTTPS, caches, emails, cron et vérifications finales.

L’objectif est simple : éviter les plugins de migration lourds, garder le contrôle technique, et pouvoir revenir en arrière si quelque chose coince.

Dans quels cas utiliser WP-CLI pour migrer WordPress ?

WP-CLI est idéal pour migrer un site WordPress lorsque vous avez accès au serveur en SSH.

Cette méthode convient très bien pour :

• déplacer WordPress vers un nouveau VPS ou serveur dédié ;
• migrer d’un hébergement mutualisé vers un serveur plus performant ;
• changer de stack Apache vers Nginx, ou inversement ;
• migrer un site client vers une infrastructure mieux maintenue ;
• cloner une production vers un staging ;
• changer de nom de domaine ou de sous-domaine ;
• restaurer un site à partir d’une sauvegarde propre.

En revanche, si vous n’avez aucun accès SSH, cette méthode ne sera pas adaptée. Dans ce cas, un plugin de migration ou une sauvegarde hébergeur peut dépanner. Mais dès que SSH est disponible, WP-CLI reste plus précis, plus rapide et plus contrôlable.

Vue d’ensemble de la migration

Une migration WordPress propre suit toujours la même logique :

• préparer le nouveau serveur ;
• faire une sauvegarde complète de l’ancien site ;
• transférer les fichiers avec rsync ;
• exporter puis importer la base avec WP-CLI ;
• adapter wp-config.php ;
• lancer un search-replace si l’URL change ;
• corriger les permissions ;
• tester le site sans basculer le DNS ;
• mettre à jour DNS et HTTPS ;
• vérifier caches, formulaires, emails et cron.

Le piège classique consiste à copier les fichiers, importer la base, puis déclarer victoire. WordPress aime les détails : URLs sérialisées, caches persistants, préfixe de tables, permissions, certificats, tâches cron, chemins absolus et emails sortants. Bref, tout le petit théâtre applicatif.

Pré-requis sur les deux serveurs

Avant de commencer, vérifiez que vous avez :

• un accès SSH sur l’ancien serveur ;
• un accès SSH sur le nouveau serveur ;
• WP-CLI installé sur les deux serveurs ;
• rsync disponible ;
• un utilisateur système avec les bons droits ;
• une base de données vide sur le nouveau serveur ;
• un virtual host Nginx ou Apache prêt ;
• un certificat TLS prêt ou générable après bascule DNS ;
• un plan de rollback.

Sur Debian ou Ubuntu, installez les outils utiles :

sudo apt update
sudo apt install rsync mariadb-client unzip curl

Vérifiez WP-CLI :

wp cli info

Si votre stack serveur n’est pas encore prête, vous pouvez partir de ce guide : installer Nginx, PHP et MariaDB sur Debian.

Étape 1 : vérifier l’ancien site WordPress

Sur l’ancien serveur, placez-vous dans la racine WordPress :

cd /home/www/example.com/public_html

Vérifiez que WP-CLI reconnaît bien le site :

wp core version
wp option get home
wp option get siteurl
wp db prefixLangage du code : JavaScript (javascript)

Contrôlez aussi la taille du site :

du -sh .
wp db size --tables

Ces informations vous donnent déjà une idée du temps de transfert et du risque. Une boutique WooCommerce de 40 Go ne se migre pas comme un blog de 250 Mo. Elle réclame un peu plus de respect, et parfois une fenêtre de maintenance.

Étape 2 : mettre le site en maintenance si nécessaire

Pour un site vitrine, vous pouvez souvent migrer sans maintenance stricte. Pour WooCommerce, un LMS, un forum ou un site membre, il faut éviter que des commandes, inscriptions ou paiements arrivent pendant le dernier export SQL.

Vous pouvez activer la maintenance juste avant le dernier export :

wp maintenance-mode activate

Et la désactiver après validation :

wp maintenance-mode deactivate

Sur WooCommerce, prévoyez plutôt une vraie fenêtre de bascule. Les paniers, sessions, webhooks, paiements et emails transactionnels n’aiment pas trop les migrations “en douce”. Ils ont le sens du timing dramatique.

Étape 3 : exporter la base de données avec WP-CLI

Créez un dossier de sauvegarde hors du webroot :

mkdir -p ~/backups/migration-wordpressLangage du code : JavaScript (javascript)

Exportez la base :

wp db export ~/backups/migration-wordpress/example-$(date +%F-%H%M%S).sql --add-drop-tableLangage du code : JavaScript (javascript)

Vérifiez que le fichier existe :

ls -lh ~/backups/migration-wordpress/Langage du code : JavaScript (javascript)

WP-CLI utilise les identifiants de wp-config.php pour exporter la base. Cela évite de retaper les accès MySQL à la main.

Ne placez pas vos exports SQL dans un dossier public du site. Un dump SQL accessible depuis le web, c’est moins une sauvegarde qu’un cadeau aux robots.

Étape 4 : transférer les fichiers avec rsync

Depuis l’ancien serveur, synchronisez les fichiers vers le nouveau serveur :

rsync -azP \
  --exclude='wp-content/cache/' \
  --exclude='wp-content/uploads/cache/' \
  --exclude='wp-content/upgrade/' \
  --exclude='.git/' \
  /home/www/example.com/public_html/ \
  deploy@new-server:/home/www/example.com/public_html/Langage du code : JavaScript (javascript)

Le slash final après public_html/ est important : il signifie que l’on copie le contenu du dossier, pas le dossier lui-même.

Pour un premier passage sur un gros site, vous pouvez lancer rsync pendant que l’ancien site tourne encore. Ensuite, juste avant la bascule, relancez une synchronisation courte après avoir activé la maintenance.

Pour une simulation sans rien modifier :

rsync -azP --dry-run \
  /home/www/example.com/public_html/ \
  deploy@new-server:/home/www/example.com/public_html/Langage du code : JavaScript (javascript)

Étape 5 : transférer le dump SQL

Transférez le dump vers le nouveau serveur :

rsync -azP ~/backups/migration-wordpress/example-2026-06-03-120000.sql \
  deploy@new-server:~/restore/Langage du code : JavaScript (javascript)

Sur le nouveau serveur, créez le dossier si nécessaire :

mkdir -p ~/restore

Adaptez évidemment le nom du fichier SQL à votre export réel.

Étape 6 : créer la base sur le nouveau serveur

Sur le nouveau serveur, créez une base et un utilisateur MySQL/MariaDB dédiés.

sudo mysql

Exemple :

CREATE DATABASE example_wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;
CREATE USER 'example_user'@'localhost' IDENTIFIED BY 'mot_de_passe_long_et_unique';
GRANT ALL PRIVILEGES ON example_wordpress.* TO 'example_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;Langage du code : PHP (php)

Utilisez un vrai mot de passe, pas passw0rd. Ce mot de passe a déjà assez souffert dans les tutoriels du monde entier.

Étape 7 : adapter wp-config.php

Sur le nouveau serveur, ouvrez wp-config.php :

nano /home/www/example.com/public_html/wp-config.php

Modifiez les constantes de base de données :

define( 'DB_NAME', 'example_wordpress' );
define( 'DB_USER', 'example_user' );
define( 'DB_PASSWORD', 'mot_de_passe_long_et_unique' );
define( 'DB_HOST', 'localhost' );Langage du code : JavaScript (javascript)

Conservez le préfixe de table existant :

$table_prefix = 'wp_';Langage du code : PHP (php)

Si l’ancien site utilisait un préfixe personnalisé, gardez-le. Ne changez pas le préfixe pendant une migration, sauf si vous savez exactement pourquoi vous le faites.

Vérifiez ensuite que WP-CLI charge bien la configuration :

cd /home/www/example.com/public_html
wp config get DB_NAME
wp config get DB_USER
wp db checkLangage du code : JavaScript (javascript)

Étape 8 : importer la base avec WP-CLI

Depuis la racine WordPress du nouveau serveur :

cd /home/www/example.com/public_html

Importez le dump SQL :

wp db import ~/restore/example-2026-06-03-120000.sqlLangage du code : JavaScript (javascript)

Vérifiez ensuite que WordPress lit bien la base importée :

wp option get home
wp option get siteurl
wp core version
wp plugin list --status=activeLangage du code : JavaScript (javascript)

Si wp db import échoue, vérifiez le nom de base, l’utilisateur, les privilèges, le chemin du fichier SQL et la taille maximale autorisée par le serveur MySQL.

Étape 9 : remplacer les URLs si le domaine change

Si vous migrez vers le même domaine, par exemple https://www.example.com vers le même https://www.example.com, vous n’avez généralement pas besoin de remplacer les URLs.

Si vous migrez vers un nouveau domaine, un sous-domaine de staging ou un changement HTTP vers HTTPS, utilisez wp search-replace.

Testez d’abord à blanc :

wp search-replace 'https://old.example.com' 'https://www.example.com' --all-tables --dry-runLangage du code : JavaScript (javascript)

Si le résultat est cohérent, appliquez :

wp search-replace 'https://old.example.com' 'https://www.example.com' --all-tablesLangage du code : JavaScript (javascript)

WP-CLI gère les données PHP sérialisées. C’est précisément pour cela qu’il faut éviter les requêtes SQL directes avec REPLACE() sur une base WordPress. Elles peuvent casser les options, widgets, builders et réglages de plugins.

Si vous voulez éviter de modifier certaines colonnes comme les GUID, vous pouvez utiliser :

wp search-replace 'https://old.example.com' 'https://www.example.com' \
  --all-tables \
  --skip-columns=guidLangage du code : JavaScript (javascript)

Pour un multisite, ajoutez --network lorsque c’est pertinent :

wp search-replace 'https://old.example.com' 'https://www.example.com' --network --dry-runLangage du code : JavaScript (javascript)

Étape 10 : corriger les permissions

Les permissions dépendent de votre stack, de votre utilisateur PHP-FPM et de votre modèle de déploiement. Une base raisonnable consiste à donner les fichiers à l’utilisateur qui doit les gérer, puis à éviter les permissions trop larges.

Exemple avec un utilisateur www-data :

sudo chown -R www-data:www-data /home/www/example.com/public_html

sudo find /home/www/example.com/public_html -type d -exec chmod 750 {} \;
sudo find /home/www/example.com/public_html -type f -exec chmod 640 {} \;

Adaptez à votre serveur. Sur certaines stacks, l’utilisateur SSH propriétaire des fichiers n’est pas le même que l’utilisateur PHP-FPM. Le bon modèle dépend de votre politique de déploiement.

Pour approfondir ce point, consultez les bonnes permissions WordPress avec chown et chmod.

Étape 11 : tester le site avant de modifier le DNS

Avant de basculer le DNS, testez le nouveau serveur en forçant la résolution locale avec votre fichier hosts.

Sur macOS ou Linux :

sudo nano /etc/hosts

Ajoutez temporairement :

203.0.113.10 www.example.com example.comLangage du code : CSS (css)

Remplacez 203.0.113.10 par l’IP du nouveau serveur.

Ensuite, testez :

• la page d’accueil ;
• l’administration WordPress ;
• les permaliens ;
• les médias ;
• les formulaires ;
• les emails sortants ;
• le checkout WooCommerce ;
• les tâches cron ;
• les logs PHP, Nginx ou Apache.

Vérifiez aussi avec WP-CLI :

wp option get home
wp option get siteurl
wp rewrite flush
wp cache flush
wp cron event list | headLangage du code : JavaScript (javascript)

Étape 12 : générer ou vérifier le certificat HTTPS

Si vous utilisez Let’s Encrypt, le certificat peut être généré avant ou après la bascule DNS selon votre méthode de validation.

Avec une validation HTTP classique, le domaine doit pointer vers le nouveau serveur. Avec une validation DNS, vous pouvez préparer le certificat avant la bascule.

Après activation HTTPS, testez :

curl -I https://www.example.comLangage du code : JavaScript (javascript)

Vérifiez aussi les URLs WordPress :

wp option get home
wp option get siteurlLangage du code : JavaScript (javascript)

Si le site était auparavant en HTTP, faites le remplacement avec WP-CLI :

wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tables --dry-run
wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tablesLangage du code : JavaScript (javascript)

Étape 13 : basculer le DNS

Quand le nouveau serveur est validé, modifiez les enregistrements DNS du domaine :

• A pour l’IPv4 ;
• AAAA pour l’IPv6 si elle est configurée ;
• CNAME si vous utilisez un alias ;
• éventuellement les enregistrements mail si le serveur mail change aussi.

Avant la migration, vous pouvez réduire le TTL DNS à 300 secondes pour accélérer la bascule. Faites-le quelques heures avant, pas trente secondes avant en mode “ça va passer”. DNS n’est pas rancunier, mais il a de la mémoire.

Après changement DNS, vérifiez :

dig A www.example.com +short
dig AAAA www.example.com +short
curl -I https://www.example.comLangage du code : JavaScript (javascript)

Étape 14 : relancer une dernière synchronisation

Si l’ancien site est resté actif pendant les tests, lancez une dernière synchronisation des fichiers juste avant ou juste après la bascule, selon votre fenêtre de maintenance.

rsync -azP \
  --exclude='wp-content/cache/' \
  --exclude='wp-content/uploads/cache/' \
  --exclude='wp-content/upgrade/' \
  /home/www/example.com/public_html/ \
  deploy@new-server:/home/www/example.com/public_html/Langage du code : JavaScript (javascript)

Pour WooCommerce ou un site à écritures fréquentes, faites aussi un dernier export/import SQL pendant la maintenance. Sinon, vous risquez de perdre une commande, un compte client ou un formulaire envoyé pendant la fenêtre de transition.

Étape 15 : vérifier les emails sortants

Après migration, testez les emails WordPress. C’est un oubli très fréquent.

Vérifiez au minimum :

• réinitialisation de mot de passe ;
• formulaire de contact ;
• emails WooCommerce ;
• notifications admin ;
• SMTP applicatif ;
• SPF, DKIM et DMARC si l’envoi change de serveur.

Si le serveur mail change, relisez configurer SPF, DKIM et DMARC avec Postfix et OpenDKIM.

Étape 16 : vérifier cron et tâches planifiées

WordPress dépend souvent de tâches planifiées : publications différées, emails, automatisations, synchronisations, tâches WooCommerce, nettoyages et exports.

Listez les tâches cron WordPress :

wp cron event listLangage du code : PHP (php)

Si vous utilisez un vrai cron système pour déclencher WordPress, vérifiez qu’il pointe vers le nouveau chemin :

crontab -l

Pour WooCommerce, vérifiez Action Scheduler si disponible :

wp action-scheduler action list --status=pending --per-page=20Langage du code : PHP (php)

Si la commande n’existe pas, ce n’est pas forcément un problème. Elle dépend de WooCommerce ou du package Action Scheduler.

Étape 17 : purger les caches

Après migration, purgez toutes les couches de cache concernées :

• cache objet WordPress ;
• Redis ou Memcached ;
• cache page ;
• OPcache PHP ;
• cache Nginx ou Apache ;
• cache CDN comme Cloudflare ;
• cache plugin comme WP Rocket ou LiteSpeed Cache.

Commencez par WordPress :

wp cache flush

Si vous utilisez PHP-FPM, vous pouvez recharger le service pour vider OPcache selon votre configuration :

sudo systemctl reload php8.3-fpmLangage du code : CSS (css)

Adaptez la version PHP à votre serveur.

Étape 18 : contrôler les logs

Après la bascule, gardez un œil sur les logs :

sudo journalctl -u nginx -u php8.3-fpm -fLangage du code : CSS (css)

Avec Apache :

sudo journalctl -u apache2 -f

Selon votre configuration, regardez aussi les logs de site :

tail -f /var/log/nginx/example.com.error.log
tail -f /var/log/nginx/example.com.access.logLangage du code : JavaScript (javascript)

Côté WordPress, vous pouvez temporairement activer le debug log si nécessaire, puis le couper après diagnostic. Ne laissez pas un debug verbeux tourner indéfiniment en production.

Script Bash de migration assistée

Voici un script côté ancien serveur pour préparer l’export SQL et lancer un transfert rsync. Il ne fait pas tout à votre place, mais il évite les oublis classiques.

#!/usr/bin/env bash

set -euo pipefail

WP_ROOT="${WP_ROOT:-$(pwd)}"
REMOTE_USER="${REMOTE_USER:-deploy}"
REMOTE_HOST="${REMOTE_HOST:-new-server}"
REMOTE_PATH="${REMOTE_PATH:-/home/www/example.com/public_html}"
BACKUP_DIR="${BACKUP_DIR:-$HOME/backups/migration-wordpress}"
DATE="$(date +%F-%H%M%S)"
SQL_FILE="${BACKUP_DIR}/wordpress-${DATE}.sql"

cd "${WP_ROOT}"
mkdir -p "${BACKUP_DIR}"

if ! wp core is-installed >/dev/null 2>&1; then
  echo "WordPress n'est pas détecté dans ${WP_ROOT}" >&2
  exit 1
fi

echo "Site : $(wp option get home)"
echo "Racine : ${WP_ROOT}"
echo "Export SQL : ${SQL_FILE}"
echo

wp db export "${SQL_FILE}" --add-drop-table

echo
echo "Synchronisation des fichiers vers ${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_PATH}"
rsync -azP \
  --exclude='wp-content/cache/' \
  --exclude='wp-content/uploads/cache/' \
  --exclude='wp-content/upgrade/' \
  --exclude='.git/' \
  "${WP_ROOT}/" \
  "${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_PATH}/"

echo
echo "Transfert du dump SQL..."
ssh "${REMOTE_USER}@${REMOTE_HOST}" "mkdir -p ~/restore"
rsync -azP "${SQL_FILE}" "${REMOTE_USER}@${REMOTE_HOST}:~/restore/"

echo
echo "Terminé."
echo "Sur le nouveau serveur, importez : ~/restore/$(basename "${SQL_FILE}")"Langage du code : PHP (php)

Utilisation :

chmod +x prepare-wordpress-migration.sh

WP_ROOT=/home/www/example.com/public_html \
REMOTE_USER=deploy \
REMOTE_HOST=203.0.113.10 \
REMOTE_PATH=/home/www/example.com/public_html \
./prepare-wordpress-migration.shLangage du code : JavaScript (javascript)

Gardez le script lisible et volontairement limité. Une migration trop automatisée sans garde-fous peut devenir une machine très rapide à propager une erreur.

Plan de rollback

Avant la bascule DNS, gardez l’ancien serveur intact. C’est votre rollback le plus simple.

En cas de problème majeur après bascule :

• repointez le DNS vers l’ancien serveur ;
• désactivez la maintenance sur l’ancien site ;
• conservez les logs du nouveau serveur ;
• analysez l’erreur hors pression ;
• relancez une migration corrigée.

Si le problème vient seulement de la base importée sur le nouveau serveur, vous pouvez réimporter le dump :

wp db import ~/restore/example-2026-06-03-120000.sql
wp cache flushLangage du code : JavaScript (javascript)

Ne supprimez pas l’ancien serveur le jour de la migration. Laissez-le disponible au moins quelques jours, surtout pour une boutique, un site membre ou un site à fort trafic.

Erreurs fréquentes à éviter

Utiliser –allow-root partout

WP-CLI peut fonctionner en root avec --allow-root, mais ce n’est pas une bonne habitude. Utilisez plutôt l’utilisateur du site ou un utilisateur de déploiement correctement configuré.

Changer le préfixe de tables pendant la migration

Gardez le préfixe existant. Une migration est déjà assez riche en variables. Ne rajoutez pas une modification structurelle inutile au milieu.

Faire un search-replace SQL brut

Évitez les UPDATE ... REPLACE() sur WordPress. Les données sérialisées peuvent casser. Utilisez wp search-replace.

Oublier wp-content/uploads

Les fichiers médias sont souvent la partie la plus lourde du site. Vérifiez leur transfert avec rsync et testez les images dans la bibliothèque WordPress.

Oublier les emails

Un site migré qui n’envoie plus d’emails peut sembler fonctionnel pendant plusieurs heures. Puis arrivent les formulaires perdus, les commandes sans notification et les clients joyeux comme des cactus.

Supprimer l’ancien serveur trop vite

Gardez l’ancien serveur en lecture seule ou en maintenance quelques jours. C’est votre assurance rollback.

Checklist post-migration

• Le DNS pointe vers le nouveau serveur.
• Le certificat HTTPS est valide.
• home et siteurl sont corrects.
• Les permaliens fonctionnent.
• Les médias s’affichent.
• L’administration WordPress fonctionne.
• Les formulaires envoient bien les emails.
• WooCommerce, checkout et webhooks fonctionnent.
• Les tâches cron sont actives.
• Les caches ont été purgés.
• Les logs ne montrent pas d’erreurs critiques.
• L’ancien serveur est conservé pour rollback.

Pour aller plus loin avec WP-CLI et l’administration serveur

Si vous migrez WordPress vers un nouveau serveur, ces guides complètent bien la préparation, la maintenance, les permissions et les vérifications post-migration.

• Sauvegarder, archiver et installer des extensions WordPress par lots avec WP-CLI
• Mettre à jour WordPress en SSH avec WP-CLI
• WordPress : bonnes permissions fichiers avec chown et chmod
• Identifier les options de base de données liées à un plugin WordPress
• Installer Nginx, PHP et MariaDB sur Debian

FAQ

WP-CLI suffit-il pour migrer WordPress ?

WP-CLI couvre la base, les URLs, les caches, les permaliens et beaucoup de vérifications. Pour les fichiers, utilisez plutôt rsync. Les deux outils se complètent très bien.

Faut-il installer WordPress neuf sur le nouveau serveur ?

Pas forcément. Pour une migration complète, vous copiez généralement les fichiers existants, adaptez wp-config.php, puis importez la base. Installer WordPress neuf est surtout utile pour créer une installation de départ ou un staging particulier.

Pourquoi utiliser wp search-replace au lieu d’une requête SQL ?

Parce que WordPress stocke beaucoup de données sérialisées. wp search-replace les gère proprement, alors qu’un remplacement SQL brut peut casser des options, widgets ou réglages de plugins.

Puis-je migrer WooCommerce sans maintenance ?

Ce n’est pas recommandé. Une boutique reçoit des commandes, sessions, webhooks et paiements. Prévoyez une fenêtre courte de maintenance pour le dernier export SQL et la bascule.

Comment tester le nouveau serveur avant DNS ?

Utilisez votre fichier /etc/hosts pour faire pointer le domaine vers la nouvelle IP uniquement sur votre machine. Vous pouvez alors tester le site sans modifier le DNS public.

Combien de temps garder l’ancien serveur ?

Gardez-le au moins quelques jours après la migration. Pour un site critique ou WooCommerce, gardez-le plus longtemps, en maintenance ou en lecture seule, jusqu’à validation complète.

Conclusion

Migrer WordPress vers un nouveau serveur avec WP-CLI donne un contrôle précis sur les étapes sensibles : export SQL, import, remplacement d’URLs, cache, permaliens et vérifications. Avec rsync, vous gérez aussi les fichiers proprement, sans archive géante à manipuler à chaque essai.

La réussite d’une migration ne tient pas à une commande magique. Elle tient à la préparation, aux sauvegardes, aux tests avant DNS, au dernier export au bon moment et aux vérifications post-bascule.

La ligne de commande fait gagner beaucoup de temps. Mais c’est la méthode autour qui évite de transformer une migration serveur en chasse au fantôme dans les logs.

Sources

• WP-CLI : wp search-replace
• WP-CLI : commandes wp db
• WP-CLI : wp rewrite flush
• WP-CLI : wp cache flush

Report a typo