AWS propose une approche en trois phases dans le cadre d’un programme d’accélération de la migration (MAP) :
- Évaluer
- Mobiliser
- Migrer et moderniser
Assessment (évaluation de la capacité à effectuer une migration)
Cette phase d’inventaire et d’analyse de la situation existante dure de 1 à 3 mois, et les questions suivantes doivent être traitées en priorité :
- Identifier le TCO (Total cost of ownership) sur AWS (généralement, Migration Evaluator est utilisé) et confirmer qu’il répond aux conditions d’accès au MAP.
- Confirmer le budget et les ressources humaines pour effectuer la migration.
- Identifier le projet nécessaire avant la migration, via une évaluation de l’état de préparation à la migration (MRA). Il s’agit ici d’évaluer la capacité à effectuer la migration selon les critères suivants :
- La capacité de la plateforme cloud (Landing Zone) à héberger des applications à grande échelle
- La capacité des solutions et des processus de sécurité à fournir les niveaux de sécurité attendus pour l’ensemble du portefeuille et à fonctionner à l’échelle
- La capacité à assurer la gestion financière du cloud pour un grand nombre d’applications et de comptes AWS
- Les compétences des équipes pour réaliser les activités de migration et d’exploitation du cloud.
- L’organisation et la gouvernance du cloud pour prendre les bonnes décisions sur un grand volume d’applications
- Le niveau de contrôle du portefeuille d’applications
- La capacité à gérer des programmes complexes
4. Confirmation du sponsoring
C’est également le moment de définir la phase de mobilisation en termes de ressources (internes et externes), de gestion, de budget et de durée avec des étapes clés, et d’établir des contrats avec des fournisseurs externes.
Mobiliser (mobilisation des ressources pour la migration vers le cloud)
Cette phase dure généralement de 3 à 9 mois.
Elle permet de combler les lacunes identifiées lors de l’évaluation de l’état de préparation à la migration, de s’exercer sur quelques applications pilotes (3 à 5) et de mobiliser les équipes qui participeront au programme de migration.
Dans le cas des priorités évoquées ci-dessus, il y a donc des travaux à réaliser qui n’ont pas été considérés comme aboutis. Il y a aussi :
- Un projet spécifique sur l’analyse détaillée du portefeuille d’applications afin d’identifier le périmètre de la migration, le plan de migration pour chaque application et le calendrier de migration.
- Un projet sur la mise en place de la méthodologie, de l’organisation, des outils, des KPI et de la gouvernance nécessaires à la phase de migration avec la contractualisation associée.
- Un projet sur le modèle opérationnel cible (TOM)
- Un projet spécifique sur la progression des compétences, la mise en œuvre du community building et la conception du plan de communication.
- Un projet pour gérer l’ensemble de ces sujets et notamment les nombreuses dépendances entre eux.
Migration et Modernisation
En réalité, la phase de migration à grande échelle se déroule sur une période de 1 à 3 ans, au cours de laquelle la planification est réalisée en appliquant la méthodologie et la gouvernance préparées dans la phase de Mobilisation. Migrer un portefeuille de 200 applications, c’est gérer 200 projets en parallèle, de complexités différentes, avec des équipes différentes. Ces migrations reposent sur 4 piliers organisationnels majeurs :
- Les équipes de développement qui, idéalement en mode DevOps, assurent l’ensemble des activités de développement, de test et d’exploitation de l’application et dont le propriétaire de l’application gère l’ensemble du cycle de migration ( » accountable » de la migration).
- La « Migration Factory » qui accompagnera les équipes de développement dans les migrations à plusieurs niveaux :
Garant de la méthodologie de migration des modèles et des outils associés (qui industrialise les activités de migration dès que possible)
- Gestionnaire de programme pour fournir une vue consolidée de la planification, du budget et de la portée de la migration
- Architectes AWS pour soutenir les équipes de développement qui élaborent les conceptions sur AWS
- Garant du budget global en consolidant toutes les informations sur les coûts associés à la migration et en détectant les dérives
- Experts sur les technologies de migration (outils de migration de données, outils de migration de VM, outils de migration de grands espaces de stockage, etc.) et le mécanisme de déclenchement des crédits fournis par AWS.
- Développement d’outils de découverte automatisés – Développement et enrichissement du cockpit de migration (panneaux de contrôle qui permettront de gérer la migration à l’échelle)
- Modérer la communauté de migration
3. Le CCOE (Cloud Centre of Excellence) qui gère la plateforme cloud et la configuration pour répondre aux besoins des différentes applications et business owners à migrer.
- Les entités complémentaires de services technologiques partagés qui gèrent :
- la sécurité informatique
- l’infrastructure du réseau
- Les outils de construction et d’exploitation
- Les services d’infrastructure transversaux (DNS, NTP, AD, transferts de fichiers, gestion des correctifs et des images système, etc. L’efficacité du modèle de collaboration entre ces piliers est un gage majeur de la réussite du projet de migration. Le modèle de gouvernance et la capacité à renforcer les équipes, à déclencher des alertes dans un cycle court et à impliquer des expertises complémentaires est un autre ingrédient du succès.
Exécution de la migration
Le cycle de migration est un cycle applicatif standard qui doit capitaliser le plus possible sur les pratiques de gestion des versions des différentes usines de développement. Il est basé sur les phases suivantes :
Discover : Au cours de cette phase, le propriétaire de l’application présente aux membres de l’usine de migration qui supporteront la migration :
- les enjeux métiers associés à l’application, la conception de l’application existante,
- les différents flux entrants et sortants
- les contrats de service
- les différents environnements et leurs rôles
- les capacités utilisées
- les variations du niveau d’utilisation au cours d’une journée, d’une semaine et d’une année types
- et les différents acteurs impliqués dans l’application. Cette phase peut être accélérée par l’utilisation d’outils de découverte automatisés basés sur l’exploitation de données techniques structurées (règles de pare-feu, liens backend-frontend dans les load balancers, fichiers de configuration de l’infrastructure, fichiers de configuration de l’application, enregistrements DNS, etc.)
Design / Conception : au cours de cette phase, la conception de l’application une fois migrée sur AWS est développée en fonction du type de modèle de migration envisagé (Rehost, Rebuild, Replatform, Refactor – voir le chapitre « Transformation de l’application »).
Refacto Replatform : validation de la conception et évaluation financière pour vérifier la conformité avec l’analyse de rentabilité et définir le budget qui sera mis en œuvre.
Mise en œuvre et déploiement : il s’agit de déployer l’infrastructure des environnements sur la base de l’infrastructure en tant que code, et de transformer l’application pour tirer le meilleur parti du nuage et des tests.
Pre-cutover : durant cette phase, les capacités et les performances de l’application sur AWS sont validées, les outils d’exploitation sont intégrés et les instructions d’exploitation sont adaptées. Ensuite, l’opérabilité est validée, les flux inter-applicatifs (internes et externes) sont testés, l’acceptation du propriétaire du service est obtenue, et le plan détaillé de la bascule avec le plan de retour en arrière associé est défini.
Cutover : transfert des flux de données inter-utilisateurs et inter-applications vers les instances déployées sur AWS. Au cours de cette phase, la montée en charge et le comportement corrects doivent être validés à l’aide de taux d’erreur et de performances standard.
Post-cutover : phase d’observation au cours de laquelle le fonctionnement des applications est contrôlé. À la fin de cette phase, la décision est prise de ne pas revenir à l’instance d’origine.
Decommisionning : il s’agit des opérations de mise hors service de l’application d’origine et de tous les paramètres associés. Cette phase peut inclure la destruction des données conformément aux instructions de sécurité et la récupération des équipements par un broker.
Assessment : basé sur un modèle agile rétrospectif, il permet d’identifier les pratiques à conserver, à améliorer ou à abandonner ainsi que les nouvelles pratiques à adopter. Un échange global permet de bénéficier des meilleures pratiques.
