Migrer WordPress vers un nouveau serveur, sans interruption

Une migration WordPress échoue rarement à cause d'une seule commande. Elle échoue à cause de l'ordre des opérations. Si vous basculez le DNS avant de copier, vous créez à coup sûr une fenêtre pendant laquelle les visiteurs voient soit une page d'erreur, soit une installation à moitié remplie. En procédant dans l'autre sens, vous terminez tranquillement le nouveau serveur, vous le testez sous le vrai nom de domaine et vous ne modifiez l'enregistrement DNS qu'au moment où tout fonctionne de façon vérifiable.

Cet article décrit précisément cet ordre, ainsi que les endroits où ça casse en pratique : les données sérialisées dans la base, les collations lors du passage de MySQL à MariaDB, les certificats sans enregistrement DNS pointant vers le bon serveur, et le chemin de retour si quelque chose a malgré tout été oublié.

Le déroulé qui ne produit aucune interruption

L'ancien site reste en ligne jusqu'au dernier moment. Rien n'est éteint, rien n'est supprimé. Le nouveau serveur tourne en parallèle, il est testé, et il ne prend le relais qu'une fois l'enregistrement DNS basculé.

1. Abaisser le TTL des enregistrements A et AAAA à 300 secondes, au moins 24 à 48 heures à l'avance.
2. Mettre en place le nouveau serveur : serveur web, PHP, base de données, utilisateurs, répertoires.
3. Copier les fichiers, copier la base de données.
4. Émettre le certificat pour le domaine, bien que le DNS pointe encore vers l'ancien serveur.
5. Adapter le fichier hosts sur votre propre machine et parcourir le site sous le vrai nom de domaine.
6. Juste avant la bascule, lancer une synchronisation différentielle pour récupérer les dernières modifications.
7. Basculer le DNS. Laisser l'ancien serveur tourner encore plusieurs jours.

Le seul point où une fenêtre d'indisponibilité peut théoriquement apparaître est l'étape 6. Sa durée dépend entièrement de l'étape 1.

Abaisser le TTL avant toute autre chose

Le TTL indique aux résolveurs du monde entier combien de temps ils ont le droit de mettre une réponse en cache. S'il est à 86400, un résolveur peut encore servir votre ancienne IP pendant 24 heures après votre bascule. Et voici ce que l'on oublie volontiers : un TTL abaissé ne prend effet qu'une fois l'ancien TTL expiré. Si vous passez de 86400 à 300, il peut s'écouler une journée entière avant que tous les résolveurs connaissent la valeur courte.

C'est donc la première manipulation, pas la dernière. dig n'est livré de base sur aucune distribution alors qu'il sert en permanence dans ce guide. Installez-le donc en premier :

apt install -y bind9-dnsutils

Sur Debian 11, Ubuntu 22.04 et Ubuntu 24.04, le paquet s'appelle encore dnsutils. À partir de Debian 12, dnsutils n'est plus qu'un paquet de transition qui renvoie vers bind9-dnsutils, et sur Debian 13 c'est même un paquet purement virtuel, sans version propre. Les deux fonctionnent, car apt résout lui-même l'unique fournisseur, mais bind9-dnsutils est le nom qui restera. Vérifiez ensuite la valeur actuelle :

dig +noall +answer example.com A
dig +noall +answer example.com SOA

Le nombre dans la deuxième colonne de la réponse A correspond au TTL restant. Interrogez directement le serveur faisant autorité, sinon vous ne voyez que la valeur résiduelle issue du cache de votre résolveur :

dig @a.ns14.net example.com A +noall +answer

Après la migration, remontez le TTL à 3600 ou plus. Des TTL durablement courts génèrent une charge inutile et allongent les pannes de votre fournisseur DNS.

Équiper correctement le nouveau serveur

C'est ici que naissent la plupart des mauvaises surprises, parce que la distribution du nouveau serveur ne livre pas les mêmes versions que l'ancienne. Toutes les commandes de paquets de ce guide partent de Debian ou d'Ubuntu ; sur AlmaLinux, Rocky Linux et Oracle Linux il n'y a pas d'apt et les noms de paquets diffèrent. En juillet 2026, la situation se présente ainsi :

