Tâche 1 : Réalisation de la découverte initiale et validation de la stratégie de migration - AWS Conseils prescriptifs
Étape 1 : valider les données de découverteÉtape 2 : Identifier les moteurs commerciaux et techniquesÉtape 3 : Valider les stratégies de migrationÉtape 4 : Valider les modèles de migrationCritères de sortie des tâches

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Tâche 1 : Réalisation de la découverte initiale et validation de la stratégie de migration

La première étape de l'évaluation du portefeuille dans le cadre d'un projet de migration de grande envergure consiste à comprendre les informations dont vous disposez aujourd'hui, les facteurs commerciaux et techniques, ainsi que toutes les décisions relatives à la stratégie de migration qui ont déjà été prises. Le résultat de l'évaluation du portefeuille est d'intégrer en permanence les métadonnées de migration, le plan de vague et les stratégies de migration dans le flux de travail de migration. Sur la base des informations collectées, vous analysez les lacunes et décidez des prochaines étapes. Vous pouvez ignorer certaines sections de ce manuel si vous avez déjà terminé l'analyse et les tâches. Cette tâche comprend les étapes suivantes :

Étape 1 : valider les données de découverte

Au cours de la phase de mobilisation, vous avez peut-être terminé l'évaluation initiale de votre portefeuille et, dans l'affirmative, vous pouvez réutiliser ces données de découverte lors de la phase de migration. Si ce n'est pas le cas, ne vous inquiétez pas. Ce manuel vous expliquera ce qui est nécessaire pour prendre en charge votre migration de grande envergure.

Les grandes migrations contiennent généralement beaucoup de données. Par exemple, vous avez :

  • Métadonnées relatives aux serveurs sources, aux applications et aux bases de données

  • Informations sur votre portefeuille informatique issues de votre base de données de gestion des configurations (CMDB)

  • Des données issues d'outils de découverte qui vous aident à mieux comprendre l'état actuel et les dépendances

  • Métadonnées pour les AWS ressources cibles

À propos des types de métadonnées

Les trois principaux types de métadonnées nécessaires pour prendre en charge une migration de grande envergure sont les suivants :

  • Métadonnées du portefeuille source : les métadonnées du portefeuille source sont les métadonnées relatives à vos serveurs, applications et bases de données source. Vous pouvez obtenir les métadonnées auprès d'une CMDB existante, d'outils de découverte ou même auprès du propriétaire de l'application. Vous trouverez une liste complète de ce type de métadonnées ici, dont voici quelques exemples :

    • Server name

    • Adresse IP du serveur

    • Système d'exploitation (OS) du serveur

    • Stockage sur le serveur, processeur, mémoire et opérations d'entrée/sortie par seconde (IOPS)

    • Nom de l'application

    • Propriétaire de l'application

    • pplication-to-application Dépendances A.

    • Unité commerciale

    • Une pplication-to-server cartographie

    • Une pplication-to-database cartographie

    • Type et taille de base de données

    • Type et taille de stockage

    • Métadonnées relatives aux dépendances

    • Données de performance et d'utilisation

  • Métadonnées de l'environnement cible : il s'agit d'un type de métadonnées qui vous permet de migrer les serveurs vers l'environnement cible. Vous devez prendre des décisions concernant l'environnement cible. Vous pouvez obtenir certaines de ces métadonnées à l'aide des outils de découverte. Voici quelques exemples de ce type de métadonnées :

    • Sous-réseau cible

    • Groupe de sécurité cible

    • Type d'instance cible

    • Rôle cible AWS Identity and Access Management (IAM)

    • Adresse IP cible

    • ID AWS du compte cible

    • AWS Région cible

    • AWS Service cible

    • Conception de l'architecture de l'application cible

  • Métadonnées de planification des vagues : les métadonnées de planification des vagues sont le type de métadonnées qui vous aident à gérer la migration. Voici des exemples de ce type de métadonnées :

    • Identifiant Wave

    • Heure de début de la vague

    • Temps de coupure des vagues

    • Propriétaire de Wave

    • Mappage des groupes Wave vers une application, un serveur, une base de données ou un groupe de déplacement

Validez vos données de découverte

