View a markdown version of this page

Élaborez un plan de migration - AWS Transformation

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.

Élaborez un plan de migration

L'étape de planification de la migration de AWS Transform for migrations est une expérience collaborative basée sur le chat pour la planification de migrations importantes. AWS Les agents de Transform appliquent des directives AWS prescriptives pour guider les clients depuis l'analyse des données sur site jusqu'à la finalisation des plans de vague de migration.

Une fois la tâche de découverte de données sur site terminée avec succès, AWS Transform utilise les données de découverte pour regrouper les applications en vagues de migration. AWS Transform vous guide pas à pas pour analyser et définir la portée de vos serveurs, les regrouper dans des applications, générer des groupes de migration et créer des vagues de migration.

AWS Transform prend en charge la planification itérative tout au long du processus :

  • Vous pouvez poser des questions pour mieux comprendre comment AWS Transform a analysé les logiciels que vous avez installés, par exemple en ce qui concerne les dépendances des serveurs et l'architecture réseau.

  • Vous pouvez ajuster la portée au sein des groupes d'applications et des vagues à tout moment.

  • Vous pouvez télécharger à nouveau les données de découverte, et AWS Transform traitera, dédupliquera et fusionnera automatiquement les nouveaux enregistrements avec les données existantes.

  • Lorsque des modifications sont détectées, telles que des dépendances récemment découvertes ou des ajouts à l'infrastructure, AWS Transform signale les groupes de dépendances concernés et fournit des recommandations pour les ajustements du plan de vagues.

  • La planification de la migration peut également utiliser des données textuelles non structurées pour enrichir le processus de planification.

La planification de la migration comporte quatre étapes :

  • Dans Scope and analysis, vous pouvez examiner vos données de découverte, poser des questions sur votre environnement logiciel et réseau et déterminer les ressources concernées par la migration.

  • Dans les applications de groupe, vous pouvez fournir une combinaison de règles commerciales et techniques concernant, par exemple, l'analyse des noms d'hôte, les dépendances réseau et les règles métier, afin que la planification de la migration puisse regrouper votre infrastructure en applications. Si vous disposez déjà d'un inventaire de vos applications, la planification de la migration peut l'utiliser à la place.

  • Dans Générer des groupes de migration, vous pouvez indiquer à la planification de la migration vos exigences techniques et commerciales afin qu'elle puisse déterminer quelles applications doivent être déplacées ensemble. Les dépendances techniques incluent les bases de données, les files de messages ou d'autres ressources partagées entre plusieurs applications. Les dépendances commerciales et opérationnelles incluent la criticité commerciale, le RPO et le RTO, l'emplacement des centres de données et les propriétaires des applications.

  • Enfin, dans Build waves, vous pouvez donner un contexte à la planification de la migration concernant vos délais et vos priorités afin qu'il puisse élaborer un plan de migration que vous pouvez effectuer. Vous pouvez sélectionner des groupes de déplacements à inclure dans une vague en fonction de facteurs tels que le score de priorité, la taille des groupes de déplacements, le nombre d'utilisateurs et la complexité de l'application.

Terminologie de planification de la migration

Vague migratoire

Groupe logique d'applications qui sont migrées ensemble. Les vagues migratoires sont composées d'un ou de plusieurs groupes de déplacements.

Déplacer le groupe

Ensemble d'applications co-dépendantes qui doivent être déplacées ensemble. Ils peuvent présenter des dépendances techniques telles qu'une base de données partagée ou des dépendances commerciales telles que la prise en charge d'une fonction métier partagée.

Dépendance

Relation entre les systèmes. Il existe plusieurs types de dépendances :

  • Dépendances critiques ou difficiles. Les systèmes ne peuvent pas fonctionner sans dépendance. Les exemples courants incluent les applications qui dépendent de bases de données, d'autres applications ou de services.

  • Dépendances douces. Non critique pour le fonctionnement du système. Les exemples courants incluent les dépendances insensibles à la latence qui peuvent être migrées indépendamment.

  • Non-technicaldépendances. Dépendances commerciales, organisationnelles, opérationnelles et de conformité liées à votre organisation et à ses priorités. Les exemples incluent le partage des fonctions commerciales et la propriété organisationnelle.

Flux de travail

