Plan de projet de migration vers le cloud

Ce que contient le modèle

Une migration cloud n’est pas un projet unique : c’est un socle à construire, puis une vague qui se répète. Le modèle sépare les deux pour que le socle soit terminé avant que les vagues n’en dépendent :

• Inventaire et évaluation — Inventaire applicatif, cartographie des dépendances, criticité métier et choix de trajectoire par application selon les 7R — rehost, replatform, refactor, repurchase, relocate, retire, retain. Jalon : trajectoires arbitrées.
• Socle cloud (landing zone) — Comptes et abonnements, réseau et connectivité, identités, garde-fous de sécurité, journalisation et modèle de coûts. Tout l’aval en dépend. Jalon : socle en service.
• Découpage en vagues et pilote — Regroupement des applications par dépendance plutôt que par direction, puis validation du mode opératoire sur une vague pilote à faible risque.
• Vagues de migration — Cycles répétés de construction, migration, tests et bascule par vague. Le schéma est identique à chaque fois ; seul le profil de risque change.
• Bascule et hypercare — Bascules en production, bascule DNS et du trafic, fenêtres de retour arrière et période de support renforcé après chaque vague. Jalon : bascule de production terminée.
• Décommissionnement et optimisation — Extinction du parc source, sortie du centre de données ou du contrat d’hébergement, puis redimensionnement et engagements de capacité réservée. C’est là que le retour sur investissement se concrétise vraiment.

Comment l’adapter

1. Fixer d’abord la date de sortie du centre de données ou du contrat d’hébergement et travailler à rebours : cette date est en général contractuelle et non négociable.
2. Ajouter une ligne par application une fois l’inventaire terminé, regroupée sous la vague qui la porte.
3. Dupliquer la phase de vague autant de fois que nécessaire : sa structure interne reste identique.
4. Sortir les candidats au refactoring du plan de vagues : ce sont des projets de développement, pas des migrations, et les mélanger casse le rythme des vagues.
5. Marquer en jalons la mise en service du socle, la fin du pilote, chaque bascule de production et le décommissionnement de la source.

Conseils de planification

• Ne lancez pas les vagues avant que le socle soit terminé. Migrer vers une fondation encore mouvante oblige à remigrer, et c’est la première source de reprise sur ces programmes.
• Groupez les vagues par dépendance, pas par service. Les applications qui se parlent doivent bouger ensemble, sinon vous paierez la latence entre deux parcs pendant toute la séparation.
• Faites une vraie vague pilote. Son but est de valider le mode opératoire et de faire sortir les surprises : choisissez des applications peu risquées mais réellement représentatives, pas les trois plus faciles.
• Budgétez le fonctionnement en parallèle. Les deux parcs tournent en même temps pendant toute la migration ; ce coût de recouvrement est réel et doit figurer dans le dossier dès le départ.
• Prévoyez une fenêtre de retour arrière à chaque bascule. Une bascule sans retour arrière documenté et répété est une porte à sens unique franchie sans l’avoir décidé.

Modèles associés

• Planning de déploiement d’un ERP
• Modèle de diagramme de Gantt pour un projet logiciel
• Planning de construction d’un centre de données
• Voir tous les modèles de diagramme de Gantt

Ce modèle est en français. Les pages associées non encore traduites s’ouvrent en anglais.

Questions fréquentes