Vendredi 17 h : bascule DNS vers le nouvel hébergeur. À 17 h 05, le site répond — mais les commandes depuis 16 h ont disparu parce que la base a été exportée à midi et personne n'a resynchronisé. À 17 h 30, les images sont en 404 : les uploads n'étaient pas dans le dernier rsync. L'outil « migration en un clic » avait pourtant l'air impeccable.
Migrer sans coupure n'est pas une question de marque d'hébergeur. C'est une chronologie : quoi copier, quand figer les écritures, quand changer le DNS, comment revenir en arrière.
Phase 0 : inventaire et fenêtre
Listez : base, fichiers, cron, emails, DNS, certificats, webhooks, IP allowlist, object storage. Fixez une fenêtre bas trafic. Prévenez les parties prenantes du maintenance window court pour le dump final — pas de la migration entière.
| Élément | Pré-migration | Jour J |
|---|---|---|
| TTL DNS | 300 s | Baisse déjà propagée |
| Certificat TLS | ACME ou import prêt | Valide sur nouvelle IP |
| Cron / workers | Désactivés sur ancien après bascule | Actifs sur nouveau |
| Emails | MX inchangés ou planifiés | SPF/DKIM vérifiés |
Phase 1 : sync à froid, sans bascule
- Copie bulk fichiers + export base initial sur nouvelle infra.
- Config nginx, PHP,
.env, versions alignées. - Test fonctionnel via hosts file ou URL preview — pas via DNS public.
- Delta sync fichiers jusqu'à J-1.
Ne touchez pas au DNS public tant que les tests échouent.
Phase 2 : jour J — séquence stricte
Ordre recommandé :
- Mettre l'ancien site en lecture seule (maintenance flag ou config app).
- Dump final base + rsync final fichiers.
- Smoke test sur nouvelle infra (login, panier, API critique).
- Basculer DNS A/AAAA ou CNAME vers nouvelle cible.
- Surveiller logs et erreurs 30–60 min.
- Activer cron sur nouveau ; désactiver sur ancien.
- Garder l'ancien environnement intact 48–72 h pour rollback.
Changer le DNS avant le dump final, c'est accepter des données perdues en silence.
Cas WordPress, SaaS et object storage
WordPress — plugins migration pratiques mais vérifiez serialized URLs en base, permalinks, cron wp-cron.php. Recherchez-remplacez domaines seulement après validation.
SaaS avec workers — arrêtez consumers avant dump ; relancez après bascule DNS pour éviter double traitement.
Médias sur S3 — pas de rsync disque : même bucket ou replication cross-region ; migrez seulement la config et les clés.
Rollback : préparer la marche arrière
Si le nouveau site casse après DNS :
- TTL bas permet repoint rapide vers ancienne IP.
- Ne détruisez pas l'ancien serveur avant validation 72 h.
- Documentez whois DNS et accès panneau des deux hébergeurs.
Le sommet : « zero downtime » marketing vs downtime de données
C'est l'écart entre la démo commerciale et la compta du lundi matin. Mesurez succès sur cohérence des données, pas seulement sur ping.
Décider et avancer sans angle mort
- Baissez TTL une semaine avant.
- Testez sur preview jusqu'à green complet.
- Exécutez la séquence J avec dump final figé.
- Surveillez post-bascule ; gardez rollback prêt.
- Comparez offres migration dans annuaire — lisez enquête migration gratuite.
Voir staging pour répéter la migration à blanc avant prod.
Questions fréquentes
Combien de temps baisser le TTL DNS avant migration ?
Passez à 300 s au moins 24–48 h avant — idéalement une semaine si l'ancien TTL était long.
Migrer d'abord les fichiers ou la base ?
Sync fichiers d'abord ; base en lecture seule au moment J pour dump final cohérent.
Faut-il couper le site pendant la migration ?
Pas des heures. Maintenance court au dump final suffit si le reste est préparé.
Comment tester avant de pointer le DNS ?
Hosts file, hostname temporaire ou URL preview hébergeur. Validez login, formulaires, emails, cron.
Le bon outil de migration est celui que votre équipe sait exécuter dans le bon ordre — avec un plan B DNS prêt avant d'appuyer sur Entrée.