La liste de contrôle de migration AWS : tout ce qui doit être répondu avant le jour de la bascule

Si votre équipe s’apprête à déplacer des charges de travail vers AWS, cette liste de contrôle vous aide à décider si vous êtes prêts pour la bascule. La bascule, c’est la fenêtre pendant laquelle les utilisateurs passent des anciens serveurs aux nouveaux. Chaque élément est une question qui exige une réponse écrite et vérifiée avant que quelqu’un réserve cette fenêtre.

Quand une bascule tourne mal, le problème vient rarement des serveurs eux-mêmes. Il vient plus souvent du DNS, du retour arrière, des licences logicielles ou de la personne à réveiller à 3 h du matin si quelque chose lâche. La liste est regroupée en six blocs, et les éléments les plus souvent oubliés reçoivent la formulation la plus ferme.

Ce que vous décidez

Le jour de la bascule est un pari : que tout ce dont la charge de travail dépend a été identifié, déménagé ou rebranché, et testé. La liste de contrôle existe pour réduire le pari. Chaque élément sans réponse est un risque que vous acceptez en silence; la discipline consiste à rendre chaque acceptation explicite. Deux propriétés distinguent une vraie liste de contrôle du théâtre. Un : les réponses sont écrites — « Dave connaît les règles de pare-feu » n’est pas une réponse, parce que Dave est dans un avion le jour de la bascule. Deux : les réponses sont vérifiées — « les sauvegardes sont configurées » et « on a restauré un fichier de sauvegarde mardi » sont deux affirmations différentes, et seule la deuxième compte.

La liste ci-dessous est regroupée en six blocs. Une charge de travail est prête pour la bascule quand chaque bloc est au vert pour cette charge — pas quand l’échéancier du projet le dit.

Quoi vérifier en premier

Si vous n’avez qu’une heure, ces cinq questions prédisent l’état de préparation mieux que tout le reste :

Pouvez-vous nommer le déclencheur de retour arrière? La condition précise et l’heure à laquelle vous abandonnez la bascule et revenez en arrière.
Une instance de test de la charge a-t-elle été lancée et validée dans AWS? Pas « la réplication est au vert » — réellement démarrée, avec une session ouverte, et exercée.
Connaissez-vous chaque enregistrement DNS à changer, et son TTL actuel? Un TTL de 24 heures découvert le soir de la bascule ajoute une journée à votre panne.
Quelqu’un a-t-il restauré une sauvegarde dans le nouvel environnement? Restaurer, pas configurer.
Qui est de garde pendant les premières 72 heures, et ses accès fonctionnent-ils? Identifiants testés, MFA inscrit, VPN fonctionnel — avant l’ouverture de la fenêtre.

Comment vérifier

Vérifiez les affirmations avec des commandes plutôt qu’en acceptant le vert des rapports d’avancement. Un échantillon par bloc :

# Réseau : le chemin site à site est-il vraiment actif?
aws ec2 describe-vpn-connections \
  --query 'VpnConnections[].[VpnConnectionId,State,VgwTelemetry[].Status]'

# DNS : quel est le vrai TTL des enregistrements à déplacer?
dig +noall +answer app.example.com

# Réplication : chaque serveur de la vague est-il à jour?
aws mgn describe-source-servers \
  --query 'items[].[sourceServerID,dataReplicationInfo.dataReplicationState]' \
  --output table

# Sauvegardes : une tâche de restauration a-t-elle déjà roulé pour vrai?
aws backup list-restore-jobs \
  --query 'RestoreJobs[].[CreationDate,Status,CreatedResourceArn]' --output table

# Surveillance : les alarmes existent-elles et pointent-elles vers un sujet abonné?
aws cloudwatch describe-alarms \
  --query 'MetricAlarms[].[AlarmName,StateValue,AlarmActions[0]]' --output table

Dans la console, Application Migration Service > Source servers devrait montrer toute la vague à Ready for cutover, et Backup > Jobs > Restore jobs devrait contenir au moins une entrée réussie qu’un humain a lancée volontairement.

La démarche

