Diagramme de Gantt : migration cloud avec vagues et bascule
Un diagramme de Gantt de migration cloud modifiable : découverte, cartographie des dépendances, zone d'atterrissage construite en parallèle, vagues, répétition de bascule, hypercare et décommissionnement, avec dépendances et jalons.
Qu'est-ce que le processus diagramme de gantt : migration cloud avec vagues et bascule ?
Une migration cloud, ce sont plusieurs projets qui partagent une même échéance. Découverte et planification décident de ce qui bouge et dans quel ordre. La zone d'atterrissage, le réseau, l'identité et la journalisation où atterriront les charges de travail, peut se construire en même temps. Les vagues déplacent ensuite les charges par lots, et l'environnement source ne peut pas être éteint avant que la dernière vague ait tourné un moment en production. Un plan qui les range en une seule séquence en exagère la durée. Un plan qui les traite comme indépendantes cache les points où l'une attend l'autre.
Ce modèle compte quatre phases : Découvrir et planifier, Construire la zone d'atterrissage, Migrer par vagues, et Bascule et retrait. « Découverte des applications et serveurs » est la seule tâche de départ. « Cartographie des dépendances » commence trois jours ouvrés après le début de la découverte, car les premiers constats suffisent pour commencer à tracer les connexions, et « Stratégie de migration par charge » la suit. À partir de là, le plan se scinde. « Plan des vagues et fenêtres de bascule » mène au jalon « Plan de migration approuvé », tandis que « Conception de la zone d'atterrissage » commence dès que la stratégie est connue et se déroule en parallèle du plan des vagues.
Dans la zone d'atterrissage, « Réseau et connectivité » (10 jours ouvrés) et « Identité, sécurité et journalisation » (8) suivent tous deux la conception, et la seconde commence deux jours ouvrés après le début de la conception. « Zone d'atterrissage prête » attend les deux. « Vague 1 : migration pilote » ne peut pas commencer avant que « Plan de migration approuvé » et « Zone d'atterrissage prête » soient atteints, et c'est là que ces plans dérapent le plus souvent : les papiers sont finis et la cible ne l'est pas, ou l'inverse. « Appliquer les leçons du pilote aux procédures » se place entre le pilote et « Vague 2 : charges critiques », et « Vague 3 : charges restantes » commence cinq jours ouvrés après le début de la vague 2, de sorte que la dernière vague chevauche la principale.
Après les vagues, « Tests de performance et de basculement » et la vague 3 doivent tous deux être terminés avant « Répétition finale de la bascule », puis viennent « Fenêtre de bascule », « Hypercare » (10 jours ouvrés) et « Décommissionner les serveurs sources ». « Environnement source retiré » est le jalon de clôture. Toutes les durées sont indicatives. Un parc réel comporte des charges qui ne peuvent pas bouger ensemble, des licences avec leurs propres dates de fin et des gels des changements que ce diagramme ne connaît pas : remplacez donc les durées et le découpage en vagues par les vôtres. Une frise planifie le travail. Elle ne rend pas une migration sûre, sécurisée ou rentable, et ne remplace pas les procédures, les résultats de tests et les approbations que demande votre processus de changement. Côté processus, voir le déploiement à /fr/templates/organigramme-du-processus-de-deploiement-de-logiciels-de-la-conception-a-la-production, la reprise à /fr/templates/organigramme-du-processus-de-reprise-apres-sinistre-systemes-informatiques et le changement à /fr/templates/workflow-de-gestion-des-changements-informatiques-soc-2-cc8-1.
Ce que couvre cet organigramme
Dans ce modèle
- Quatre phases, Découvrir et planifier, Construire la zone d'atterrissage, Migrer par vagues, et Bascule et retrait, avec 19 tâches et trois jalons : « Plan de migration approuvé », « Zone d'atterrissage prête » et « Environnement source retiré ».
- Un chevauchement début à début dans la découverte : « Cartographie des dépendances » commence trois jours ouvrés après le début de « Découverte des applications et serveurs », avant la fin de la découverte.
- Une zone d'atterrissage construite à côté de la planification : « Conception de la zone d'atterrissage » suit « Stratégie de migration par charge » et se déroule en parallèle de « Plan des vagues et fenêtres de bascule », avec « Identité, sécurité et journalisation » qui commence deux jours ouvrés après la conception.
- Une jonction qui conditionne la première vague : « Vague 1 : migration pilote » attend « Plan de migration approuvé » et « Zone d'atterrissage prête », puis « Appliquer les leçons du pilote aux procédures » précède « Vague 2 : charges critiques ».
- Des vagues qui se chevauchent et une fin prudente : « Vague 3 : charges restantes » commence cinq jours ouvrés après le début de la vague 2, et « Décommissionner les serveurs sources » attend les 10 jours d'« Hypercare ».
Quand utiliser ce modèle
- Vous déplacez des serveurs ou des applications vers un fournisseur cloud et devez montrer quand tombent la planification, la zone d'atterrissage, chaque vague et la bascule.
- Vous devez expliquer à un comité de pilotage ou aux responsables d'applications pourquoi la vague 1 ne peut pas commencer avant que la zone d'atterrissage soit prête, quoi que dise le plan.
- On vous demande combien de temps l'environnement source doit rester allumé, par exemple à cause de la date de fin d'un contrat de centre de données ou d'hébergement.
- Vous voulez tester ce qui arrive à la date de retrait si la construction du réseau ou une vague prend plus de temps que prévu.
Le plan, tâche par tâche
Toutes les tâches du diagramme avec leur durée en jours ouvrés et ce qu'elles attendent. Une dépendance est un numéro d'étape ; SS signifie début à début, FF fin à fin et +n un décalage en jours ouvrés.
| # | Tâche | Groupe | Jours ouvrés | Dépend de |
|---|---|---|---|---|
| 1 | Découverte des applications et serveurs | Découvrir et planifier | 8 | |
| 2 | Cartographie des dépendances | Découvrir et planifier | 6 | 1SS+3 |
| 3 | Stratégie de migration par charge | Découvrir et planifier | 4 | 2 |
| 4 | Plan des vagues et fenêtres de bascule | Découvrir et planifier | 4 | 3 |
| 5 | Plan de migration approuvé | Découvrir et planifier | Jalon | 4 |
| 6 | Conception de la zone d'atterrissage | Construire la zone d'atterrissage | 6 | 3 |
| 7 | Réseau et connectivité | Construire la zone d'atterrissage | 10 | 6 |
| 8 | Identité, sécurité et journalisation | Construire la zone d'atterrissage | 8 | 6SS+2 |
| 9 | Zone d'atterrissage prête | Construire la zone d'atterrissage | Jalon | 7, 8 |
| 10 | Vague 1 : migration pilote | Migrer par vagues | 8 | 5, 9 |
| 11 | Appliquer les leçons du pilote aux procédures | Migrer par vagues | 3 | 10 |
| 12 | Vague 2 : charges critiques | Migrer par vagues | 15 | 11 |
| 13 | Vague 3 : charges restantes | Migrer par vagues | 12 | 12SS+5 |
| 14 | Tests de performance et de basculement | Migrer par vagues | 6 | 12 |
| 15 | Répétition finale de la bascule | Bascule et retrait | 2 | 13, 14 |
| 16 | Fenêtre de bascule | Bascule et retrait | 2 | 15 |
| 17 | Hypercare | Bascule et retrait | 10 | 16 |
| 18 | Décommissionner les serveurs sources | Bascule et retrait | 8 | 17 |
| 19 | Environnement source retiré | Bascule et retrait | Jalon | 18 |
Comment cela fonctionne
Remplacez les durées de découverte et de planification
Fixez les durées de « Découverte des applications et serveurs », « Cartographie des dépendances » et « Stratégie de migration par charge » d'après la taille de votre parc. Gardez le lien début à début si le traçage peut commencer avant la fin de la découverte.
Construisez la zone d'atterrissage à côté du plan
Gardez « Conception de la zone d'atterrissage » et « Plan des vagues et fenêtres de bascule » comme tâches parallèles. Ajoutez des tâches pour tout ce dont la cible a besoin, comme les services partagés, et reliez-les à « Zone d'atterrissage prête ».
Conditionnez la vague 1 des deux côtés
« Vague 1 : migration pilote » dépend de « Plan de migration approuvé » et de « Zone d'atterrissage prête ». Allongez la construction du réseau et voyez lequel fixe le début du pilote.
Découpez les vagues selon vos charges
Renommez ou dupliquez les tâches de vague pour vos propres groupes de charges. Utilisez un décalage sur le lien début à début quand une vague suivante peut commencer pendant qu'une précédente est en cours.
Ajoutez bascule, hypercare et décommissionnement
Réglez « Hypercare » sur la durée pendant laquelle vous voulez garder la source comme solution de repli. Comparez la date que donne « Environnement source retiré » avec toute date de fin de contrat ou de licence à respecter.
Ajoutez les responsables, partagez et exportez
Indiquez l'équipe responsable dans Personnes, les références de procédures dans les notes des tâches, partagez le diagramme avec les responsables d'applications et exportez un PDF pour le dossier de changement.
Questions fréquentes
Ce diagramme choisit-il une stratégie de migration pour moi ?
Non. Il planifie le travail. La tâche « Stratégie de migration par charge » est celle où vous décidez, pour chaque charge, de la déplacer telle quelle, de la modifier ou de la remplacer. Le diagramme montre seulement ce qui attend cette décision.
Puis-je planifier autour de la date de fin d'un contrat de centre de données ?
Comparez la date de fin de « Environnement source retiré » avec la date dont vous avez besoin. Si elle est plus tardive, changez une durée ou une dépendance et regardez la date bouger. Un Début fixe sert aux dates réellement fixes, comme un gel des changements, et le diagramme signale celui qui entre en conflit avec une dépendance.
Les jours ouvrés sont-ils de vrais jours calendaires ?
Ce sont des jours du lundi au vendredi. Le diagramme n'a pas de calendrier de jours fériés : ajoutez une tâche ou allongez une durée là où tombe un jour férié ou une période de gel.
En quoi diffère-t-il du diagramme de migration de données ?
Celui-ci déplace des charges et des environnements. Le diagramme de migration de données, à /fr/templates/diagramme-de-gantt-migration-de-donnees, couvre le profilage, la correspondance, les chargements d'essai et le rapprochement des données elles-mêmes. Un grand programme peut utiliser les deux.
Où trouver l'organigramme du même travail ?
Le processus de déploiement à /fr/templates/organigramme-du-processus-de-deploiement-de-logiciels-de-la-conception-a-la-production et celui de reprise à /fr/templates/organigramme-du-processus-de-reprise-apres-sinistre-systemes-informatiques dessinent les décisions et les passations. Pour un plan de programme plus large, voir /fr/templates/diagramme-de-gantt-plan-de-deploiement.
