Sauvegardes et migrations

Ce qu'il faut vérifier avant de migrer un hébergement

Vérifié le 11 min de lecture migrations hébergement liste de contrôle compatibilité

Une migration sûre commence avant de copier des fichiers. Préparer cet inventaire permet de savoir ce qu'il faut déplacer, de choisir une offre adaptée et d'éviter qu'un site, une boîte mail ou un service externe reste chez l'ancien fournisseur.

Si vous n'avez pas encore choisi le parcours, commencez par le guide pour migrer un hébergement vers Hostsuar.

La migration du service d'hébergement vers Hostsuar est gratuite. Vous pouvez utiliser cette liste pour la préparer vous-même ou pour nous fournir les informations nécessaires afin que notre équipe se charge du processus.

Définissez le périmètre

Notez quels éléments doivent fonctionner chez Hostsuar après le changement :

  • Domaines et sous-domaines.
  • Sites, répertoires et applications.
  • Bases de données.
  • Comptes de messagerie et messages stockés.
  • Redirections, filtres et réponses automatiques.
  • Tâches planifiées ou cron.
  • Enregistrements DNS de services externes.
  • Certificats propres, si vous en utilisez un qui ne peut pas être réémis.

Transférer le domaine ne copie aucun de ces éléments. Décidez séparément si vous voulez seulement migrer l'hébergement ou aussi changer le registraire du domaine.

Identifiez le panneau et le fournisseur actuels

Vérifiez si l'origine utilise cPanel, Plesk ou un autre panneau :

  • cPanel : permet normalement de générer une sauvegarde complète compatible avec la destination.
  • Plesk ou un autre panneau : confirmez quelle méthode de transfert l'origine accepte. S'il n'existe pas d'import compatible, il faudra déplacer séparément les fichiers, les bases de données, le courrier et la configuration.
  • Plateforme fermée : des services comme Wix peuvent ne pas permettre d'exporter une application complète et exiger une reconstruction.

Confirmez aussi si le fournisseur maintient actifs l'hébergement et la zone DNS lorsque le domaine est transféré. Ne lancez pas le transfert administratif si cela risque d'entraîner la suppression du contenu avant sa copie.

Calculez l'espace nécessaire

Examinez séparément :

  • Les fichiers des sites.
  • Les bases de données.
  • Les boîtes mail.
  • Les sauvegardes stockées dans le compte.
  • Les répertoires temporaires, journaux et caches.

L'espace total affiché par le panneau peut inclure d'anciennes sauvegardes ou des fichiers superflus. Ne choisissez pas l'offre de destination uniquement d'après ce chiffre : distinguez le contenu nécessaire de ce qui peut être nettoyé avant de migrer.

Vérifiez la compatibilité des applications

Pour chaque site, notez :

  • L'application et sa version : WordPress, PrestaShop, Joomla ou autre.
  • La version de PHP et les extensions nécessaires.
  • La version et la taille de MySQL ou MariaDB.
  • Les tâches planifiées.
  • Les processus externes, files d'attente ou commandes à exécuter.
  • Les licences liées au domaine ou à l'IP.
  • Les intégrations avec des passerelles de paiement, des API, du stockage ou des services tiers.

Une sauvegarde correcte ne garantit pas qu'une ancienne application fonctionne avec une autre version de PHP ou de la base de données. Résolvez ces incompatibilités avant le changement ou conservez temporairement une version compatible sur la destination.

Inventoriez les domaines et le DNS

Gardez une copie de la zone DNS et examinez en particulier :

  • Les enregistrements A et AAAA du site et des sous-domaines.
  • Les enregistrements MX du courrier.
  • Les enregistrements TXT de SPF, DKIM, DMARC et des vérifications ; certains fournisseurs publient DKIM au moyen d'un CNAME.
  • Les enregistrements CNAME et SRV de Microsoft 365, Google Workspace ou d'autres services.
  • Les sous-domaines utilisés par des applications, standards téléphoniques, agendas ou outils externes.

Si le courrier reste chez Google Workspace, Microsoft 365 ou un autre fournisseur, reproduisez ses enregistrements dans la nouvelle zone avant de changer les serveurs DNS.

Si vous changez les serveurs DNS et que le domaine utilise DNSSEC, organisez aussi le changement de ses clés et de ses enregistrements DS. Garder un DS qui ne correspond pas à la nouvelle zone peut empêcher le domaine de se résoudre.

