Migrez votre hébergement avec une bascule testée et un plan de retour arrière réaliste
Une migration d'hébergement déplace un système en fonctionnement, pas seulement un dossier. La difficulté consiste à préserver la cohérence des données alors que les utilisateurs, les traitements en arrière-plan et les réponses mises en cache par DNS peuvent encore aboutir à des endroits différents. Un plan de bascule clair rend cette transition vérifiable.
L'essentiel à retenir
Préparez et testez la destination, définissez quel système peut accepter des écritures, basculez le trafic de manière délibérée et convenez de la limite de données qui rend un retour arrière sûr.
Rédigez le brief de migration avant de copier les données
Inventoriez la version applicative, la base de données, les fichiers téléversés, les secrets, les tâches planifiées, le courrier, le DNS et les intégrations externes. Incluez les consommateurs de files d'attente et les callbacks des services de paiement ou d'identité. Identifiez la personne autorisée à modifier chaque composant. Une copie de site réussie peut malgré tout échouer si un traitement en arrière-plan continue de s'exécuter sur l'ancien hôte ou si un webhook est livré à un point de terminaison retiré.
Définissez les critères d'acceptation en termes simples pour l'utilisateur : un client peut se connecter, consulter un enregistrement représentatif, téléverser un fichier et effectuer une transaction synthétique à l'aide d'intégrations de test approuvées. Ajoutez les exigences administratives telles que les sauvegardes, la supervision et les tâches planifiées. Consignez la fenêtre de maintenance prévue et le dernier moment auquel l'équipe doit décider de poursuivre ou de revenir en arrière.
Confirmez les ressources de la destination et la région d'hébergement choisie avant de planifier le déplacement. Prévoyez un espace temporaire pour les archives, les imports de base de données et l'ensemble de travail de l'application. Si l'assistance à la migration concerne le service acheté, demandez au support de confirmer son périmètre exact et ses dépendances. Ne supposez pas que l'enregistrement de domaine, toutes les boîtes aux lettres et l'ensemble des paramètres tiers sont déplacés avec une commande d'hébergement.
Validez la destination sans modifier le trafic public
Créez la destination avec les versions logicielles et applicatives prévues. Restaurez une copie de répétition selon la même méthode que celle prévue pour le transfert final. Testez avec le nom d'hôte applicatif réel via une substitution locale contrôlée ou un environnement de préproduction approuvé, afin d'exercer le routage des hôtes et le comportement des certificats HTTPS. Consulter une adresse IP seule ne prouve pas que le nom d'hôte de production fonctionnera.
Maintenez la répétition isolée des effets de bord en production. Désactivez l'envoi d'e-mails de production, les actions de paiement réelles, les webhooks sortants et les tâches planifiées jusqu'à ce que leur comportement ait été examiné. Vérifiez les permissions du système de fichiers, la gestion des téléversements, la connectivité à la base de données et les routes applicatives requises. Pour WordPress, faites attention aux URL de site stockées et au comportement des extensions ; remplacer du texte arbitraire dans la base de données peut endommager des valeurs sérialisées.
Effectuez une répétition de restauration et relevez la durée écoulée. Un premier test nécessitant deux heures d'import de données ne peut pas tenir dans une fenêtre finale de quinze minutes non expliquée. Décidez si l'application a besoin d'une période de maintenance plus longue, d'un transfert incrémental pris en charge ou d'une conception différente. Le plan de migration doit refléter le travail mesuré plutôt que de considérer le changement de DNS public comme l'ensemble du projet.
Faites d'un seul système l'autorité pour les écritures
| Phase | Autorité d'écriture | Preuve requise |
|---|---|---|
| Préparation | Service de production existant | La destination réussit les contrôles de répétition isolée |
| Synchronisation finale | Écritures suspendues ou contrôlées par la conception de la migration | La base de données, les téléversements et les files d'attente atteignent une limite consignée |
| Vérification de la bascule | Destination uniquement après acceptation | Les requêtes et intégrations atteignent le service prévu |
| Retour arrière après de nouvelles écritures | Choisi après planification de la réconciliation | Les changements récents acceptés ne seront pas écartés silencieusement |
Pour une application modeste, un intervalle de maintenance ou de lecture seule planifié peut fournir une limite de données finale claire. Arrêtez ou suspendez les écritures concernées, y compris les traitements en arrière-plan et les tâches d'import, puis capturez l'état cohérent final de la base de données et des fichiers. Consignez les files d'attente ou événements externes qui restent à traiter. Une page de maintenance qui bloque les navigateurs mais laisse les traitements en arrière-plan actifs ne constitue pas un gel complet des écritures.
Une conception reposant sur la réplication continue de base de données exige sa propre procédure de basculement prise en charge et une validation minutieuse. N'improvisez pas de synchronisation bidirectionnelle à l'approche d'une échéance. Deux copies applicatives accessibles en écriture de manière indépendante peuvent produire des commandes, des identifiants ou des téléversements contradictoires. Choisissez la méthode de migration que l'équipe a répétée et peut expliquer, même si cela impose une période de maintenance plus visible.
Basculez le trafic selon une séquence courte et observable
Préparez les changements DNS à l'avance. Si vous réduisez la durée de vie du cache (TTL) d'un enregistrement DNS, faites-le suffisamment tôt pour que les réponses précédemment mises en cache avec l'ancienne durée de vie expirent. Une valeur plus faible saisie à la dernière minute ne raccourcit pas les réponses déjà détenues ailleurs. Gardez les anciens et nouveaux points de terminaison contrôlés pendant le chevauchement ; modifier DNS ne transfère pas instantanément toutes les connexions client actives.
- Confirmez la frontière de données finale et la version applicative de destination.
- Vérifiez HTTPS, les routes importantes et la politique d'écriture prévue sur la destination.
- Ne modifiez que les enregistrements de trafic prévus et consignez leurs valeurs précédentes.
- Comparez les réponses faisant autorité du DNS avec plusieurs résolutions récursives indépendantes.
- Vérifiez des parcours utilisateurs représentatifs et observez les erreurs, la latence et le trafic sur les deux hôtes.
- Activez chaque worker ou tâche planifiée approuvé exactement une fois, sur son hôte désigné.
Par exemple, une équipe suspend les écritures à 21:00, termine la synchronisation finale à 21:15 et modifie les enregistrements web à 21:20. Elle vérifie la destination avant de rouvrir les écritures à 21:30. Ces horaires constituent une séquence illustrative, pas une durée standard. L'élément important est le moment où les nouvelles modifications client sont acceptées pour la première fois sur la destination.
Traitez le retour arrière comme une décision sur les données, puis retirez l'ancien service avec soin
Avant que la destination n'accepte de nouvelles écritures, ramener le trafic vers un ancien service encore cohérent peut être relativement simple. Ensuite, rebasculer DNS seul risque d'abandonner des changements acceptés. Décidez si la destination peut être réparée plus rapidement, ou si ses nouvelles données doivent d'abord être réconciliées dans l'ancien système. Maintenez le gel des écritures jusqu'à ce que l'autorité de retour arrière et la frontière de données choisies soient claires.
Maintenez l'ancien service selon un plan de conservation délibéré plutôt que de l'annuler dès qu'un navigateur fonctionne. Confirmez que le trafic résiduel, les dépendances de messagerie et les callbacks ne reposent plus sur lui. Vérifiez une sauvegarde récente du nouveau service de production et effectuez un contrôle opérationnel final. Archivez le compte rendu de migration afin qu'un incident ultérieur ne dépende pas de la mémoire de quelqu'un pour savoir quel serveur exécute encore une tâche planifiée.
