Checklist de migration cloud : dépendances, bascule et retour arrière

Une checklist de migration cloud transforme le déplacement d'une application en décisions vérifiables : ce qui migre, les services dont l'application dépend, la cohérence des données, le moment de la bascule et la manière de rétablir le service en cas d'échec. Chaque point de contrôle doit avoir un responsable, une preuve et un motif d'arrêt clair.

Utilisez cette checklist pour une application ou une charge de travail transférée depuis une infrastructure sur site ou un autre fournisseur cloud. Pour déplacer des dossiers entre des comptes de stockage, notre guide du transfert de fichiers de cloud à cloud présente les outils et les vérifications de la copie d'arrivée. Une migration applicative concerne aussi les identités, le réseau, les bases de données, les tâches en arrière-plan et les responsabilités d'exploitation.

1. Définir le périmètre et la stratégie de migration cloud

Notez le nom de l'application, le responsable métier, le responsable technique, les environnements source et cible, ainsi que le résultat attendu. Précisez ce qui reste en place. Un portail client peut migrer alors que son fournisseur d'identité, son service de paiement et sa base de reporting restent hébergés ailleurs.

Choisissez une méthode pour chaque charge de travail. La documentation de Google Cloud distingue le réhébergement avec peu de modifications, l'adaptation à la nouvelle plateforme et la refonte plus profonde de l'application. Déplacer et refondre simultanément élargit le périmètre des tests nécessaires.

Fixer des critères d'acceptation mesurables

Remplacez « fonctionne dans le cloud » par des résultats observables : les parcours utilisateurs désignés réussissent, les données concordent, les temps de réponse respectent un seuil convenu et l'équipe d'exploitation sait rétablir le service. Mesurez le fonctionnement actuel sous une charge représentative pour disposer d'une comparaison utile.

Distinguer la fenêtre de maintenance des objectifs de reprise

AWS définit le RTO et le RPO selon l'interruption et la perte de données acceptables. L'objectif de délai de reprise, ou RTO, précise le temps admissible pour rétablir le service. L'objectif de point de reprise, ou RPO, exprime l'ancienneté maximale acceptable des données récupérées. Ce sont des exigences à tester, pas des garanties apportées par un logiciel de sauvegarde.

Documentez séparément l'interruption prévue pour la migration. Précisez si la bascule doit conserver toutes les transactions dont l'enregistrement a été confirmé, et comment le vérifier. Convenez de ces limites avec les responsables du service avant de choisir la méthode de migration.

2. Cartographier les dépendances avant de définir les vagues

Recensez l'application, les données, l'infrastructure et leurs connexions. La documentation de planification de Google place l'inventaire des charges de travail et de leurs dépendances avant leur regroupement en vagues de migration.

Allez au-delà de la liste des principaux serveurs :

• Fournisseurs d'identité, comptes de service, certificats, clés de chiffrement et emplacements des secrets.
• Noms DNS, règles de pare-feu, adresses IP autorisées, routes privées et appels de services tiers.
• Bases de données, systèmes de fichiers partagés, stockage objet et répertoires locaux contenant des données persistantes.
• Files de messages, tâches planifiées, envoi d'e-mails, traitements de reporting et agents de supervision.
• Licences, systèmes d'exploitation pris en charge, versions des environnements d'exécution et contacts d'assistance externe.

Pour chaque connexion, indiquez son sens, son responsable et le comportement attendu pendant le déplacement. Un service peut démarrer correctement, puis échouer lorsque son traitement nocturne appelle une base oubliée. Regroupez les composants étroitement liés lorsque cela est possible, ou testez la connexion qui reliera les deux environnements.

3. Préparer l'environnement cloud cible

Vérifiez que la destination peut exécuter la charge de travail avant de programmer la bascule en production. Confirmez la disponibilité régionale, les quotas, l'architecture du processeur, la prise en charge du système d'exploitation, le comportement du stockage et les licences requises. Testez la configuration retenue : des ressources portant des noms similaires ne se comportent pas nécessairement de la même manière.

Valider les accès, le réseau et la configuration

Le guide de préparation de Microsoft prévoit des contrôles de compatibilité et des tests d'authentification, de connectivité et de fonctionnement. Incluez un parcours utilisateur courant et les accès entre services.

Vérifiez que l'équipe de migration peut accéder aux systèmes nécessaires sans partager de mots de passe administrateur. Utilisez le dispositif approuvé pour les secrets, contrôlez les noms et dates d'expiration des certificats, puis confirmez que les journaux et les alertes arrivent aux personnes d'astreinte. Conservez les définitions de l'infrastructure et de la configuration testées dans un système de gestion de versions.

Budgéter la période de coexistence

Estimez le coût des deux environnements en parallèle, des transferts, des sauvegardes, des journaux et de l'assistance. Attribuez un responsable et une date de révision à chaque ressource temporaire. Une migration cloud ne prouve pas, à elle seule, une économie : comparez le coût réel après stabilisation au coût de référence.