Il est important de comprendre vos données de découverte actuelles avant de prendre des décisions. Vous ne disposez probablement pas de toutes les informations à ce stade de la migration. Ce manuel vous aide à définir les exigences en matière de métadonnées et à collecter les métadonnées de manière efficace. Posez-vous les questions suivantes pour savoir quelles métadonnées sont actuellement disponibles et où elles pourraient se trouver :

  • Avez-vous utilisé des outils pour effectuer une évaluation de la migration, tels que Migration Evaluator ?

  • Avez-vous déployé des outils de découverte dans votre environnement, tels que AWS Application Discovery Service Flexera One Cloud Migration and Modernization ?

  • Disposez-vous d'une CMDB qui contient le plus up-to-date d'informations pour votre portefeuille informatique ?

  • Avez-vous terminé l'évaluation initiale du portefeuille lors de la phase de mobilisation ?

  • Avez-vous terminé la planification initiale de la vague ?

  • Avez-vous terminé la conception initiale de l'environnement cible ?

  • Quelle est la source de chaque type de métadonnées ?

  • Avez-vous accès à toutes les métadonnées ?

  • Comment accéder à toutes les métadonnées ?

  • Avez-vous documenté le processus d'accès aux métadonnées ?

Étape 2 : Identifier les moteurs commerciaux et techniques

Les moteurs commerciaux et technologiques sont essentiels lorsque l'on considère les stratégies et modèles de migration de haut niveau pour chaque application. Vous devez comprendre les facteurs propres à votre migration. Vous utilisez ces facteurs commerciaux et techniques lors de la validation de vos stratégies de migration et de la définition des règles de mappage des applications.

Facteurs commerciaux courants

Les facteurs commerciaux sont des facteurs liés aux objectifs ou aux limites de l'entreprise que vous devez prendre en compte lors de la planification d'une migration importante, tels que l'expiration des contrats, la croissance rapide ou le budget. Les moteurs commerciaux les plus courants sont les suivants :

  • Quitter un centre de données : vous devez migrer le plus rapidement possible vers le cloud. Par exemple, un contrat de centre de données est sur le point d'expirer.

  • Réduction des coûts et des risques opérationnels : vous souhaitez réduire les coûts ou les risques associés à l'exploitation d'un environnement sur site.

  • Flexibilité : vous devez passer au cloud en tant qu'orientation stratégique afin de vous préparer aux changements futurs de l'entreprise.

  • Développement de l'entreprise — Vous devez être en mesure d'accélérer rapidement le développement et l'innovation ou de vous adapter à une croissance rapide.

  • Utilisation intelligente des données : vous souhaitez tirer parti de l'intelligence artificielle, de l'apprentissage automatique et de l'Internet des objets (IoT) basés sur le cloud, qui peuvent prévoir la croissance de votre entreprise et fournir des informations sur le comportement des clients.

  • Amélioration de la sécurité et de la conformité : vous devez tirer parti des programmes de conformité déjà intégrés à l'infrastructure AWS cloud, ou vous souhaitez tirer parti des outils de sécurité logiciels qui peuvent vous avertir d'une menace potentielle pour vos données.

  • Disponibilité des ressources : le fait de disposer de ressources limitées ou d'une expérience interne limitée peut vous amener à sélectionner des stratégies permettant de déplacer l'application sans modification.

Facteurs techniques courants

Les facteurs techniques sont des facteurs liés aux objectifs ou aux limites techniques que vous devez prendre en compte lors de la planification d'une migration de grande envergure, tels que l'architecture actuelle. Les facteurs techniques les plus courants sont les suivants :

  • Matériel ou logiciel end-of-support : votre matériel ou logiciel est proche de la fin de son cycle de vie et vous devez le rafraîchir car le fournisseur ne le prend plus en charge.

  • Intégration technologique — Vous avez accès à une infrastructure mondiale qui vous permet de faire évoluer rapidement et stratégiquement votre application. Vous pouvez accéder rapidement à l'international grâce à des services et à une infrastructure internationaux prêts à être utilisés.

  • Limites de stockage et de calcul : votre centre de données n'a pas la capacité de stockage ou de serveurs supplémentaires, et vous devez trouver un autre endroit pour vous développer.

  • Exigences en matière d'évolutivité et de résilience : vos applications ont connu des temps d'arrêt par le passé et vous souhaitez utiliser le cloud pour améliorer l'objectif de point de reprise (RPO) et l'objectif de temps de restauration (RTO).

  • Modernisation de l'architecture des applications : vous souhaitez tirer parti du cloud et transformer vos applications pour qu'elles soient natives pour le cloud.

  • Amélioration des performances : les performances de votre application sont médiocres pendant les saisons de pointe. Vous souhaitez augmenter ou diminuer automatiquement les performances pour répondre à la demande.