Deux conséquences en découlent. Premièrement : sur Debian, vous n'obtiendrez pas de mysql-server, c'est toujours MariaDB qui tourne. Si l'ancien site fonctionnait sous MySQL 8, la migration vers Debian est en même temps un changement de base de données, avec un piège très concret décrit plus bas. Deuxièmement : le saut de PHP 8.1 à 8.4 ne se fait pas tout seul. Les thèmes et extensions anciens réagissent aux fonctions supprimées par un Fatal error: Uncaught Error: Call to undefined function ou par une page blanche. Si l'ancienne installation tournait sous PHP 8.1 et que vous ne voulez pas coupler la migration à une montée de version PHP, Ubuntu 22.04 ou une version de PHP issue d'un dépôt tiers est le choix le plus tranquille. Ce qui manque volontairement dans le tableau, c'est Debian 11 : php-cli y livre encore PHP 7.4.33, donc une version sans suivi de sécurité et en dessous de ce que WordPress recommande. Debian 11 est ainsi exclu comme cible de migration, sauf si vous intégrez au préalable le dépôt Sury.

Les paquets de base pour une installation typique avec nginx et PHP-FPM :

apt update
apt install -y nginx php-fpm php-mysql php-xml php-curl php-mbstring php-zip php-gd php-intl
apt install -y mariadb-server mariadb-client rsync curl

Les détails sur le serveur web se trouvent dans le guide nginx, la sécurisation de base de la base de données dans Sécuriser MariaDB et MySQL. Si le serveur est tout neuf, un coup d'œil préalable à la checklist pour les nouveaux serveurs root vaut le détour.

Créez la base et l'utilisateur avec le même jeu de caractères que sur la source :

CREATE DATABASE wp_nouveau CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_nouveau'@'localhost' IDENTIFIED BY 'un-mot-de-passe-long';
GRANT ALL PRIVILEGES ON wp_nouveau.* TO 'wp_nouveau'@'localhost';
FLUSH PRIVILEGES;

Transférer les fichiers sans casser les permissions

La copie se fait directement de serveur à serveur, pas en passant par votre connexion domestique. Le plus simple est rsync depuis l'ancien vers le nouveau serveur, avec une clé SSH plutôt qu'un mot de passe :

rsync -az --delete --exclude 'wp-content/cache/' --exclude 'wp-content/uploads/backup*' \
  -e 'ssh -p 22' /var/www/html/ root@nouvelle.ip:/var/www/html/

La première passe a le droit de durer. C'est exactement pour cela qu'on la lance plusieurs jours avant la bascule, puis qu'on relance juste avant la même commande, qui ne transfère alors plus que les différences.

Après la copie, il faut remettre d'aplomb le propriétaire et les permissions, car les UID diffèrent d'un système à l'autre et rsync transfère des nombres, pas des noms :

chown -R www-data:www-data /var/www/html
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 640 /var/www/html/wp-config.php

Deux fichiers dégagent avant le premier démarrage, s'ils existent : wp-content/object-cache.php et wp-content/advanced-cache.php. Ce sont des drop-ins d'extensions de cache qui pointent vers un socket Redis ou Memcached absent du nouveau serveur. Le résultat serait une page blanche, sans message exploitable.

Transférer la base de données et le piège des collations

Le dump se fait avec WP-CLI ou de façon classique. WP-CLI a l'avantage de reprendre le jeu de caractères et le préfixe depuis wp-config.php :

cd /var/www/html
wp db export /root/wp-dump.sql --add-drop-table

Sans WP-CLI, sur un système MariaDB récent, l'outil s'appelle mariadb-dump. L'ancien nom mysqldump n'est plus qu'un lien symbolique obsolète depuis MariaDB 11.0 et vous accueille avec Deprecated program name. It will be removed in a future release :

mariadb-dump --single-transaction --default-character-set=utf8mb4 wp_ancien > /root/wp-dump.sql

Voici maintenant l'endroit où une migration d'Ubuntu avec MySQL 8 vers Debian avec MariaDB se casse régulièrement la figure. MySQL 8 utilise par défaut la collation utf8mb4_0900_ai_ci, qui n'existe tout simplement pas dans MariaDB. L'import s'interrompt avec :

ERROR 1273 (HY000) at line 42: Unknown collation: 'utf8mb4_0900_ai_ci'

Réparation avant l'import, directement dans le dump :

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g; s/utf8mb4_0900_as_cs/utf8mb4_unicode_ci/g' /root/wp-dump.sql
grep -c utf8mb4_unicode_ci /root/wp-dump.sql

Puis importez :

