Migrer de nuit après un nettoyage : la checklist
Migrer de nuit après un nettoyage : site déjà propre, TTL DNS baissé, e-mails prévus, tous les mots de passe régénérés, ancien cron coupé, ancienne IP surveillée quelques jours. Le nouveau serveur n'est sûr que si l'entrée est fermée. Une bascule visible tient souvent en quelques minutes — le travail est avant. Migrer un zip de suspension encore sale brûle parfois le contrat neuf en 24 heures.
Site propre, DNS TTL baissé, emails prévus, mots de passe tous régénérés, ancien cron coupé, ancienne IP surveillée quelques jours. Le nouveau serveur n'est sûr que si l'entrée est fermée.
Pourquoi la nuit, et pourquoi pas avant d'être propre
La nuit : moins de clients, TTL déjà bas, vous êtes disponibles. Ce n'est pas « plus furtif pour l'attaquant ». Si le site est encore sale, la nuit ne change rien : vous brûlez le nouveau compte. Changer d'hébergeur encore infecté. Quand changer.
Motifs de départ : isolation impossible, IP listée, support muet. Pas la honte. Tests visiteurs OK avant. Tests.
Boutique : une heure creuse, checkout testé en préalable sur l'IP / host temporaire. Vitrine vs boutique. Une home qui « marche » et un paiement cassé à 8 h n'est pas une victoire.
J-2 / J-1 : TTL, inventaire, secrets
TTL des A/AAAA à 300 s si vous les contrôlez (Gandi, Cloudflare, Infomaniak). Inventaire : vhosts, MX (restent-ils ?), cron, FTP à recréer, certificats, `.env`. Secrets NEUFS pour le nouveau panel — pas les anciens « pour aller plus vite ».
DNS : vérifiez qu'ils n'ont pas déjà bougé. Gandi. Cloudflare : plan de purge. Cloudflare.
Liste des abandonnés : ne les remigrez pas « pour plus tard » si vous pouvez les laisser hors de la copie.
La copie de migration n'est pas l'archive de suspension
Vous migrez un état TRAITÉ, pas le zip OVH du jour de l'abus. Archive sale. Comparez encore une fois les fichiers au zip officiel avant le transfert.
Outils de migration WP : pratiques, ils recopient parfois des mu-plugins. Vérifiez à l'arrivée. Site PHP : rsync / git propre. Site PHP.
Bases : import, URLs, clés. Pas d'admins fantômes réimportés : revue. Moindre privilège.
Nuit J : ordre de bascule
1) Site répond sur l'IP / hôte temporaire, tests internes. 2) Cron ANCIEN coupé (sinon double envoi, double mineur). 3) DNS A vers le neuf. 4) Certificat (HTTP-01 vs déjà chez CF). 5) Purge CDN. 6) Spot check mobile.
Ne laissez pas les deux vhosts écrire la même base. Ne laissez pas deux crons.
Adresse perso sur les deux tickets (ancien + nouveau) si un abus sort. Mail coupé.
Mails, cron, FTP, panel neuf
MX : ne les touchez que si le mail déménage aussi. Sinon ils restent. SPF : IP d'envoi si le site envoie encore via l'hébergeur.
FTP/SFTP neufs, jailed, nominatifs. Panel 2FA. cPanel.
Cron recréés un par un, lus. Pas un export aveugle de l'ancien crontab.
Le matin : tests, caches, Search Console
4G, privé, clic Google, `site:`, inspection URL. www / nu / IPv6. IPv6 www.
Search Console : pas un réexamen Safe Browsing « parce qu'on a migré ». Seulement si une alerte existait et que c'est propre. Blacklist.
WAF / CF : origine neuve dans les records, restriction origine à froid plus tard. WAF.
Ancien compte : éteindre sans tout oublier
Vhost coupé, cron mort, FTP révoqués, archive hors ligne gardée. Surveillez l'ancienne IP quelques jours (sous-domaine oublié). Isolation.
Résiliation quand MX et DNS sont stables. Trop tôt = mail coupé au milieu.
Réputation de l'ancienne IP : plus votre problème une fois éteint. Réputation IP.
Si ça rate : rollback prévu
Gardez l'ancien vhost prêt (sans cron) quelques heures. TTL bas = retour DNS possible. Un rollback vers un ancien ENCORE SALE est pire que deux heures de 500. Décidez avant, par écrit.
Hostinger / builders : republier, caches. Hostinger.
Créer un compte si la bascule + boutique + mail dépassent une nuit. Un rollback vers un ancien sale est pire qu'un 500 de deux heures : prévoyez la règle avant, par écrit.
Boutique : testez le checkout sur l'hôte temporaire AVANT le DNS. Une bascule qui « marche la home » et casse le paiement à 8 h n'est pas une victoire.
Ce qu'on ne migre pas (et qu'on croit anodin)
Les cron de l'ancien, les FTP `agence`, le mu-plugin « tmp », le zip `backup` à la racine, les sites `old.` encore en 200, les clés AUTH WordPress anciennes si vous pouvez les régénérer, le même mot de passe panel « pour aller plus vite ». La checklist de quand changer sert ici : on part pour isoler, pas pour déménager la porte.
Outils de migration WP : relisez `mu-plugins` et les users à l'arrivée. Site PHP : un git sale rappliqué est un rebuild inutile. Site PHP. Dépendances : pas le même cache Composer.
Ancien compte : vhost coupé, cron mort, archive hors ligne, résiliation quand les MX sont stables. Surveillez l'ancienne IP quelques jours (sous-domaine oublié). Isolation. TTL encore haut : assumez des heures, pas « instantané ».