Inventoriez le courrier

Pour chaque domaine, déterminez :

  • Quel fournisseur reçoit actuellement le courrier.
  • Combien de boîtes mail existent et combien occupe chacune.
  • Si vous utilisez IMAP, POP ou Exchange.
  • Si les messages restent sur le serveur ou seulement sur les appareils.
  • Quelles redirections, filtres et réponses automatiques sont configurés.
  • Si vous utilisez des contacts, des agendas ou des fichiers qui ne font pas partie de la boîte IMAP.

Imapsync copie les messages, les dossiers et leur état entre serveurs IMAP, mais il ne remplace pas une migration complète de Microsoft 365 et ne copie pas à lui seul les agendas, les contacts ou les règles externes.

Préparez les accès

Selon l'origine, il peut falloir :

  • Un accès temporaire à cPanel pour générer une sauvegarde complète.
  • Un accès SFTP ou FTPS limité aux répertoires à copier.
  • Un utilisateur de base de données temporaire limité aux bases nécessaires.
  • Un accès IMAP ou un mot de passe d'application pour chaque boîte mail à synchroniser.
  • L'accès au fournisseur DNS pour effectuer le changement final.
  • Votre disponibilité pour approuver un second facteur d'authentification si nécessaire.

N'envoyez ni mots de passe, ni codes d'autorisation (auth-codes), ni codes de second facteur dans le texte d'un ticket ou d'un e-mail. Si l'assistance a besoin d'accéder à l'origine, demandez le canal sécurisé et utilisez des identifiants temporaires, différents des habituels et avec la portée la plus réduite possible.

Décidez quand le changement aura lieu

Le parcours habituel est :

  1. Créer et dimensionner le service de destination.
  2. Faire une première copie des sites, bases de données et boîtes mail.
  3. Vérifier le contenu sans changer le DNS.
  4. Corriger les incompatibilités et reproduire les enregistrements DNS externes.
  5. Programmer un créneau de faible activité.
  6. Copier les dernières modifications des bases de données et resynchroniser le courrier.
  7. Changer le DNS.
  8. Vérifier le site, le courrier, HTTPS et les services externes.
  9. Garder l'origine active pendant la transition.
  10. Révoquer les accès et résilier l'ancien fournisseur seulement après la vérification finale.

Pour les boutiques, réservations, forums et sites au contenu dynamique, évitez que des modifications continuent à se produire sur les deux serveurs pendant la bascule. Si l'activité ne peut pas être arrêtée, convenez de la manière dont se fera la synchronisation finale.

Décidez quel serveur exécutera les tâches planifiées pendant la transition pour éviter des envois, des paiements ou d'autres processus en double. Notez par écrit quand arrêter le changement et comment rétablir le service. Refaire pointer le DNS vers l'origine ne récupère pas à lui seul les commandes ou les messages déjà arrivés sur la destination.

Informations que vous pouvez fournir sans inclure de secrets

Pour examiner une migration, indiquez :

  • Le fournisseur et le panneau actuels.
  • Les domaines, sites et sous-domaines inclus.
  • L'espace utilisé par les fichiers, les bases de données et le courrier.
  • Les principales applications et leurs versions.
  • Le fournisseur de messagerie et le nombre de boîtes mail.
  • Si le courrier restera à l'extérieur ou sera aussi déplacé.
  • Qui gère actuellement la zone DNS.
  • La date limite ou le créneau préféré pour le changement.
  • Si le site reçoit des commandes, des formulaires ou des modifications fréquentes.

Avec ces données, on peut évaluer le périmètre et confirmer ensuite quels accès temporaires sont réellement nécessaires.

Vérification avant de commencer

Ne lancez pas le changement avant de pouvoir répondre oui à chaque point :

  • J'ai une sauvegarde récupérable du contenu actuel.
  • Je sais quel fournisseur sert le site et lequel sert le courrier.
  • J'ai identifié tous les enregistrements DNS externes.
  • Le service de destination dispose d'assez d'espace et de versions compatibles.
  • Je peux accéder au contenu, aux bases de données et aux boîtes mail à copier.
  • Je peux modifier le DNS le moment venu.
  • L'ancien fournisseur restera actif pendant la transition.
  • Je sais comment vérifier le site et le courrier avant de résilier l'origine.

Une fois l'inventaire complet, poursuivez avec le parcours de migration de l'hébergement.

Cela peut aussi vous aider

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