Mettre à jour le runbook

  1. Dans les modèles de playbook de portfolio, ouvrez le modèle Runbook pour hiérarchiser les applications (format Microsoft Word).

  2. Dans la section Facteurs commerciaux et techniques, enregistrez les facteurs que vous avez identifiés pour votre projet de migration de grande envergure.

  3. Enregistrez votre runbook de priorisation des applications.

Étape 3 : Valider les stratégies de migration

La sélection de stratégies de migration est essentielle pour une migration de grande envergure. Vous devez vérifier que les stratégies de migration que vous sélectionnez répondent aux attentes, aux limites et aux exigences de l'organisation. Pour plus d'informations sur les stratégies de migration disponibles, consultez le Guide pour les AWS grandes migrations.

Vous avez peut-être sélectionné des stratégies de migration lors de la phase de mobilisation ou lors de l'évaluation initiale du portefeuille. Au cours de cette étape, vous utilisez les facteurs commerciaux et techniques afin de sélectionner et de valider les stratégies de migration pour votre portefeuille.

Vos stratégies de migration peuvent changer à mesure que vous poursuivez l'évaluation du portefeuille et que vous commencez la migration. À ce stade, l'objectif est de comprendre la répartition générale de votre portefeuille selon chaque stratégie de migration. La sélection des stratégies de migration est essentielle pour passer à l'étape suivante, à savoir la validation des modèles de migration détaillés.

Sélectionnez et validez les stratégies de migration

Évaluez le portefeuille et sélectionnez les stratégies de migration comme suit :

  1. Passez en revue tous les facteurs techniques et commerciaux que vous avez identifiés à l'étape précédente, et hiérarchisez les facteurs en fonction des besoins de votre entreprise.

  2. Associez chaque moteur commercial et technique à une stratégie de migration. Le tableau suivant en est un exemple.

    Priorité Conducteur commercial ou technique Stratégie de migration

    1

    Quittez un centre de données à une date spécifiée

    Réhébergez autant d'applications que possible, replateformage et refactorisation uniquement si le réhébergement n'est pas possible.

    2

    Réduisez les coûts opérationnels et les risques

    Pour accélérer la migration, réhébergez autant d'applications que possible.

    3

    Matériel ou logiciel end-of-support

    Réhébergez les applications prises en charge et replatformatez les applications qui ne sont pas prises en charge sur du matériel et des logiciels plus récents dans le cloud.

    4

    Disponibilité des ressources

    Réhébergez vers AWS Managed Services (AMS) pour réduire la charge opérationnelle.

  3. En évaluant chaque facteur commercial et technique et en évaluant votre portefeuille à un niveau élevé, estimez la manière dont les applications devraient être réparties entre chaque stratégie de migration. Il est fréquent de voir des conflits entre les conducteurs. Les parties prenantes du projet doivent travailler ensemble et prendre les décisions finales pour résoudre les conflits. Voici un exemple de la manière dont vous pouvez répartir votre portefeuille en fonction de chaque stratégie de migration :

    • Réhébergement — 60 %

    • Replateforme — 15 %

    • Retraite — 10 %

    • Conserver — 5 %

    • Rachat — 5 %

    • Refactor — 5 %

Ne poursuivez pas la migration avant d'avoir sélectionné des stratégies de migration de haut niveau pour votre portefeuille.

Mettre à jour le runbook

  1. Ouvrez le runbook de priorisation des applications.

  2. Dans la section Stratégies de migration, notez comment la charge de travail de l'application est répartie entre les sept stratégies de migration. Par exemple :

    • Réhébergement — 60 %

    • Replateforme — 15 %

    • Retraite — 10 %

    • Conserver — 5 %

    • Rachat — 5 %

    • Refactor — 5 %

  3. Enregistrez votre runbook de priorisation des applications.

Étape 4 : Valider les modèles de migration

À propos des modèles de migration