mariadb --default-character-set=utf8mb4 wp_nouveau < /root/wp-dump.sql

Si après l'import vous lisez partout création au lieu de création, le jeu de caractères s'est perdu au dump ou à l'import. Cela ne se répare pas avec un rechercher/remplacer, mais en refaisant le dump et l'import avec --default-character-set=utf8mb4. C'est précisément pour cette raison que l'ancienne base est encore intacte à ce stade.

Adaptez ensuite les identifiants dans wp-config.php sur le nouveau serveur : DB_NAME, DB_USER, DB_PASSWORD, et surtout DB_HOST si l'ancienne installation pointait vers un serveur de base de données distant. Si l'ancienne adresse y reste, vous verrez Error establishing a database connection alors que tout tourne correctement en local. Si la connexion coince malgré des identifiants corrects, consultez Résoudre Access denied for user.

Remplacer le domaine, et pourquoi un REPLACE en SQL démolit le site

D'abord la bonne nouvelle : si seul le serveur change et que le domaine reste identique, vous n'avez strictement rien à remplacer dans la base. C'est justement l'une des raisons pour lesquelles le test via le fichier hosts est supérieur au test via un domaine provisoire. Le remplacement ne devient nécessaire que si le domaine change réellement, si vous couplez la migration au passage de http à https, ou si vous travaillez malgré tout avec un domaine de test et devez faire le remplacement inverse ensuite.

Et voici pourquoi on ne fait jamais cela avec une simple commande SQL. WordPress stocke les options, les réglages de widgets et les configurations de thèmes sous forme de tableaux PHP sérialisés. Une URL n'y figure pas nue, mais précédée de sa longueur en octets :

s:19:"https://example.com"

Si vous remplacez example.com par nouveau-domaine.fr via UPDATE ... REPLACE(), la chaîne s'allonge mais le nombre 19 reste tel quel. PHP ne peut alors plus décoder le tableau, unserialize() renvoie false et le réglage concerné est perdu. Symptômes typiques : widgets disparus, options du thème réinitialisées, entrées de menu vides, et dans les journaux Notice: unserialize(): Error at offset.

WP-CLI règle cela correctement, parce qu'il désérialise les données, effectue le remplacement et les réécrit avec une longueur corrigée. Toujours d'abord avec --dry-run :

wp search-replace 'https://ancien-domaine.fr' 'https://nouveau-domaine.fr' --all-tables --precise --dry-run --report-changed-only

Ce que font les différentes options : --all-tables touche aussi les tables qui ne suivent pas le préfixe WordPress, par exemple celles des extensions de boutique ou de formulaires. --precise force le traitement en PHP au lieu de SQL, c'est plus lent, mais les données sérialisées sont traitées de façon fiable. --report-changed-only réduit la sortie aux tables où il y a de vraies correspondances.

Si l'aperçu paraît plausible, relancez la même commande sans --dry-run. Vient ensuite la passe que presque tous les guides oublient : les page builders comme Elementor stockent leurs contenus en JSON dans la base, et les barres obliques y sont échappées. Un remplacement de https://ancien-domaine.fr ne trouve tout simplement pas https:\/\/ancien-domaine.fr. D'où une deuxième passe :

wp search-replace 'https:\/\/ancien-domaine.fr' 'https:\/\/nouveau-domaine.fr' --all-tables --precise --report-changed-only

Avec Elementor, il faut ensuite régénérer les fichiers CSS dans l'administration, sous Outils, sinon les feuilles de style générées continuent de pointer vers l'ancien domaine.

Deux choses que search-replace n'atteint pas : les constantes dans wp-config.php et le multisite. Si vous y trouvez define('WP_HOME', 'https://ancien-domaine.fr');, cela écrase toute valeur en base et vous cherchez pendant des heures au mauvais endroit. En multisite, il vous faut en plus --network et vous devez adapter les domaines dans wp_blogs et wp_site.

Et un avertissement sur le préfixe des tables : ne le changez pas pendant la migration. Le préfixe se retrouve aussi dans le nom d'option wp_user_roles et dans les métadonnées utilisateur wp_capabilities et wp_user_level. Si vous renommez uniquement les tables, vous pourrez certes encore vous connecter, mais vous obtiendrez ensuite Sorry, you are not allowed to access this page. et vous n'aurez plus d'administrateur.

Émettre le certificat avant que le DNS ne pointe