Inventaire et dépendances. Chaque serveur, application, base de données, tâche planifiée et intégration de la vague est listé avec un responsable. Les dépendances sont cartographiées dans les deux sens — ce dont cette charge a besoin, et ce qui a besoin d’elle. Tout ce qui est découvert pendant la bascule s’ajoute rétroactivement à cette liste, avec une note expliquant pourquoi c’était manqué.
Réseau et DNS. La connectivité entre le bureau/les utilisateurs et AWS est active et mesurée. Les groupes de sécurité sont écrits et révisés. Chaque enregistrement DNS qui change est listé avec TTL actuel, valeur cible et responsable du changement; les TTL sont abaissés au moins 48 heures d’avance. Les IP codées en dur ont été traquées ou documentées comme risque accepté.
Identité et accès. L’authentification fonctionne dans l’environnement cible et a été testée par une vraie ouverture de session. Les comptes de service, clés d’API et certificats utilisés par la charge sont inventoriés et valides dans AWS. Les accès de l’équipe de garde sont vérifiés. Les licences sont confirmées pour le nouvel environnement — certaines licences de fournisseurs sont liées à des empreintes matérielles ou à des cœurs et deviennent invalides sur une nouvelle infrastructure.
Données et sauvegardes. La réplication ou l’amorçage des données est complet et à jour, avec un écart mesuré, pas supposé. Un plan de sauvegarde existe dans AWS, a roulé, et une restauration a été effectuée et validée. La rétention respecte l’obligation de conformité applicable. Pour les bases de données, l’histoire de récupération à un point dans le temps est comprise — voyez la stratégie PITR et instantanés pour ce qui est attendu sur RDS.
Plan de bascule et retour arrière. Une séquence écrite minute par minute avec des responsables nommés, un point de décision, des étapes de validation qu’un non-expert pourrait exécuter, et un déclencheur de retour arrière explicite (« si la validation n’a pas passé à 2 h, on revient en arrière »). Le retour arrière lui-même a été pensé mécaniquement : ce qui est repointé, ce qui est redémarré, quelle réconciliation de données est requise si des écritures ont eu lieu dans AWS.
Opérations du jour deux. La surveillance et les alarmes existent avant la mise en service — une base comme l’ensemble d’alarmes CloudWatch est le plancher. La responsabilité des correctifs est assignée. L’estimation des coûts est écrite pour pouvoir comparer la première facture. Quelqu’un possède l’environnement nommément, et la revue du premier mois est déjà au calendrier.

Quand c’est la mauvaise approche

Une liste aussi lourde est de trop pour une charge jetable — un environnement de développement ou un service sans état reconstructible en une heure n’a pas besoin d’une cérémonie de retour arrière. C’est aussi le mauvais outil quand le vrai problème est en amont : si l’inventaire lui-même est de la fiction, aucune liste de bascule ne vous sauve, et le geste honnête est d’arrêter de réserver des fenêtres et de retourner en découverte. Les listes de contrôle vérifient l’état de préparation; elles ne le créent pas.

Erreurs fréquentes

Le vert par affirmation. Des éléments marqués complets parce que quelqu’un l’a dit, sans commande, capture d’écran ou test pour appuyer l’affirmation.
Un plan de retour arrière jamais parcouru. Le retour arrière est une procédure avec des étapes, un minutage et ses propres problèmes de données — pas une phrase qui dit « on reviendra en arrière ».
Tester seulement depuis l’intérieur d’AWS. La charge fonctionne d’instance à instance et échoue depuis le bureau, parce que personne n’a testé le chemin que les utilisateurs empruntent vraiment.
Geler la liste au lancement. Les parcs changent pendant un projet de plusieurs mois; une liste qui ignore le nouveau serveur monté à la semaine six audite le passé.

Garder le contrôle

Gardez la liste dans un seul document partagé avec un statut, un responsable et un lien de preuve par élément — des preuves, pas des adjectifs.
Révisez-la en groupe 72 heures avant la fenêtre; tout élément rouge ou sans preuve déclenche une conversation de report, pas un espoir.
Réexécutez les commandes de vérification le matin de la bascule; les états de réplication et la santé des tunnels peuvent changer en une semaine.
Après chaque vague, tenez une rétrospective de 30 minutes et amendez la liste avec ce qui a été manqué — la liste devrait être plus intelligente à la vague trois.
Archivez la liste complétée par vague; c’est la trace d’audit quand quelqu’un demande dans six mois pourquoi une décision a été prise.

Une bascule qui suit une liste de contrôle entièrement documentée est plate, et plate est l’objectif. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.