Un modèle de migration est une tâche de migration reproductible qui détaille la stratégie de migration, la destination de la migration et l'application ou le service de migration utilisé. Rehost to Amazon Elastic Compute Cloud (Amazon EC2) en utilisant par exemple. AWS Application Migration Service Les AWS services et solutions suivants sont fréquemment référencés dans les modèles de migration courants :

  • AWS Conteneur App2

  • AWS Application Migration Service (AWS MGN)

  • AWS CloudFormation

  • AWS Database Migration Service (AWS DMS)

  • AWS DataSync

  • Amazon Elastic Compute Cloud (Amazon EC2)

  • Amazon Elastic Container Service (Amazon ECS)

  • Amazon Elastic File System (Amazon EFS)

  • AWS Solution d'usine de migration vers le cloud

  • Amazon Relational Database Service (Amazon RDS)

  • AWS Schema Conversion Tool (AWS SCT)

  • AWS Transfer Family

Comme pour la sélection de stratégies de migration, vous avez peut-être déjà identifié vos modèles de migration lors d'une phase antérieure. Cependant, vous devez les valider et vous assurer que les modèles ont été définis et documentés. Le tableau suivant répertorie les stratégies et modèles de migration courants.

ID Strategy Modèle

1

Réhéberger

Réhébergez sur Amazon EC2 à l'aide du service de migration d'applications ou de Cloud Migration Factory

2

Recréation de plateforme

Replateforme vers Amazon RDS à l'aide de et AWS DMS AWS SCT

3

Recréation de plateforme

Replateforme vers Amazon EC2 à l'aide de AWS CloudFormation

Note

CloudFormation les modèles créent une nouvelle infrastructure dans le AWS Cloud.

4

Recréation de plateforme

Replateforme vers Amazon EFS à l'aide AWS DataSync de ou AWS Transfer Family

5

Recréation de plateforme

Replateforme vers Amazon ECS à l'aide AWS d'App2Container

6

Recréation de plateforme

Replateforme des serveurs mainframe ou de milieu de gamme vers Amazon EC2 à l'aide d'un émulateur

7

Recréation de plateforme

Replateforme de Windows vers Linux sur Amazon EC2

8

Mise hors service

Supprimer l'application

9

Conserver

Conserver sur place

10

Rachat

Rachat et mise à niveau vers le SaaS

11

Refactoriser ou réorganiser

Réarchitecture de l'application

Mettre à jour le runbook

À ce stade, vous définissez les modèles au niveau du portefeuille. Plus loin dans ce playbook, vous mappez chaque application à son modèle de migration correspondant.

  1. Ouvrez le runbook de priorisation des applications.

  2. Dans la section Modèles de migration, enregistrez les modèles de migration que vous avez identifiés et validés. Attribuez un identifiant unique à chaque modèle et notez la stratégie de migration du modèle.

  3. Enregistrez votre runbook de priorisation des applications.

Notez que les modèles de migration peuvent changer au fur et à mesure de votre progression. Vous pouvez modifier vos stratégies et modèles de migration ultérieurement, à mesure que vous trouvez de nouvelles informations, que vous modifiez l'étendue de la charge de travail ou que vous décidez d'utiliser de nouveaux AWS services.

Critères de sortie des tâches

Si vous n'avez pas encore identifié vos stratégies et modèles de migration du point de vue du portefeuille de haut niveau, nous vous recommandons vivement de travailler avec les équipes techniques pour les définir avant de passer à la tâche suivante. L'évaluation du portefeuille et la planification des vagues dépendent de la compréhension des stratégies et des modèles de migration. Il n'est pas nécessaire de disposer d'une liste complète des modèles de migration avant de poursuivre. Vous pouvez ajouter de nouveaux modèles et ajuster vos stratégies au fur et à mesure.

Passez à la tâche suivante lorsque vous aurez effectué les opérations suivantes :

  • Vous avez accès aux dernières données de découverte et vous les comprenez.

  • Vous avez identifié les facteurs commerciaux et techniques de votre migration.

  • Vous avez sélectionné et validé des stratégies de migration en fonction de vos facteurs commerciaux et techniques.

  • Vous avez sélectionné et validé des modèles de migration.

  • Vous avez documenté les points suivants dans votre manuel de priorisation des applications :

    • Facteurs commerciaux et techniques

    • Stratégies de migration

    • Schémas de migration