Planifier vagues de migration cloud et bascule en diagramme de Gantt
Planifiez une migration cloud sur un diagramme de Gantt : cartographiez les dépendances, répartissez les charges en vagues, construisez la zone d'atterrissage en parallèle, répétez la bascule et décommissionnez après l'hypercare.
Le plus difficile dans un planning de migration cloud est de décider ce qui bouge ensemble et ce qu'attend chaque vague. Ce guide montre comment transformer un inventaire de charges en vagues, en zone d'atterrissage, en bascule répétée et en date de retrait.
En bref
- Tracez les dépendances pendant la découverte, pour connaître les charges qui doivent migrer ensemble avant de figer les vagues.
- Traitez la zone d'atterrissage comme un flux à part avec un jalon de disponibilité que la première vague attend.
- Lancez d'abord une vague pilote et mettez une tâche de retour d'expérience entre elle et les vagues plus importantes.
- Chevauchez les vagues suivantes par un lien début à début, mais ne lancez jamais une vague avant que les éléments de sa répétition existent.
- Décommissionnez la source après une période d'hypercare, et vérifiez la date de retrait par rapport aux dates de vos contrats.
De la liste des charges au plan des vagues
Un inventaire de charges est une liste. Un plan de migration est un ordre. La différence, ce sont les dépendances : une application ne peut pas migrer avant la base de données qu'elle appelle, un traitement par lots avant le partage de fichiers où il écrit, et rien ne migre avant que l'endroit où cela va existe. Les équipes qui sautent cette étape se retrouvent avec des vagues qui paraissent nettes sur une diapositive et échouent le premier week-end, parce que la moitié des connexions d'une vague ont été oubliées.
La méthode comporte trois gestes. D'abord, tracez les dépendances pendant que la découverte est encore en cours, pour que les groupes de charges qui doivent migrer ensemble apparaissent tôt. Ensuite, faites de la zone d'atterrissage un flux de travail distinct, avec ses propres tâches et un jalon de disponibilité, plutôt qu'une ligne en haut du plan. Enfin, placez le retrait de l'environnement source derrière une période d'hypercare, pour que la question du moment où l'on peut l'éteindre ait une réponse visible.
Un diagramme de Gantt aide sur ce qu'une liste ne peut pas montrer : quelle date bouge quand une autre bouge. Si la construction du réseau prend quatre jours de plus, la vague pilote se décale, puis chaque vague suivante, puis la date de retrait. Si la découverte révèle une application enchevêtrée, le plan des vagues change avant la zone d'atterrissage. Le diagramme ne dit pas quelle stratégie convient à une charge ni si la cible est sécurisée. Il planifie le travail que vous avez décidé.
L'exemple construit par étapes le modèle de migration cloud. Les durées sont indicatives. Pour le processus plutôt que le planning, voir le déploiement à /fr/templates/organigramme-du-processus-de-deploiement-de-logiciels-de-la-conception-a-la-production et la reprise à /fr/templates/organigramme-du-processus-de-reprise-apres-sinistre-systemes-informatiques.
Un plan de migration cloud, construit par étapes
Dix-neuf tâches en quatre phases. Les durées sont indicatives ; fixez les vôtres. Ouvrez le panneau tableur pour voir les lignes derrière chaque étape.
Découverte, dépendances et plan des vagues
« Découverte des applications et serveurs » dure 8 jours ouvrés. « Cartographie des dépendances » commence trois jours ouvrés après son début : le traçage démarre donc sur les premiers constats. « Stratégie de migration par charge » et « Plan des vagues et fenêtres de bascule » suivent, jusqu'au jalon « Plan de migration approuvé ».
La zone d'atterrissage, construite à côté du plan
« Conception de la zone d'atterrissage » commence dès que la stratégie est connue, et non à l'approbation du plan. « Réseau et connectivité » dure 10 jours ouvrés et « Identité, sécurité et journalisation » 8, avec un début deux jours ouvrés après celui de la conception. « Zone d'atterrissage prête » attend les deux.
D'abord le pilote, puis les vagues plus grandes
« Vague 1 : migration pilote » (8 jours ouvrés) attend « Plan de migration approuvé » et « Zone d'atterrissage prête ». « Appliquer les leçons du pilote aux procédures » la suit, puis « Vague 2 : charges critiques » (15). « Vague 3 : charges restantes » commence cinq jours ouvrés après le début de la vague 2, et « Tests de performance et de basculement » suit la vague 2.
Répéter, basculer, puis retirer
« Répétition finale de la bascule » attend la vague 3 et les tests. La « Fenêtre de bascule » dure 2 jours ouvrés, « Hypercare » 10, et « Décommissionner les serveurs sources » (8) la suit, jusqu'au jalon « Environnement source retiré ».
Comment cela fonctionne
Commencez la cartographie avant la fin de la découverte
Ajoutez « Cartographie des dépendances » comme tâche à part et reliez-la en début à début avec la découverte, par exemple 1SS+3. Les premiers constats suffisent pour commencer, et les groupes qui doivent migrer ensemble apparaissent des semaines plus tôt.
Faites de la zone d'atterrissage un flux avec un jalon
Donnez à la conception de la zone, au réseau et à l'identité leurs propres tâches, réunissez-les dans un jalon de durée 0, et faites-en dépendre la première vague, en plus du plan approuvé.
Dimensionnez les vagues par groupes de dépendances
Mettez dans la même vague les charges qui dépendent les unes des autres. Donnez une tâche à chaque vague et servez-vous du champ Groupe pour garder vagues, zone d'atterrissage et bascule dans des bandes séparées.
Lancez un pilote et planifiez ce que vous changerez
Faites une petite vague 1, et ajoutez après elle une tâche pour les changements de procédures et d'outillage. Les vagues suivantes dépendent de cette tâche, de sorte que son temps apparaît dans les dates.
Chevauchez les vagues avec un décalage
Quand une vague suivante peut commencer pendant qu'une précédente tourne, utilisez un lien début à début avec un décalage, comme 12SS+5. Vérifiez que les personnes et la capacité de la cible sont là, car le diagramme ne les contrôle pas.
Placez le retrait derrière l'hypercare
Ajoutez l'hypercare comme tâche dont la durée correspond au temps pendant lequel vous voulez garder la source comme solution de repli, et faites suivre le décommissionnement. Comparez la date de fin avec la date dont vous avez besoin.
Erreurs à éviter
Lancer le pilote quand les papiers sont prêts
Un plan signé n'est pas une cible prête. Si la vague 1 ne dépend que de l'approbation, une construction de réseau en retard surprend tout le monde. Faites attendre à la première vague à la fois le plan et la zone d'atterrissage.
Des vagues découpées par équipe plutôt que par dépendance
Déplacer le même jour tout ce qui appartient à une équipe sépare souvent une application de sa base de données. Découpez selon ce qui communique avec quoi, et vérifiez les groupes avec la cartographie des dépendances.
Éteindre la source à la bascule
Si le décommissionnement commence à la bascule, le repli prend fin avant que les problèmes aient pu apparaître. Gardez l'hypercare entre les deux et donnez-lui une vraie durée.
Prendre le plan pour un registre de décisions
Le diagramme montre quand le travail est censé avoir lieu. Les choix de stratégie, les revues de sécurité et les résultats de tests relèvent de vos propres enregistrements et de votre processus de changement, avec une référence dans les notes des tâches.
Ouvrir le diagramme de Gantt de migration cloud
Ouvrez le modèle de migration cloud, adaptez la durée des vagues aux vôtres et voyez bouger la date de retrait.
Guides associés
Questions fréquentes
Combien de vagues une migration doit-elle comporter ?
Cela dépend du nombre de charges et de leurs dépendances mutuelles. Le modèle en utilise trois à titre d'illustration. Ajoutez ou retirez des tâches de vague selon vos groupes.
Puis-je planifier autour d'une date de sortie d'un centre de données ?
Comparez la date de fin du jalon de retrait avec la date dont vous avez besoin. Si elle est plus tardive, changez une durée ou une dépendance. N'utilisez un Début fixe que pour les dates réellement fixes, comme un gel ; le diagramme signale un début fixe qui entre en conflit avec une dépendance.
Le diagramme suit-il les coûts ou la capacité ?
Non. QueryChart planifie des tâches, des dépendances et l'avancement. Il ne suit ni les coûts, ni l'effort, ni la charge des ressources : gardez-les dans l'outil que vous utilisez déjà.
Puis-je coller ma liste de charges dans le diagramme ?
Oui. Copiez des lignes depuis Excel, Sheets ou un CSV et collez-les dans le tableur. Si la première ligne nomme des colonnes comme Tâche (Task), Durée (Duration) et Dépend de (Depends on), chaque colonne est reconnue par son nom ; les noms anglais sont aussi acceptés.
Où voir quelles tâches fixent la date de fin ?
Activez Affichage, puis Chemin critique, pour mettre en évidence l'enchaînement de tâches qui fixe la date de fin. Voir /fr/guides/chemin-critique-diagramme-de-gantt pour le lire.
