Migrer WordPress vers un nouvel hébergeur sans downtime (checklist + plan de bascule)
Changer d’hébergeur WordPress, c’est souvent le moment où tout peut casser : downtime, pertes de commandes, formulaires qui n’arrivent plus, ou (pire) SEO qui dévisse.
L’objectif ici est simple : zéro coupure visible (ou, à défaut, une fenêtre de gel ultra-courte et maîtrisée). Pour y arriver, on applique un plan DevOps très classique : staging fidèle + synchronisation + bascule DNS + monitoring + rollback.
TL;DR (la checklist en 12 points)
- Baisser le TTL DNS 24–48h avant (ex: 300s).
- Monter un staging/cible paritaire (mêmes versions PHP/DB + extensions).
- Mettre le staging en noindex + protection (HTTP basic / IP allowlist).
- Faire une sauvegarde complèvous (fichiers + DB) et tester une restauration.
- Faire une sync initiale (fichiers + DB).
- Tester la cible via /etc/hosts (sans toucher au DNS public).
- Préparer le plan de rollback (remettre l’IP/DNS, restaurer snapshot).
- Définir une fenêtre de bascule (trafic bas) + informer les parties prenantes.
- Activer un gel contenu (commentaires, formulaires, commandes) juste avant la bascule.
- Faire une sync delta (uploads + DB) après le gel.
- Basculer le DNS / IP, purger caches, vérifier HTTPS.
- Monitorer 2–48h (4xx/5xx, perf, Search Console, logs).
Schéma (pour visualiser le flux)
Même si vous changes d’hébergeur, l’idée reste la même : vous montes la nouvelle cible en miroir, vous testes, puis vous bascules le trafic.
1) Préparer une migration “zéro downtime” (les prérequis)
Baisser le TTL DNS (indispensable)
- Fais-le 24 à 48h avant la bascule.
- Objectif : réduire le temps de propagation au moment du switch (ex: TTL 300s).
Monter un staging/cible paritaire
- Même PHP (ou plus récent mais testé)
- Même MySQL/MariaDB
- Même extensions PHP (intl, mbstring, imagick, etc.)
- Même règles de rewrite (Nginx/Apache)
Sauvegardes + rollback
- Snapshot/backup côté source ET côté cible
- Un plan simple : “si KO → on remet l’ancienne IP/DNS + on restaure”
2) Choisir votre méthode : plugin vs manuel
Option A — Plugin (souvent le plus simple)
- Duplicator / All-in-One WP Migration / WPvivid
- Avantage : rapide
- Limite : gros sites (DB/medias lourds) → peut planter
Option B — Migration manuelle (recommandée si gros site / besoin de contrôle)
Deux outils “pro” :
- rsync pour les fichiers
- WP-CLI pour la DB et les remplacements (évite de casser la sérialisation)
3) Migration manuelle (staging + sync + bascule DNS)
Objectif : vous avez une cible prêvous, testable, sans toucher au trafic public.
Étape 1 — Sync initiale des fichiers
Exemple (adapte les chemins) :
rsync -avz --delete \
--exclude='wp-content/cache/' \
--exclude='wp-content/ai1wm-backups/' \
user@SOURCE:/var/www/html/ /var/www/html/
Étape 2 — Export / import DB
# export sur la source
ssh user@SOURCE "cd /var/www/html && wp db export /tmp/prod.sql --add-drop-table"
# copie + import sur la cible
scp user@SOURCE:/tmp/prod.sql /tmp/prod.sql
wp --path=/var/www/html db import /tmp/prod.sql
Étape 3 — Search & replace propre (WP-CLI)
si vous testes avec un domaine de staging (ou une URL temporaire), fais un replace (en évitant la colonne GUID) :
wp --path=/var/www/html search-replace \
'https://www.monsite.fr' 'https://staging.monsite.fr' \
--skip-columns=guid --all-tables
4) Tester la cible sans toucher au DNS (astuce /etc/hosts)
Avant toute bascule, vous voulez naviguer comme un utilisateur… mais en allant sur la nouvelle IP.
Sur votre poste :
- modifie
/etc/hosts(Mac/Linux) ouC:\\Windows\\System32\\drivers\\etc\\hosts - pointe
www.monsite.frvers l’IP de la cible
Vérifie :
- homepage + pages critiques
- formulaire(s)
- login/admin
- checkout (si WooCommerce)
- médias (uploads), permaliens, sitemap
5) Le cutover (la bascule)
Étape 1 — Gel contenu (fenêtre courte)
Juste avant la bascule, bloque ce qui écrit en base :
- commentaires
- formulaires
- commandes (WooCommerce)
L’idée : éviter les divergences entre source et cible lors du dernier delta.
Étape 2 — Sync delta (uploads + DB)
# delta fichiers (ex: uploads)
rsync -avz --delete --inplace \
user@SOURCE:/var/www/html/wp-content/uploads/ \
/var/www/html/wp-content/uploads/
# delta DB
ssh user@SOURCE "cd /var/www/html && wp db export /tmp/prod-final.sql --add-drop-table"
scp user@SOURCE:/tmp/prod-final.sql /tmp/prod-final.sql
wp --path=/var/www/html db import /tmp/prod-final.sql
Étape 3 — Bascule DNS
- change l’IP / enregistrement A (ou nameservers)
- comme le TTL est bas, la propagation est rapide
��tape 4 — Vérifs post-bascule (15–30 min)
- HTTPS OK (pas de mixed content)
- redirections (www/non-www, http→https)
- pages clés
- erreurs 4xx/5xx
- purge des caches (plugin + reverse proxy + CDN)
6) Contrôles SEO (les oublis qui coûtent cher)
Dans les 24–48h :
- Search Console : couverture / erreurs
- sitemap OK
- canoniques OK
- robots.txt OK
- logs serveur : pics de 404/5xx
- performances (TTFB)
Vidéo (FR) — migration WordPress
Déployer WordPress en 1 clic sur adgents.cloud (et éviter les galères de migration)
Si vous voulez passer moins de temps sur l’infra, vous pouvez déployer WordPress sur adgents.cloud :
- Installation / déploiement en 1 clic
- Facturation à l’heure
- Stop/Start (compute non facturé à l’arrêt)
- Backups automatiques (24h par défaut, jusqu’à 1/h)
- Rétention longue (jusqu’à 10 ans)
- Scaling CPU/RAM à la demande
\1Découvrir l’application sur Adgents.cloud
Lancez-vous avec WordPress.
Envie de vous lancer avec WordPress ? Créez votre site web en quelques clics.
WordPress
Le CMS le plus populaire au monde
Essayer gratuitement : lance une instance WordPress, teste vos flux (déploiement, backups, restore) et migre proprement.
Aller plus loin
Essayer sur Adgents.cloud
Envie d’un déploiement propre sans passer des heures sur l’infra ? Sur Adgents.cloud, vous pouvez :
- déployer en 1 clic
- être facturé à l’heure
- utiliser stop/start (compute non facturé à l’arrêt)
- activer des backups automatiques (24h par défaut, jusqu’à 1/h)
- garder une rétention longue (jusqu’à 10 ans)
- ajuster le scaling CPU/RAM à la demande
→ Découvrir wordpress sur Adgents.cloud → Essayer gratuitement