Il y a ici un problème de la poule et de l'œuf. La validation HTTP habituelle de Let's Encrypt exige que le nom de domaine pointe déjà vers le serveur à valider. Or ce n'est pas encore le cas à ce stade, puisqu'il doit toujours servir l'ancien site. Si vous lancez quand même certbot --nginx, vous obtenez :

Certbot failed to authenticate some domains (authenticator: nginx).
Invalid response from http://example.com/.well-known/acme-challenge/...: 404

La solution propre est la validation DNS. Elle vérifie un enregistrement TXT _acme-challenge.example.com et se moque de savoir où pointe l'enregistrement A :

certbot certonly --manual --preferred-challenges dns -d example.com -d www.example.com

Certbot affiche une valeur que vous déposez comme enregistrement TXT dans votre zone DNS. Avant de confirmer, vérifiez impérativement vous-même que la zone sert déjà cet enregistrement, sinon vous brûlez une tentative :

dig +short TXT _acme-challenge.example.com

Pour les domaines wildcard ou si vous voulez automatiser la chose, la voie passant par l'API DNS est décrite dans l'article sur le certificat wildcard. La variante manuelle ne se renouvelle pas toute seule, alors repassez à la validation HTTP classique après la bascule DNS. À partir de là, elle fonctionne, car le domaine pointe désormais vers le nouveau serveur.

Tester avec le fichier hosts, comme un vrai visiteur

Vient maintenant la partie qui fait la différence entre « ça devrait marcher » et « ça marche ». Vous redirigez uniquement votre propre machine vers le nouveau serveur, pendant que le reste du monde continue de voir l'ancien site.

Sous Linux et macOS, vous éditez /etc/hosts en root, sous Windows C:\Windows\System32\drivers\etc\hosts dans un éditeur lancé en tant qu'administrateur. Ajoutez une ligne avec l'IP du nouveau serveur :

203.0.113.10 example.com www.example.com

Videz ensuite le cache DNS, sinon la modification ne prend pas effet immédiatement :

resolvectl flush-caches

Sous Windows ipconfig /flushdns, sous macOS sudo dscacheutil -flushcache suivi de sudo killall -HUP mDNSResponder. Vérifiez que cela a bien pris :

getent hosts example.com

Un piège qui coûte de nombreuses heures : Firefox, avec le DNS over HTTPS activé, ignore le fichier hosts. Mozilla a explicitement classé cela en « wontfix ». Vous continuez alors de voir l'ancien site et vous croyez le test raté, alors que le nouveau serveur répond correctement depuis longtemps. Désactivez donc la résolution DNS chiffrée dans le navigateur de test, ou mieux : vérifiez indépendamment du navigateur. curl peut surcharger la résolution appel par appel, sans aucun fichier hosts :

curl -sI --resolve example.com:443:203.0.113.10 https://example.com/

Ce que vous devriez parcourir dans cet état : la page d'accueil, au moins deux pages internes, un article avec des images, la connexion sous /wp-login.php, l'administration, un formulaire de contact, et pour une boutique un article test jusqu'à la caisse. Les images méritent une attention particulière, car des téléversements manquants ne sautent pas aux yeux dans l'administration.

Ce que le test par fichier hosts ne couvre explicitement pas : tout ce qui accède au serveur depuis l'extérieur. Les webhooks des prestataires de paiement, les tâches cron externes, les robots des moteurs de recherche et vos envois d'e-mails atterrissent toujours sur l'ancienne cible. Ce n'est pas gênant, il faut simplement le savoir.

La bascule : synchronisation différentielle et DNS

Entre la première copie et la bascule, des commentaires, des commandes ou des articles se sont ajoutés. L'ordre pour une bascule propre :

1. Activer le mode maintenance sur l'ancien serveur, ou au minimum suspendre brièvement les commandes et les commentaires.
2. Resynchroniser les fichiers, cette fois cela prend quelques secondes.
3. Exporter la base à nouveau et l'importer sur le nouveau serveur.
4. Vider les caches : wp cache flush et wp rewrite flush --hard.
5. Contrôler une nouvelle fois avec curl contre la nouvelle IP.
6. Basculer les enregistrements A et AAAA.

N'oubliez pas l'enregistrement AAAA. S'il reste sur l'ancienne adresse IPv6, tous les visiteurs en IPv6 continuent d'atterrir sur l'ancien serveur, pendant que les visiteurs en IPv4 voient le nouveau site. Cela produit exactement le genre de symptôme où deux personnes assises côte à côte voient deux sites différents.