4. Préparer une migration cohérente des données

Choisissez comment chaque base de données, espace de fichiers et file de messages rejoindra la destination. Une copie complète pendant un arrêt prévu est plus simple qu'une réplication continue, mais elle peut imposer une interruption plus longue. La réplication réduit parfois le transfert final, tout en ajoutant du travail de configuration, de surveillance et de compatibilité.

Précisez où les écritures sont autorisées à chaque étape. Incluez les traitements et intégrations capables de modifier des données lorsque l'application visible par les utilisateurs est en maintenance. Définissez comment les suspendre et vérifier l'état du travail encore en cours.

Vérifier la cohérence entre composants

Un instantané du stockage peut omettre des données encore en mémoire. La documentation des instantanés Amazon EBS précise, par exemple, qu'ils capturent les données écrites sur le volume, ce qui peut exclure les caches de l'application ou du système d'exploitation. Utilisez la procédure de sauvegarde documentée pour la base ou l'application et coordonnez-la avec celle des fichiers associés.

Si une application stocke les documents téléversés séparément de sa base, vérifiez que les enregistrements restaurés renvoient toujours aux bons fichiers. La réussite de deux copies ne prouve pas qu'elles correspondent à un état compatible dans le temps.

Réserver du temps à la validation des données

Comparez les schémas, les nombres d'enregistrements, les contenus pertinents et les totaux métier avec des méthodes adaptées. Un comptage ne détecte pas une valeur modifiée dans une table de même taille. La validation AWS DMS, par exemple, compare les lignes source et cible pour les bases prises en charge et consomme du temps et des ressources supplémentaires.

Documentez les exclusions, les transformations et les écarts non résolus. Le responsable des données doit décider si les preuves permettent de continuer. Conservez une trace du dernier point de synchronisation pour que les contrôles ultérieurs portent sur le même état.

5. Prouver la restauration et préparer le retour arrière

Restaurez une sauvegarde dans un environnement isolé et exécutez les contrôles applicatifs critiques. Notez l'identifiant de la sauvegarde, les accès et clés nécessaires, le temps écoulé et le résultat. Notre guide de la sauvegarde cloud explique la différence entre conserver une copie et disposer d'une procédure de récupération utilisable.

Le plan de retour arrière doit préciser les décideurs, les motifs de déclenchement, les étapes et l'heure limite. Prévoyez le temps nécessaire au retour puis à la vérification du service avant la fin de l'interruption autorisée. Testez l'accès à l'environnement source.

Prévoir les écritures acceptées sur la destination

AWS distingue le retour arrière avant et après l'arrivée de nouvelles données. Dès que les utilisateurs ont écrit sur la destination, la base source peut être obsolète. Rediriger le trafic ne suffit pas à préserver ces changements.

Convenez d'une méthode testée pour réconcilier les modifications, les restaurer ou réparer le nouvel environnement. Précisez quel système fait référence et empêchez les écritures involontaires sur les deux copies. Si la procédure ne peut pas préserver les transactions acceptées dans les limites convenues, corrigez ce manque avant d'autoriser les écritures de production.

6. Répéter toute la procédure de migration

Utilisez un environnement et un volume de données représentatifs pour répéter la séquence, y compris le retour arrière. Mesurez les étapes qui déterminent l'interruption : arrêt des écritures, synchronisation finale, validation, changement de trafic et restauration. Un petit transfert d'essai ne permet pas d'établir la durée d'une migration de production beaucoup plus volumineuse.

Testez la connexion, les droits, une transaction métier complète, les téléversements, les rapports et les traitements en arrière-plan. Vérifiez la charge attendue, les alertes et la première tâche planifiée après la bascule. Empêchez les tests d'envoyer de vrais e-mails aux clients, de déclencher des paiements ou de produire d'autres effets en production.

Transformez la répétition en procédure d'exécution. Chaque étape doit indiquer qui intervient, quoi faire, comment vérifier la réussite et comment réagir en cas d'échec. Faites-la suivre par une autre personne que son auteur pour corriger les ambiguïtés avant la fenêtre de production.

7. Décider explicitement de poursuivre ou de reporter

Le guide de planification de Microsoft recommande des retours arrière testés, des points de contrôle mesurables et une autorité de décision définie. Lors de la revue de préparation, demandez des preuves.

• Périmètre : les responsables de l'application et de ses dépendances ont confirmé ce qui migre.
• Destination : les accès, la connectivité, la supervision et les parcours critiques ont été validés.
• Données : la synchronisation et la validation respectent les critères convenus.
• Reprise : une restauration et le retour arrière applicable ont été répétés.
• Équipe : les opérateurs, le décideur, l'assistance et les moyens de communication sont disponibles.
• Délai : il reste assez de temps pour rétablir puis vérifier le service.

