Checklist de migration de site
Mis à jour le 6 min de lecturePar l’équipe DNSPeek
Une migration de site sûre comporte six phases : planifier, préparer le nouveau serveur, le tester avant le changement DNS, basculer, vérifier et nettoyer. La règle clé : l’ancien serveur continue de servir les visiteurs jusqu’à ce que le nouveau ait été vérifié, et n’est résilié qu’une fois que le trafic ne l’atteint plus. Imprimez cette page et cochez chaque point au fur et à mesure.
Comment utiliser cette checklist
Suivez les phases dans l’ordre. Les points qui ne concernent pas votre site, comme la messagerie pour un site sans e-mail, peuvent être barrés. Utilisez le bouton d’impression ou la commande d’impression de votre navigateur pour obtenir une copie papier propre avec des cases à cocher ; la navigation et le pied de page ne sont pas imprimés.
Chaque phase renvoie à un guide détaillé. Pour les parties propres à une plateforme, voir Migration WordPress sans interruption, la checklist cPanel vers cPanel ou Migrer vers un VPS.
Phase 1 : planifier
- Date et heure de la migration choisies, hors des pics de trafic
- Accès confirmés : ancien hébergeur, nouvel hébergeur, fournisseur DNS, registrar, CDN
- Inventaire rédigé : domaines, sous-domaines, bases de données, boîtes mail, tâches cron, intégrations
- Hébergement de la messagerie identifié (même hébergeur, prestataire séparé ou aucun)
- Qui valide la mise en ligne, et qui est d’astreinte pendant la bascule
- Plan de retour en arrière : comment refaire pointer le DNS vers l’ancien serveur
- TTL actuels notés pour chaque enregistrement qui va changer
Vérifiez les TTL avec le vérificateur de TTL et voyez qui héberge aujourd’hui le domaine, son DNS et sa messagerie avec Qui héberge ce site ?.
Phase 2 : préparer le nouveau serveur
- Sauvegarde complète de l’ancien site téléchargée et stockée hors de l’ancien serveur
- Le nouveau serveur reproduit l’environnement d’exécution : version de PHP ou Node, extensions, version de la base de données
- Fichiers copiés et permissions définies
- Base de données importée ; configuration de l’application mise à jour avec les nouveaux identifiants
- Hôte virtuel ou site configuré pour le domaine et www
- Règles au niveau du serveur recréées : redirections, règles de réécriture, limites PHP
- Tâches cron préparées (pas encore actives en double avec l’ancien serveur)
- TTL réduit à 300 secondes, un ancien TTL avant la bascule
Pourquoi le TTL compte : Réduire le TTL avant une migration.
Phase 3 : tester avant de modifier les DNS
- Le site s’ouvre sur la nouvelle IP sous son vrai domaine (lien d’aperçu ou fichier hosts)
- Page d’accueil et pages clés vérifiées sur ordinateur et sur téléphone
- Formulaires envoyés ; les e-mails de notification arrivent
- La connexion au CMS ou à l’administration fonctionne ; un envoi de média fonctionne
- Paiement ou connexion testés avec des comptes de test
- Exploration QA lancée ; constats critiques corrigés et nouvelle exploration effectuée
- Ancien et nouveau site comparés côte à côte
- Aucun reste de préproduction : noindex, blocages robots.txt, URL temporaires
- Plan pour le certificat : valide maintenant, ou émis juste après la bascule
- Validation du client ou du propriétaire consignée
Un lien d’aperçu DNSPeek couvre les premiers points sur n’importe quel appareil et se partage pour validation ; un rapport QA et la comparaison en direct couvrent l’exploration et la comparaison. Compromis entre méthodes : fichier hosts ou lien d’aperçu. Validations : validation client avant la mise en ligne.
Phase 4 : basculer
- Gel du contenu sur l’ancien site (commandes, commentaires, articles)
- Synchronisation finale de la base de données et des nouveaux fichiers envoyés
- Enregistrement A du domaine modifié vers la nouvelle IP
- www et les autres noms d’hôte modifiés
- Ancien enregistrement AAAA mis à jour ou supprimé
- Enregistrements MX et de messagerie modifiés, seulement si la messagerie migre aussi
- Origine du CDN mise à jour, si un CDN sert de proxy au site
Phase 5 : vérifier
- Les résolveurs publics renvoient la nouvelle IP
- Le site répond depuis le nouveau serveur
- Certificat valide pour chaque nom d’hôte
- Redirections : de http vers https et gestion de www en une ou deux étapes
- En-têtes de sécurité présents comme avant
- MX, SPF, DKIM et DMARC corrects ; e-mail de test envoyé et reçu
- Formulaires et e-mails transactionnels délivrés
- Tâches cron actives uniquement sur le nouveau serveur
- Statistiques actives ; sitemap accessible
Outils pour cette phase : vérificateur de propagation DNS, Mon domaine est-il basculé ?, vérificateur SSL, vérificateur de redirections, vérification des en-têtes de sécurité, recherche MX, vérificateur SPF et vérificateur DMARC. La liste complète des points à contrôler : que vérifier après un changement d’hébergeur.
Phase 6 : nettoyer
- Les journaux d’accès de l’ancien serveur ne montrent plus de vrais visiteurs
- Plus aucun nouvel e-mail n’arrive sur l’ancien serveur
- Sauvegarde finale de l’ancien compte conservée
- TTL remonté à 3600 secondes ou plus
- Entrées du fichier hosts supprimées ; liens d’aperçu désactivés
- Sauvegardes et supervision configurées chez le nouvel hébergeur
- Ancien hébergement résilié
Combien de temps attendre : Combien de temps dure la propagation DNS.
En cas de problème : le retour en arrière
Un retour en arrière n’est simple que si vous l’avez prévu. Comme l’ancien serveur tourne toujours et que le TTL est court, annuler une bascule revient à faire la même opération en sens inverse : refaites pointer les enregistrements vers l’ancienne IP, et les visiteurs reviennent en quelques minutes. Décidez à l’avance de ce qui déclencherait un retour en arrière, comme un paiement qui échoue ou un site qui renvoie des erreurs, et de qui prend la décision.
Les données écrites sur le nouveau serveur après la bascule, comme les commandes, inscriptions ou commentaires, ne reviennent pas d’elles-mêmes. Notez l’heure de la bascule pour pouvoir retrouver et copier ces données si vous devez revenir temporairement sur l’ancien serveur.
La migration en un coup d’œil
Étape 1 : Planifier
Inventoriez domaines, données, messagerie et intégrations, confirmez tous les accès et convenez d’un plan de retour en arrière.
Étape 2 : Réduire le TTL
Passez les enregistrements que vous allez modifier à 300 secondes, au moins un ancien TTL avant la bascule.
Étape 3 : Préparer le nouveau serveur
Copiez les fichiers et la base de données, alignez les versions de l’environnement d’exécution et recréez les règles au niveau du serveur.
Étape 4 : Tester avant le DNS
Ouvrez le site sur la nouvelle IP sous son vrai domaine, lancez une exploration QA, comparez avec l’ancien site et obtenez la validation.
Étape 5 : Basculer
Gelez le contenu, faites une synchronisation finale et mettez à jour les enregistrements A, AAAA et les autres.
Étape 6 : Vérifier
Contrôlez la propagation, le certificat, les redirections, la messagerie et les formulaires.
Étape 7 : Nettoyer
Quand le trafic a cessé sur l’ancien serveur, faites une sauvegarde finale, remontez le TTL et résiliez l’ancien hébergement.
Résumé sur une page
Les dix points les plus importants
- Sauvegarde hors serveur effectuée
- TTL réduit un ancien TTL à l’avance
- Versions de l’environnement d’exécution alignées sur le nouveau serveur
- Site testé sur la nouvelle IP avant le DNS
- Exploration QA sans problème
- Validation consignée
- Contenu gelé et synchronisé
- Chaque nom d’hôte et enregistrement AAAA basculé
- Certificat, redirections, messagerie et formulaires vérifiés
- Ancien hébergeur résilié seulement après l’arrêt du trafic
Questions fréquentes
Qu’est-ce qu’une checklist de migration de site ?
C’est une liste ordonnée des tâches nécessaires pour déplacer un site vers un nouveau serveur ou hébergeur sans interruption ni perte de données, de la planification et des sauvegardes aux tests, à la bascule DNS, aux vérifications et à la résiliation de l’ancien hébergement.
Combien de temps dure une migration de site ?
Copier un petit site prend de quelques minutes à quelques heures. Prévoyez au moins une journée au total, car le TTL doit être réduit la veille et l’ancien serveur conservé quelques jours après la bascule.
Puis-je télécharger cette checklist en PDF ?
Utilisez le bouton d’impression et choisissez Enregistrer au format PDF dans la boîte de dialogue d’impression de votre navigateur. L’impression comprend les cases à cocher et omet la navigation du site.
Quelle est l’erreur de migration la plus fréquente ?
Basculer les DNS avant d’avoir testé le nouveau serveur, suivie de près par l’oubli des enregistrements de messagerie et la résiliation trop précoce de l’ancien hébergeur. Tester avant la bascule et garder l’ancien serveur quelques jours évite ces trois erreurs.
Cette checklist convient-elle à toutes les plateformes ?
Oui. Les phases s’appliquent à WordPress, aux autres CMS, aux frameworks et aux sites statiques. Les étapes propres à une plateforme, comme le remplacement des URL dans une base de données WordPress, sont traitées dans les guides liés.