Passer au contenu 
Je vais te montrer comment un déménagement de domaine strato et les étapes que tu dois suivre dans le bon ordre. Voici comment tu contrôles le transfert, DNS et e-mail propres et garde ton site web accessible pendant le changement.
Points centraux
- PréparationSauvegarde, vérification des contacts, sauvegarde du code d'authentification
- Transfert: Débloquer le domaine, démarrer le déménagement, confirmer les e-mails
- DNSabaisser le TTL, vérifier les enregistrements, définir le serveur de noms
- Courrier électronique: migrer proprement MX, SPF, DKIM et les boîtes aux lettres
- Contrôlevérifier le monitoring, les logs, les redirections et les paiements
Préparation : la base d'un changement en douceur
Avant de commencer le changement, je choisis un registraire approprié et je vérifie les Exigences à l'assistance, au service et aux outils. Ensuite, je déverrouille le domaine, je demande le code d'authentification et je vérifie les contacts du propriétaire et de l'administrateur pour que les confirmations arrivent. Une sauvegarde complète des fichiers et des bases de données fait partie intégrante de mon travail, car elle me permet de me prémunir contre les risques. Perte de données à partir de. Si j'utilise le courrier électronique via le domaine, j'informe les contacts importants à l'avance et je fixe une date avec peu de trafic. Pour plus de détails sur le déroulement, un petit coup d'œil sur la Guide du changement de registraireJe dois donc me renseigner sur les étapes obligatoires.
Pas à pas : Démarrer et confirmer le transfert
Je démarre le déménagement auprès du nouveau registraire, j'indique le nom de domaine et le nom de domaine. Code Auth et je confirme la demande de transfert par e-mail. Dans certains cas, je demande en plus l'accord dans le centre clients de Strato pour que le processus démarre immédiatement. Pendant ce temps, je garde un œil sur les e-mails, je vérifie le dossier des spams et je réagis rapidement aux demandes de précisions. Je prévois un temps d'attente, car le transfert proprement dit dure de quelques heures à quelques jours, selon la terminaison. Dès que le transfert est terminé, je suis prêt à DNS-conversion.
DNS : définir correctement les enregistrements et éviter les temps d'arrêt
Avant le changement, j'abaisse la TTL de mes enregistrements DNS à 300-900 secondes, afin que les modifications prennent effet plus rapidement. Ensuite, je définis A/AAAA, CNAME, MX et, le cas échéant, les enregistrements TXT pour SPF, DKIM et DMARC chez le nouveau fournisseur. S'il existe des sous-domaines, je vérifie chacun d'entre eux afin qu'aucune app ou API ne tombe en panne. Je ne modifie les serveurs de noms que lorsque tous les enregistrements sont corrects, ce qui me permet de réduire au minimum le temps d'arrêt. Après la conversion, j'attends les Propagation et tester l'accessibilité depuis plusieurs réseaux.
Migrer proprement les boîtes aux lettres électroniques
Pour les e-mails, je copie idéalement les boîtes aux lettres par IMAP-Sync, afin de conserver la structure des dossiers et l'état des lectures. Je place des enregistrements MX sur les serveurs de messagerie du nouvel hébergeur et je gère SPF, DKIM et DMARC pour que la distribution et la réputation soient correctes. Je maintiens brièvement les anciennes boîtes aux lettres actives en parallèle, au cas où des messages en attente se manifesteraient encore. Je teste les messages entrants et sortants, je vérifie les en-têtes et j'observe les taux des filtres anti-spam. En cas d'incertitude, je jette un coup d'œil dans Éviter les erreurs lors d'un déménagementJe ne veux pas qu'une petite chose m'échappe.
Tenir à jour le Whois et les données de contact
Je vérifie si les droits du propriétaire, de l'administrateur et de l'utilisateur sont respectés. Techsont corrects pour que les e-mails de transfert soient délivrés. Les modifications apportées au titulaire peuvent déclencher des contrôles supplémentaires, c'est pourquoi il vaut mieux que je m'en occupe avant le déménagement. Pour les options de protection des données, je décide si j'utilise l'anonymisation dans le Whois. Après le transfert, je contrôle à nouveau les données et je sécurise les factures et les durées de contrat. Ainsi, l'administration est préservée, Transparence et de la conformité sans équivoque.
Réduire la propagation, le calendrier et les pannes
Je planifie le changement dans une phase calme, afin que les visiteurs ne ressentent pas grand-chose. Selon le TLD et la mémoire cache du fournisseur, le processus dure DNS-propagation minutes à 24-48 heures. Je garde brièvement les deux environnements prêts en parallèle jusqu'à ce que les accès arrivent de manière fiable chez le nouvel hébergeur. Une courte fenêtre TTL définie au préalable accélère sensiblement les modifications. Après avoir terminé, j'augmente à nouveau le TTL pour que Stabilité et la répartition de la charge.
Comparaison de l'hébergement et choix du fournisseur
Pour mon changement, je fais attention à Performance, la qualité du support et un panel DNS compréhensible. Un support rapide permet d'économiser beaucoup de temps en cas d'urgence, surtout lorsque les temps d'arrêt sont courts. De bons outils DNS, des sauvegardes et des protocoles clairs comptent plus pour moi que de simples listes de fonctionnalités. Si je planifie WordPress ou plusieurs projets, je profite de serveurs puissants et de tarifs flexibles. L'aperçu suivant présente des fournisseurs qui facilitent sensiblement le transfert et la gestion quotidienne et Mise à l'échelle permettent.
| Place | Fournisseur | Particularités |
|---|---|---|
| 1 | webhoster.de | Serveurs très rapides, excellent support, gestion simple des DNS |
| 2 | Strato | Bon rapport qualité-prix, nombreuses options supplémentaires |
| 3 | IONOS | Une offre étendue, une infrastructure fiable |
| 4 | GoDaddy | Présence internationale, nombreuses fonctionnalités |
Éviter les erreurs fréquentes
Je ne renonce jamais à un Sauvegarde avant le déménagement, car le manque de sauvegardes est la pierre d'achoppement la plus fréquente. Des enregistrements DNS mal définis entraînent souvent des temps morts, c'est pourquoi je vérifie deux fois tous les enregistrements. Les adresses de contact obsolètes bloquent les confirmations, c'est pourquoi je les tiens à jour. Les e-mails avec des autorisations de transfert se perdent souvent dans les spams, je contrôle donc régulièrement les dossiers. Je documente chaque étape afin de pouvoir identifier rapidement les anomalies. corrige et répète
Redirections, serveurs de noms et signaux SEO
Après le déménagement, je mets en place les Redirectionspour que les anciens chemins mènent correctement aux nouvelles destinations. Les redirections 301 préservent les classements et assurent la cohérence des signaux. L'ordre est important : il faut d'abord nettoyer les DNS, puis tester les redirections. Ce petit guide m'aide pour les redirections spécifiques à Strato : Configurer une redirection Strato. Ensuite, je vérifie Plan du site et Robots.txt, afin que les robots d'exploration saisissent rapidement les nouvelles cibles.
Aspects juridiques, durées et calendrier
Je vérifie les durées de contrat, les fenêtres de résiliation et les éventuelles Transferlocksqui, selon le TLD, peuvent intervenir peu après l'enregistrement. Lors d'un changement de fournisseur, il ne doit pas y avoir de factures impayées, sinon le processus s'arrête. Je garde le code d'authentification confidentiel et le supprime une fois terminé. Je renouvelle ou migre les certificats (TLS/SSL) chez le nouvel hébergeur, afin que les navigateurs ne lancent pas d'avertissements. Ainsi, la présentation reste digne de confiance et conforme à la loi.
Liste de contrôle après le transfert et le suivi
Après le changement, je vérifie le site web, Courrier électronique et tous les sous-domaines en paix. J'effectue des contrôles de santé, je consulte les journaux et je définis des alarmes pour l'uptime et le SSL. Je contrôle les anomalies dans Analytics et Search Console. Je mets à jour les données de paiement et l'adresse de facturation auprès du nouveau registraire. Ensuite, j'augmente à nouveau le TTL et je documente les modifications finales. DNS-Paramètres.
Planification supplémentaire : déménagement du site web et de la base de données sans interruption
Si je ne déménage pas seulement le domaine, mais aussi l'hébergement, je prépare le changement de serveur de manière à ce que les accès se poursuivent sans interruption. Je copie d'abord les fichiers dans leur intégralité sur le nouveau serveur (par ex. via SFTP/rsync), je crée la base de données et j'importe un dump. Pour les pages dynamiques, je prévois une courte phase de lecture seule : j'active le mode de maintenance, je lance un dernier appel à l'aide et j'envoie un message de confirmation. Synchro différentielle des téléchargements et un dump final de la base de données, puis je retire le mode de maintenance après le cutover DNS. J'évite ainsi que les nouveaux commentaires, commandes ou téléchargements soient perdus en cours de route.
Testing local par fichier Hosts
Avant de changer les serveurs de noms, je teste le nouvel environnement localement via le fichier Hosts. Je résous le domaine de manière ciblée sur la nouvelle IP, je vérifie la connexion, la mise en cache, la version PHP, les tâches cron, les chemins d'accès aux images et les appels API. Si tout fonctionne, le live cutover est également adapté. Cette procédure me permet d'éviter les corrections frénétiques pendant la conversion proprement dite.
Exécuter proprement les DNSSEC, CAA et le changement de serveur de noms
J'utilise DNSSECJe fais attention à l'ordre correct : je désactive DNSSEC chez l'ancien fournisseur ou, le cas échéant, je supprime l'enregistrement DS de l'entrée de registre avant de changer les serveurs de noms. Une fois la zone reprise avec succès chez le nouveau fournisseur, je signe à nouveau la zone et redéfinis l'enregistrement DS. J'évite ainsi les erreurs de validation. En outre, je vérifie CAA-pour que mon fournisseur de certificats continue d'être autorisé. Ce n'est que lorsque les DNSSEC seront à nouveau actifs et stables que j'augmenterai les TTL à un niveau normal.
Propres serveurs de noms et glue records
Si je gère mes propres serveurs de noms (ns1.mondomaine.tld), je pense à Glue-Records. Avant de modifier la délégation, j'enregistre ou je mets à jour les IP de Glue directement à l'entrée du registre. Si Glue et A/AAAA ne correspondent pas, il y a un risque de problèmes de résolution. En cas de changement de serveur, je mets d'abord à jour les IP, j'attends la propagation et je règle ensuite la délégation afin d'éviter les dépendances circulaires.
Certificats, HSTS et transition TLS
Pour TLS/SSL je planifie l'émission du certificat avant la mise en service. Avec ACME/Let's Encrypt, je décide si j'utilise http-01 (requiert l'accessibilité de la nouvelle IP) ou dns-01 (requiert un enregistrement TXT). dns-01 est flexible lors du déménagement du domaine, car j'effectue la validation indépendamment du serveur web. HSTS-Je laisse les directives conservatrices pendant le changement afin d'éviter les échecs difficiles, puis je les renforce une fois qu'elles sont stabilisées. La CAA reste définie de manière appropriée afin que les certificats soient délivrés de manière fiable.
Détails des e-mails : autodiscover, SRV, alias et cutover
Au-delà des MX-Records, je prends en compte Autodiscover (CNAME/A-Record) et le cas échéant FSR-pour les services comme Exchange ou les suites de collaboration. Je garde les enregistrements SPF légers et je vérifie si tous les systèmes émetteurs sont mentionnés (serveur web, outil de newsletter, ERP). Je fais une rotation contrôlée du cut-over du courrier : Créer d'abord les nouvelles boîtes aux lettres, puis abaisser MX et faire un miroir parallèle par synchronisation IMAP. Je compte sur une Période de transitionJe laisse le forwarder ou une règle "catch all" actif pendant un court laps de temps. Après la commutation, je contrôle les rapports DMARC et les signatures DKIM de manière aléatoire via les en-têtes des messages.
Spécificités et délais du TLD
- .deLes transferts sont généralement rapides. Un code AuthInfo à jour est obligatoire. Je prévois tout de même une marge pour la confirmation.
- .com/.net/.orgAprès un changement de titulaire, un blocage de 60 jours peut s'appliquer. Le statut clientTransferProhibited bloque le déménagement - je lève le verrou à l'avance
- ccTLDs: Selon le registre, des processus différents s'appliquent et il n'y a pas de prolongation automatique de la durée lors du transfert. Je vérifierai les modalités en temps utile.
Exemple d'horaire pour un déménagement en soirée
- Jour précédent : abaissement du TTL, sauvegarde complète, synchronisation initiale IMAP, test du nouvel environnement via le fichier Hosts.
- 18:00 : Dernier diff-sync de fichiers, DB en mode de maintenance court, dump final et importation.
- 18:30 : Vérifier le statut du transfert, déclencher le changement de serveur de noms ou le changement de zone.
- 18:45-20:00 : Observer la propagation, tester HTTP/S, le flux de courrier et les sous-domaines, corriger rapidement les erreurs.
- 20:00+ : Désactiver le mode maintenance, armer le monitoring, garder un œil sur les logs.
- Le jour suivant : augmenter à nouveau le TTL, actualiser la documentation, désactiver l'ancien environnement de manière planifiée.
Déménagements par lots et dépendances
Si j'ai plusieurs domaines, je donne la priorité Domaines de base et identifie les dépendances (par exemple les sous-domaines API, SSO ou CDN). Je migre d'abord les zones qui n'influencent pas les systèmes externes, je reprends ensuite les enregistrements partagés via un modèle de zone et je teste séparément les chemins critiques. Pour les équipes, je communique une fenêtre de temps claire et je désigne un interlocuteur pour des validations rapides.
Tests, diagnostic et symptômes typiques
- DNSJe vérifie A/AAAA, MX, TXT et CNAME avec dig/nslookup à partir de différents réseaux. Des réponses différentes indiquent une mise en cache ou des zones non reprises.
- HTTP/SJe teste les codes d'état, les redirections et la chaîne de certificats. Une inadéquation de CAA ou une chaîne expirée explique souvent les erreurs TLS.
- Courrier électroniqueJ'envoie des e-mails de test de l'extérieur et de l'intérieur, je contrôle l'évaluation SPF, DKIM=pass et l'alignement DMARC dans l'en-tête. Les rebonds inattendus indiquent généralement des boîtes aux lettres MX incorrectes ou manquantes.
- Sous-domainesJe n'oublie pas les outils internes, les hôtes de staging ou les points finaux de l'API. On oublie facilement SRV/NAPTR pour la VoIP et la messagerie.
Coûts, durées et comptabilité
Je vérifie si, lors du transfert, une Prolongation de la durée de vie (souvent pour les gTLD) et je planifie le budget en conséquence. Je compense les postes ouverts chez l'ancien fournisseur avant le début, afin qu'aucun blocage ne s'applique. Après le changement, je sauvegarde les factures, je mets à jour le mode de paiement et je note les dates de renouvellement afin d'éviter toute surprise ultérieure.
Sécurité et gestion des accès
J'active Authentification à 2 facteurs auprès du nouveau registraire, créer des utilisateurs séparés avec des rôles et consigner les modifications critiques. Je traite le code d'authentification comme un mot de passe et je le supprime une fois terminé. Pour les adresses électroniques d'administration, j'utilise des boîtes aux lettres auxquelles plusieurs personnes responsables ont un accès sécurisé, afin que les partages ne soient pas liés à une seule personne.
En bref
Un déménagement réussi se nourrit de clarté Préparationdes étapes DNS propres et des tests approfondis. Je sécurise d'abord les données, je tiens les contacts à jour et je traite rapidement les e-mails de transfert. Ensuite, je mets en place le DNS, les e-mails et les redirections de manière structurée et je contrôle le tout grâce au monitoring. Les performances, l'assistance et les outils du nouvel hébergeur sont payants au quotidien. En étant discipliné, on tire profit du changement Sécurité et le rythme et reste accessible en ligne.