La planification de la migration est un flux de travail interactif et itératif. Vous pouvez revenir en arrière et modifier les étapes précédentes à tout moment. Un flux de travail typique de planification de la migration est le suivant :

  1. La planification de la migration commence par la synthèse des données de découverte disponibles. Passez en revue les données disponibles et revenez à tout moment à l'étape de découverte pour fournir des données supplémentaires.

  2. Au cours de l'étape de cadrage et d'analyse, vous pouvez poser des questions sur votre environnement sur site afin de valider les données que vous avez collectées. Voici quelques exemples de questions :

    1. Répertorier mes serveurs par système d'exploitation

    2. Résumer la topologie de mon réseau local

    3. Répertoriez les technologies les plus courantes utilisées dans mon environnement.

  3. Lors de l'analyse de votre environnement, si vous identifiez des serveurs qui ne devraient pas être concernés par la migration, vous pouvez demander à AWS Transform d'exclure ces ressources. En voici quelques exemples :

    1. Supprimez tous les serveurs dont le nom d'hôte contient un ancien nom d'hôte

    2. Supprimez tous les serveurs de la version 10.0.2. 0/24 sous-réseau

    3. Supprimez tous les serveurs exécutant des versions de Windows antérieures à 2022

  4. Une fois que vous aurez suffisamment exploré votre environnement et déterminé l'étendue de votre migration, vous pouvez demander à AWS Transform de passer à l'étape suivante de planification de la migration.

  5. L'étape suivante consiste à regrouper les demandes. Si vos serveurs sont déjà mappés à des applications, vous pouvez demander à AWS Transform d'utiliser ce mappage et ignorer cette étape. Si vos applications ne sont pas prédéfinies, vous pouvez fournir la logique technique et commerciale qui définit vos applications. AWS Transform vous guidera tout au long du processus de regroupement des applications et vous proposera les points de données que vous pouvez fournir pour regrouper efficacement vos serveurs au sein d'applications. Plus vous pouvez fournir d'informations sur vos applications locales, plus AWS Transform peut regrouper efficacement vos serveurs en applications. Une fois que vous avez fourni suffisamment d'informations, vous pouvez demander à AWS Transform de regrouper les applications.

  6. Une fois le regroupement des applications effectué, passez en revue les groupes d'applications. Vous pouvez demander à AWS Transform d'apporter les modifications nécessaires, par exemple :

    1. Déplacer le serveur example-server vers application-5

    2. Renommer l'application-5 « HR App Test Environment »

    3. Supprimer tous les serveurs Linux de la ferme de développement IIS

  7. Une fois vos applications regroupées, demandez à AWS Transform de passer à l'étape suivante

  8. L'étape suivante consiste à déplacer le regroupement. Lors de l'étape de regroupement des déplacements, vous identifiez les applications qui doivent être déplacées ensemble. Fournissez un contexte concernant vos dépendances techniques et non techniques. AWS Transform vous guidera tout au long du processus et vous proposera des points de données que vous pouvez fournir pour regrouper vos applications. Il y a plusieurs considérations à prendre en compte à ce stade, notamment :

    1. Quelle devrait être la taille cible du groupe de déménagement ?

    2. Voulez-vous combiner des environnements, par exemple dev, test et prod, pour chaque application, ou les scinder ?

    3. Comment souhaitez-vous prendre en compte les dépendances réseau ? Toutes les dépendances sont-elles critiques ou certaines dépendances peuvent-elles être considérées comme des dépendances douces et être réparties entre les groupes de déménagement ?

  9. Une fois que vous avez défini vos règles de regroupement de déplacements, demandez à AWS Transform d'exécuter votre stratégie de regroupement de déplacements. Vous pouvez ensuite consulter et modifier vos groupes de déplacements. Une fois que vous avez examiné vos groupes de déménagements, vous pouvez demander à AWS Transform de passer à l'étape finale de planification de la migration.

  10. La planification des vagues est la dernière étape de la planification de la migration. Au cours de cette étape, vous regroupez vos groupes de déplacements en vagues de migration et vous hiérarchisez ces vagues. Au cours de l'étape de planification des vagues, AWS Transform vous guidera en vous fournissant les priorités commerciales nécessaires pour regrouper vos groupes de déménagements en vagues, puis hiérarchiser ces vagues. Les considérations relatives à la planification des vagues incluent :

    1. L'importance commerciale de chacun de vos groupes de déménagement

    2. Les délais de migration et les délais pour chaque groupe de déménagement

    3. Les risques associés à chaque groupe de déménagement

    4. Le nombre de serveurs à migrer par vague

  11. Une fois que vous avez fourni suffisamment de conseils sur la façon de regrouper en vagues, demandez à AWS Transform d'exécuter la planification des vagues. Vous pouvez ensuite revoir vos vagues et les modifier.

  12. Une fois que vous avez finalisé votre plan Wave, vous pouvez terminer la planification de la migration et passer à l'exécution. Vous pouvez revenir à la planification de la migration à tout moment pour peaufiner et modifier votre plan.

  13. Pour chaque vague, vous pouvez attribuer une stratégie de migration : réhébergement (migration des serveurs vers Amazon EC2) et conteneurisation (conteneurisation du code source et déploiement sur Amazon Elastic Container Service ou Amazon Elastic Kubernetes Service). Lorsque vous attribuez à une vague la stratégie de conteneurisation, AWS Transform exécute le flux de travail de conteneurisation du code source pour cette vague lors de l'exécution de la migration. Pour de plus amples informations, veuillez consulter Conteneurisation du code source. Pour obtenir les stratégies AWS recommandées dans le cadre des 7R avant de les attribuer, consultez. Recommandations relatives à la stratégie de migration (7R)