Consignez la décision, les risques restants et les personnes qui les ont acceptés. Une dépendance critique non résolue ou une procédure de reprise non testée doit maintenir la migration en attente.

8. Basculer selon la séquence approuvée

Gelez les déploiements sans rapport avec l'opération, prévenez les contacts convenus et confirmez la version de la procédure. Arrêtez ou contrôlez les écritures source comme prévu, terminez la synchronisation et vérifiez la destination avant d'y envoyer le trafic de production. Le guide d'exécution de Microsoft décrit les méthodes avec arrêt planifié et celles utilisant la réplication.

Tenir compte des caches et des connexions existantes

Une modification DNS ne bascule pas immédiatement tous les clients. Le TTL DNS détermine la durée de mise en cache, et les caches locaux peuvent retarder les changements visibles. Préparez tout ajustement du TTL en amont, tenez compte des enregistrements déjà en cache et observez le trafic reçu par les deux environnements.

Appliquez la politique testée pour les connexions existantes et les traitements en arrière-plan. Confirmez l'emplacement faisant référence pour les écritures avant d'autoriser celles de production, puis répétez les contrôles d'acceptation. Si un critère d'arrêt se présente, le décideur désigné doit appliquer la procédure documentée de retour ou de réparation.

9. Stabiliser l'application et vérifier l'exploitation

Comparez les erreurs, la latence, l'utilisation des ressources, les files de messages, les tâches échouées et les retours utilisateurs au fonctionnement de référence. Confirmez que les sauvegardes couvrent la destination et que sa restauration fonctionne. Attribuez les anomalies à des responsables ; la réussite du routage ne termine pas le travail.

Choisissez une période d'observation adaptée au cycle métier. Un traitement quotidien peut être observé rapidement ; un rapport mensuel nécessite une autre manière de le tester ou de l'observer. Protégez la source, limitez ses accès et désactivez les anciennes écritures pendant la période de retour prévue.

10. Retirer la source après acceptation

Le guide de mise hors service de Microsoft distingue l'acceptation du retrait de l'ancien environnement. Obtenez l'accord du responsable, conservez les documents requis et les sauvegardes récupérables, puis confirmez qu'aucun autre service ne dépend encore de la source.

Retirez ensuite les anciennes routes, les comptes obsolètes, les accès temporaires et les ressources inutiles selon la procédure approuvée. Réexaminez les licences, abonnements, espaces de stockage et alertes pour éviter les dépenses ou notifications liées à des composants abandonnés. Mettez à jour le schéma d'architecture, les consignes d'assistance et la documentation de reprise.

Exemple : migrer une petite application avec une heure limite de retour

Cet exemple de planification est fictif. Il ne décrit ni une migration exécutée ni un benchmark. Prenons un service de rendez-vous comprenant une application web, une base de données, des documents téléversés et un traitement d'envoi de notifications.

Avant la fenêtre d'intervention

L'équipe répète un transfert cohérent de la base et des fichiers, teste la connexion et la création d'un rendez-vous, puis empêche les notifications de test d'atteindre les clients. Elle documente l'arrêt du traitement, l'identification de la dernière transaction validée et la restauration de la source. Le responsable exige de conserver chaque réservation confirmée.

Pendant une maintenance de 60 minutes

Supposons que la répétition impose 25 minutes de retour arrière et 10 minutes de vérification, marge de sécurité de l'équipe comprise. La décision de revenir doit alors être prise au plus tard à la minute 25 : 60 moins 25 moins 10. Ces chiffres illustrent le calcul ; utilisez les durées mesurées pour votre application.

Si la validation des données reste non résolue à cette échéance, le responsable arrête la tentative alors que la destination n'a encore reçu aucune écriture de production. Dès que ces écritures commencent, revenir à la source nécessite la procédure distincte de réconciliation des données déjà répétée. Le délai du premier retour arrière ne peut pas être supposé valable pour cette autre procédure.

Questions sur la checklist de migration cloud

Combien de temps dure une migration cloud ?

Estimez la durée à partir de l'inventaire, des corrections nécessaires, du volume de données, des essais de transfert, des répétitions et de la fenêtre autorisée. La copie des données n'en représente qu'une partie. Utilisez un pilote représentatif pour remplacer les hypothèses par des durées mesurées.

Une migration cloud peut-elle se faire sans interruption ?

Certaines architectures permettent une bascule progressive et une réplication continue, mais l'application, la base, les clients et le routage doivent tous prendre en charge cette méthode. Vérifiez l'objectif d'interruption par des tests. Ne le déduisez pas d'un engagement de disponibilité du fournisseur.

Quand la migration est-elle terminée ?

Lorsque l'application remplit les critères d'acceptation, que l'exploitation sait la surveiller et la restaurer, et que la décision convenue sur le retrait de la source est finalisée. Conservez les preuves avec la procédure pour que la migration suivante bénéficie de ce que l'équipe a appris.