Sauvegardes et migrations

Ce qu'il faut vérifier après avoir migré un hébergement

Vérifié le 9 min de lecture migrations hébergement vérifications DNS

Une migration ne s'achève pas quand les fichiers sont copiés ou le DNS changé. Avant de résilier l'ancien fournisseur, il faut vérifier que le site, les données, le courrier et les services externes fonctionnent réellement depuis le nouvel hébergement.

Utilisez cette liste après avoir migré un hébergement vers Hostsuar et répétez-la une fois la propagation terminée.

Confirmez quel serveur répond

Avant d'interpréter un test, vérifiez que le domaine et ses sous-domaines se résolvent vers la destination :

  • Serveurs DNS faisant autorité.
  • Enregistrements A et AAAA du site.
  • Enregistrements MX du courrier.
  • Domaine avec et sans www.

Pendant la propagation, votre ordinateur peut encore voir l'ancien fournisseur alors qu'un autre utilisateur accède déjà au nouveau. Utilisez la vérification de propagation DNS et IP et ne résiliez pas l'origine sur la base d'une seule connexion.

Vérifiez le site

Ne vérifiez pas seulement la page d'accueil. Testez :

  • Le domaine avec et sans www.
  • Les pages internes et les permaliens.
  • L'administration de l'application.
  • La connexion et la récupération du mot de passe.
  • Les formulaires de contact.
  • Le moteur de recherche, les filtres et le contenu dynamique.
  • L'envoi et le téléchargement de fichiers.
  • Les redirections et les pages d'erreur.
  • La boutique, le panier, les commandes et les passerelles de paiement.

Faites les tests dans une fenêtre privée pour réduire l'influence des cookies et des sessions précédentes. Cela ne vide pas le cache DNS et ne modifie pas le fichier hosts. Si vous l'avez modifié pour prévisualiser, retirez ces entrées et vérifiez aussi depuis un autre réseau.

Utilisez le mode test des passerelles pour vérifier les paiements et évitez de générer des paiements ou des notifications réels sans coordination.

Vérifiez la base de données et les dernières modifications

Vérifiez que les commandes, formulaires, commentaires ou modifications créés peu avant le changement apparaissent bien. S'il manque des informations récentes, elles ont pu être générées chez l'ancien fournisseur après la première copie.

Avant de refaire un import complet, identifiez quelles données manquent et où elles ont été produites. Écraser la base de données de destination peut supprimer des modifications créées après la migration.

Vérifiez aussi :

  • La connexion et les identifiants configurés dans l'application.
  • Les préfixes, l'encodage et les tables attendues.
  • Les chemins absolus qui mentionnent encore l'ancien serveur.
  • Les utilisateurs et les permissions de base de données.

Vérifiez PHP et l'application

Un site copié correctement peut échouer si l'environnement est différent. Comparez :

  • La version de PHP.
  • Les extensions nécessaires.
  • Les limites de mémoire, d'envoi et d'exécution.
  • La version de MySQL ou MariaDB.
  • Les tâches planifiées.
  • Les processus en arrière-plan ou les files d'attente.
  • Les licences liées au domaine ou à l'ancienne IP.

Consultez le journal d'erreurs de l'application si une fonction précise échoue alors que la page d'accueil se charge.

Vérifiez les tâches planifiées

Vérifiez que les tâches cron ont été copiées et que leurs chemins correspondent au nouveau serveur. Confirmez en particulier les tâches qui :

  • Importent ou exportent des données.
  • Envoient des rappels et des notifications.
  • Exécutent des sauvegardes.
  • Traitent des commandes, des paiements ou des abonnements.
  • Synchronisent des services externes.

Vérifiez que les tâches de l'origine n'exécutent plus les mêmes paiements, envois ou synchronisations. Convenez du moment où elles s'arrêtent là-bas et s'activent sur la destination.

Vous pouvez examiner leur configuration depuis Tâches Cron dans cPanel.

Vérifiez HTTPS

Testez le certificat sur :

  • Le domaine principal.
  • La version www.
  • Les sous-domaines utilisés.
  • Le webmail et les noms de service, le cas échéant.

Notre vérificateur SSL affiche depuis l'extérieur le certificat que sert chaque nom : noms couverts, émetteur, dates de validité et si la chaîne est de confiance. Confirmez aussi que le navigateur n'affiche pas d'avertissement.

Vérifiez que l'application redirige correctement de HTTP vers HTTPS et qu'elle ne charge pas d'images, de scripts ou de styles depuis des adresses non sécurisées.

Si le domaine pointe déjà vers le nouvel hébergement et que le certificat n'a pas été émis, consultez l'état SSL des domaines.

Testez le courrier

Envoyez des messages dans les deux sens avec un compte externe et vérifiez :

  • La réception dans les boîtes mail migrées.
  • L'envoi authentifié depuis le webmail et les appareils.
  • Les formulaires et les notifications du site.
  • Les dossiers, les messages envoyés et l'ancien contenu.
  • Les redirections, les filtres et les réponses automatiques.
  • L'espace disponible dans chaque compte.

Vérifiez que les enregistrements MX, SPF, DKIM et DMARC correspondent au fournisseur définitif. Si le courrier reste chez Google Workspace ou Microsoft 365, confirmez aussi ses CNAME et SRV.

Lancez une dernière synchronisation pour récupérer les messages livrés à l'origine pendant la propagation, en suivant le guide pour migrer le courrier sans perdre de messages.

Vérifiez les sous-domaines et les services externes

Vérifiez tous les éléments notés dans l'inventaire préalable :

  • Sous-domaines et domaines supplémentaires.
  • API et webhooks.
  • Standards téléphoniques et services de téléphonie.
  • Google Search Console et vérifications TXT.
  • Plateformes de paiement.
  • CDN, stockage et services d'images.
  • Microsoft 365, Google Workspace et agendas.

Un service externe peut cesser de fonctionner même si le site se charge, si son enregistrement DNS n'a pas été reproduit dans la nouvelle zone.

Gardez l'origine jusqu'à la fin

Gardez l'ancien fournisseur actif tant que :

  • Des résolveurs affichent encore l'ancienne configuration.
  • Il reste des messages ou des données à synchroniser.
  • Les fonctions critiques n'ont pas été testées.
  • Vous avez besoin d'une voie de retour.

Si vous détectez une panne grave, suivez la procédure de changement DNS avec une interruption minimale avant de rétablir les anciens enregistrements. N'oubliez pas que le retour doit aussi se propager.

Clôturez la migration

Quand toutes les vérifications sont correctes :

  1. Faites une dernière sauvegarde récupérable.
  2. Confirmez qu'il ne reste ni messages ni données récentes uniquement sur l'origine.
  3. Révoquez les utilisateurs temporaires, les mots de passe d'application et les accès de l'assistance.
  4. Changez tout mot de passe habituel qu'il a fallu utiliser.
  5. Retirez les tâches, les synchronisations et les fichiers de test temporaires. Vérifiez de nouveau qu'il ne reste aucune entrée locale dans hosts qui force l'IP.
  6. Résiliez l'ancien fournisseur.
  7. Conservez l'inventaire et la date du changement pour de futures vérifications.

La migration est terminée quand le service fonctionne depuis la destination et ne dépend plus du contenu, du courrier, du DNS ni des accès de l'ancien fournisseur.

Cela peut aussi vous aider

Quelque chose cloche ou a changé ? Racontez-nous et nous le vérifions.