Laissez l'ancien serveur tourner au moins une semaine, sans y toucher. Il est votre chemin de retour et votre archive.

Comment savoir que la migration a réellement abouti

Pas « le site se charge », mais des preuves mesurables :

dig +short A example.com
dig +short AAAA example.com
curl -sI https://example.com/ | head -n 12

Les en-têtes ne doivent contenir aucun 301 vers un ancien domaine ou vers http://. Demandez ensuite à la base quelle adresse WordPress considère lui-même comme correcte :

wp option get siteurl
wp option get home

Un test fiable pour repérer les restes oubliés est une recherche à blanc. Si elle annonce zéro remplacement, l'ancienne adresse n'est effectivement plus enregistrée nulle part :

wp search-replace 'ancien-domaine.fr' 'ancien-domaine.fr' --all-tables --dry-run --report-changed-only

Contrôlez également le certificat, y compris sa durée de validité et les noms couverts :

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

Et enfin le journal d'erreurs du serveur web, pendant que vous naviguez cinq minutes sur le site. Si rien de nouveau n'y apparaît, c'est terminé. Si quelque chose coince malgré tout, Résoudre l'erreur 502 Bad Gateway est le point de chute le plus fréquent, en général parce que le socket PHP-FPM dans le bloc nginx porte encore le chemin de l'ancienne version de PHP.

Si ça tourne mal : le chemin de retour

Le retour arrière tient en une seule manipulation, et c'est pour cela que l'étape 1 était si importante : remettre les enregistrements A et AAAA sur l'ancienne IP. Avec un TTL de 300 secondes, la plupart des visiteurs se retrouvent en moins de cinq minutes sur l'ancien serveur, qui a continué de tourner sans modification.

Il existe exactement un cas où ce n'est pas propre : lorsque des données sont déjà apparues sur le nouveau serveur et n'existent pas sur l'ancien. Nouvelles commandes, commentaires, inscriptions. Après un rollback, ces données ne subsistent que dans le nouveau système. C'est pourquoi on décide dans les premières minutes ou pas du tout. Et c'est aussi la raison d'être du mode maintenance pendant la bascule : il réduit la fenêtre pendant laquelle les deux jeux de données peuvent diverger.

Si vous devez malgré tout revenir en arrière plus tard, exportez depuis le nouveau serveur uniquement les tables concernées et injectez-les sur l'ancien, plutôt que de repousser la base complète. Un simple rollback à partir d'une ancienne sauvegarde complète efface tout ce qui s'est passé entre-temps.

Les messages d'erreur, au mot près

Error establishing a database connection
Les identifiants ou DB_HOST dans wp-config.php ne correspondent pas au nouveau serveur. Souvent, c'est encore l'IP d'un serveur de base de données externe qui y figure au lieu de localhost.

ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci'
Un dump issu de MySQL 8 est importé dans MariaDB. Passez la collation du dump à utf8mb4_unicode_ci avec sed.

Error: This does not seem to be a WordPress installation.
WP-CLI a été lancé dans le mauvais répertoire, ou les fichiers ne sont pas là où vous le pensez. Travaillez avec --path=/var/www/html.

ERR_TOO_MANY_REDIRECTS
Presque toujours une contradiction entre siteurl en base, une constante dans wp-config.php et la redirection dans le serveur web. Cela concerne aussi les installations derrière un proxy qui ne perçoivent pas l'état HTTPS et renvoient donc sans fin de http vers https et retour.

La page d'accueil se charge, toutes les pages internes renvoient 404
Le grand classique du passage d'Apache à nginx. Le fichier .htaccess avec les règles de permaliens est ignoré par nginx ; il y faut try_files $uri $uri/ /index.php?$args; dans le bloc location.

Le fichier téléversé dépasse la directive upload_max_filesize dans le fichier php.ini.
La configuration PHP n'a pas été migrée avec le reste. Réglez upload_max_filesize, post_max_size et memory_limit sur les valeurs de l'ancien serveur.

Page blanche, aucune entrée dans le journal
Le plus souvent un drop-in qui pointe dans le vide : wp-content/object-cache.php ou advanced-cache.php. Renommez-le et rechargez.

Une migration menée ainsi ne comporte aucune fenêtre sans site web. Le seul moment perceptible est le changement DNS, et vous en avez vous-même fixé la durée deux jours plus tôt.