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.
# Analyse du portefeuille et planification de la migration
Cette étape de l'évaluation vise à terminer la découverte et l'analyse au niveau du portefeuille entamées dans la section [Découverte du portefeuille et planification initiale](portfolio-discovery-initial-planning.md). L'objectif est d'itérer et d'établir une base de référence pour le portefeuille initial d'applications et d'infrastructures. Cette base de référence inclut l'identification de toutes les dépendances, l'itération de modèles de rationalisation pour la migration, la création d'une analyse de rentabilisation détaillée et la définition d'un plan de vague de migration. Par conséquent, la fidélité des données requise est plus élevée. Cette étape nécessitera un investissement en temps. Pour accélérer les résultats de l'évaluation, nous recommandons d'utiliser autant de sources de données programmatiques que possible, telles que des outils de découverte.
Les principaux résultats de cette étape sont les suivants :
+ Inventaire des applications et des infrastructures de haute fidélité
+ Une stratégie de migration de haut niveau pour chaque application
+ Un plan de vague de migration très fiable
+ Une analyse de rentabilisation détaillée
# Comprendre les exigences complètes en matière de données d'évaluation
Le tableau suivant décrit les informations requises pour obtenir une vue complète du portefeuille des applications concernées par la migration et de leur infrastructure associée.
Les tableaux utilisent les abréviations suivantes :
+ R, pour obligatoire
+ O, en option
+ N/A, car non applicable
**Applications**
| **Nom d'attribut** | **Description** | **Inventaire et priorisation** | **Analyse de rentabilisation détaillée** | **Niveau de fidélité recommandé (minimum)** |
| --- | --- | --- | --- | --- |
| Identifiant unique | Par exemple, l'ID de l'application. Généralement disponible sur les inventaires et systèmes de contrôle internes existants CMDBs ou autres. Envisagez de créer des IDs éléments uniques chaque fois que ceux-ci ne sont pas définis dans votre organisation. | R | R | Élevée |
| Application name (Nom de l'application) | Nom sous lequel cette application est connue de votre organisation. Incluez le fournisseur commercial off-the-shelf (COTS) et le nom du produit, le cas échéant. | R | R | Élevée |
| Est-ce que COTS ? | Oui ou non Qu'il s'agisse d'une application commerciale ou d'un développement interne | R | R | Élevée |
| Produit et version COTS | Nom et version du produit logiciel commercial | R | R | Élevée |
| Description | Fonction et contexte principaux de l'application | R | R | Élevée |
| Criticité | Par exemple, une application stratégique ou génératrice de revenus, ou le soutien d'une fonction critique | R | R | Élevée |
| Type | Par exemple, base de données, gestion de la relation client (CRM), application Web, multimédia, service informatique partagé | R | R | Élevée |
| Environnement | Par exemple, production, pré-production, développement, test, bac à sable | R | R | Élevée |
| Conformité et réglementation | Cadres applicables à la charge de travail (par exemple, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) et aux exigences réglementaires | R | R | Élevée |
| Dépendances | Dépendances en amont et en aval vis-à-vis d'applications ou de services internes et externes. Dépendances non techniques telles que les éléments opérationnels (par exemple, les cycles de maintenance). | R | O | Élevée |
| Cartographie des infrastructures | Mappage vers les actifs and/or virtuels physiques qui constituent l'application | R | R | Élevée |
| Licence | Type de licence logicielle standard (par exemple, Microsoft SQL Server Enterprise) | R | R | Moyenne-élevée\$1 |
| Cost | Coûts de licence logicielle, d'exploitation des logiciels et de maintenance | N/A | R | Moyenne-élevée\$1 |
| Unité commerciale | Par exemple, le marketing, les finances, les ventes | R | R | Élevée |
| Informations sur le propriétaire | Informations de contact pour le propriétaire de l'application | R | R | Élevée |
| Informations DR | Composants de reprise après sinistre | R | R | Élevée |
| Stratégie de migration | Par exemple, l'un des 6 R pour la migration vers AWS | R | R | Élevée |
| Tickets de support | 12 à 24 mois de données pour aider à évaluer la productivité et l'impact financier des pannes, des ralentissements, de la limitation des transactions et des dépassements de fenêtres par lots | O | R | Moyenne |
**Infrastructures**
| **Nom d'attribut** | **Description** | **Inventaire et priorisation** | **Affaire de rentabilisation** | **Niveau de fidélité recommandé (minimum)** |
| --- | --- | --- | --- | --- |
| Identifiant unique | Par exemple, l'ID du serveur. Généralement disponible sur les inventaires et systèmes de contrôle internes existants CMDBs ou autres. Envisagez de créer des IDs éléments uniques chaque fois que ceux-ci ne sont pas définis dans votre organisation. | R | R | Élevée |
| Nom du réseau | Nom de l'actif sur le réseau (par exemple, nom d'hôte) | R | R | Élevée |
| Nom DNS (nom de domaine complet, ou FQDN) | Nom du DNS | R | O | Élevée |
| Adresse IP et masque réseau | Adresses IP and/or publiques internes | R | R | Élevée |
| Type de ressource | Par exemple, serveur physique ou virtuel, hyperviseur, conteneur, appareil, instance de base de données | R | R | Élevée |
| Nom du produit | Fournisseur commercial et nom du produit (par exemple VMware ESXi, IBM Power Systems, Exadata) | R | R | Élevée |
| Système d’exploitation | Par exemple, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Élevée |
| Configuration | Processeur alloué, nombre de cœurs, nombre de threads par cœur, mémoire totale, stockage, cartes réseau | R | R | Élevée |
| Utilisation | Pic et moyenne du processeur, de la mémoire et du stockage. Débit des instances de base de données. | R | R | Élevée |
| Licence | Type de licence de base (par exemple, RHEL Standard) | R | R | Élevée |
| S'agit-il d'une infrastructure partagée ? | Oui ou Non pour désigner les services d'infrastructure qui fournissent des services partagés tels que le fournisseur d'authentification, les systèmes de surveillance, les services de sauvegarde et les services similaires | R | R | Élevée |
| Cartographie des applications | Applications ou composants d'application exécutés dans cette infrastructure | R | R | Élevée |
| Cost | Coûts complets pour les serveurs bare metal, y compris le matériel, la maintenance, les opérations, le stockage (SAN, NAS, Object), les licences du système d'exploitation, la part de l'espace rack et les frais généraux des centres de données | N/A | R | Moyenne-élevée\$1 |
| Volume estimé de transfert de données (entrée/sortie) | Par exemple, par actif d'infrastructure supérieur par jour sur une période de 30 jours | O | R | Moyenne |
**Réseaux**
| **Nom d'attribut** | **Description** | **Inventaire et priorisation** | **Affaire de rentabilisation** | **Niveau de fidélité recommandé (minimum)** |
| --- | --- | --- | --- | --- |
| Taille du tuyau (Mb/s), redundancy (Y/N) | Spécifications actuelles des liaisons WAN (par exemple, redondance de 1 000 Mo/s) | R | R | Moyenne-élevée\$1 |
| Utilisation des liens | Utilisation maximale et moyenne, transfert de données sortants (Go/mois) | R | R | Moyenne-élevée\$1 |
| Latence (ms) | Latence actuelle entre les sites connectés. | R | O | Élevée |
| Cost | Coût actuel par mois | N/A | R | Moyenne-élevée\$1 |
**Migration**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/application-portfolio-assessment-guide/understanding-complete-assessment-data-requirements.html)
# Établir une base de référence pour le portefeuille d'applications
Pour créer des plans de vague de migration fiables, vous devez établir une base de référence pour le portefeuille d'applications et son infrastructure associée. Une base de portefeuille fournit une vue complète de l'étendue de la migration, y compris les dépendances techniques et la stratégie de migration. La base de référence du portefeuille indique clairement quelles applications sont concernées par la migration et indique que les points de données décrits dans la section [Comprendre les exigences complètes en matière de données d'évaluation](understanding-complete-assessment-data-requirements.md) sont collectés. De même, toute l'infrastructure associée (calcul, réseaux de stockage) est comprise et mappée aux applications.
Les dépendances techniques peuvent être décrites en quatre catégories :
+ **Les pplication-to-infrastructure dépendances établissent le lien entre le logiciel et le matériel physique ou virtuel.** Par exemple, il existe une dépendance entre une application CRM et les machines virtuelles sur lesquelles elle est installée.
+ Les dépendances entre **les composants de l'application** décrivent la manière dont les composants exécutés dans différents actifs d'infrastructure interagissent. Par exemple, une interface Web exécutée sur des machines virtuelles, avec une couche d'application exécutée sur une machine virtuelle différente et une base de données exécutée sur un cluster de bases de données constituent un exemple de dépendance entre les composants d'une application.
+ **Les pplication-to-application dépendances ont trait à l'interaction entre des applications ou des composants d'applications avec d'autres applications ou leurs composants.** Une application de traitement des paiements et une application de gestion des stocks sont des exemples de application-to-application dépendance. Ces applications sont indépendantes, mais elles interagissent constamment à l'aide d'opérations d'API définies.
+ Application-to-infrastructure les dépendances de **services** sont techniquement application-to-application des dépendances, étant donné que le service d'infrastructure est lui-même une application. Cependant, nous vous recommandons de les classer séparément. La principale raison est que les services d'infrastructure sont généralement partagés par de nombreuses applications, de sorte qu'ils ont une longue série de dépendances. Ils suivent également généralement une stratégie et un modèle de migration différents. Par exemple, un équilibreur de charge peut contenir des pools d'équilibrage pour plusieurs applications. Ce qui compte, c'est la dépendance vis-à-vis du pool, qui est susceptible d'être migré individuellement, parallèlement à l'application dépendante, tandis que l'équilibreur de charge lui-même est conservé ou retiré. En outre, l'individualisation des dépendances des application-to-infrastructure services permet d'éviter les faux groupes de dépendances. Un faux groupe de dépendances se produit lorsque plusieurs applications métiers sont regroupées, ce qui implique qu'elles ont une dépendance commune à un service d'infrastructure qui doit être migrée en même temps. Par exemple, les services d'authentification, tels qu'Active Directory, sont susceptibles d'être associés à de grands groupes d'applications. L'essentiel est d'aborder ces applications individuellement et de remédier à la dépendance en activant le service, par exemple dans l'environnement cloud. AWS Directory Service for Microsoft Active Directory
Lorsque vous établissez une base de référence pour le portefeuille, nous vous recommandons de confirmer une stratégie de migration pour chaque composant de l'application. La stratégie de migration sera l'un des 6 R de la migration (voir la section [sur la stratégie de migration des 6 R](iterating-6-rs-migration-strategy-selection.md)). Dans la base de référence du portefeuille, l'un des 6 R doit être associé à chaque application. Une stratégie 6 R doit également être associée à chacun des composants de l'infrastructure de l'application.
Pour établir une version de référence du portefeuille, y compris les dépendances et les stratégies de migration, utilisez des outils de découverte automatisés (voir [Évaluation du besoin d'outils de découverte).](understanding-initial-assessment-data-requirements.md#discovery-tooling) Complétez les données avec des informations recueillies auprès des principales parties prenantes telles que les propriétaires d'applications et les équipes d'infrastructure. Continuez à collecter des données jusqu'à ce que vous obteniez un inventaire complet du portefeuille qui correspond aux attributs et au niveau de fidélité décrits dans la [section sur les exigences en matière de données](understanding-complete-assessment-data-requirements.md) pour cette étape. L'ensemble de données qui en résultera jouera un rôle déterminant dans la conduite de la migration.
Sachez qu'en fonction de l'étendue de votre migration et des outils disponibles, cette activité peut prendre plusieurs semaines.
# Réitération des critères de priorisation
Avant de créer des plans de vague de migration, nous vous recommandons de réitérer les critères de priorisation des applications afin de passer de la sélection des applications pilotes à la planification des vagues à long terme.
Dans les sections précédentes, nous avons introduit un critère de priorisation par défaut qui prioriserait les applications simples prêtes pour le cloud (voir [Prioriser](prioritization-and-migration-strategy.md#prioritizing-applications) les applications). En effet, au début, nous recommandons de commencer par les applications non critiques afin d'affiner les processus de migration et d'intégrer les leçons apprises. Toutefois, à ce stade, et pour créer des plans à long terme, l'ordre dans lequel les applications sont migrées doit être aligné sur les facteurs commerciaux. L'application des nouveaux critères générera un nouveau classement des candidatures qui sera un élément clé pour la planification des vagues.
Passez en revue les points de données disponibles dans le portefeuille d'applications et sélectionnez les attributs qui détermineront la priorisation des applications en fonction des facteurs commerciaux.
Tout d'abord, validez vos [moteurs commerciaux (voir Moteurs commerciaux et principes directeurs techniques](business-drivers-technical-guiding-principles.md)). Ensuite, en fonction des facteurs de votre activité, sélectionnez les attributs qui vous aideront à hiérarchiser les applications à migrer.
Le tableau suivant présente des exemples de critères de priorisation alignés sur les moteurs commerciaux de l'innovation.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html)
Le tableau suivant présente des exemples de critères de priorisation alignés sur les facteurs commerciaux pour une réduction rapide des coûts.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html)
Testez les critères de priorisation et recommencez jusqu'à ce que vous soyez généralement d'accord avec le résultat. Il faut au moins trois ou quatre itérations pour obtenir une version de référence.
# Itérer la sélection de la stratégie de migration en 6 R
À ce stade, nous vous recommandons d'itérer et de faire évoluer l'arbre de décision des 6 R. La section [Déterminer le type R pour la migration](prioritization-and-migration-strategy.md#migration-r-type) a introduit un arbre de décision par défaut. Nous vous recommandons de réviser l'arborescence, de prendre en compte les enseignements tirés tout au long de la migration des applications pilotes initiales et de veiller à ce qu'elle corresponde toujours aux moteurs commerciaux, aux critères de priorisation et à votre situation particulière. Validez l'arbre de décision avec des exemples d'applications et vérifiez qu'il produit toujours la stratégie attendue. Sinon, mettez à jour la logique en conséquence. L'arbre qui en résultera sera essentiel pour établir des bases de référence pour le portefeuille d'applications et pour allouer des stratégies de migration pour chaque composant de l'application.
Comme décrit dans la [section précédente des 6 R](prioritization-and-migration-strategy.md#migration-r-type), les 6 R s'appliquent également à l'infrastructure, et il est tout aussi important de les attribuer en conséquence. Alors qu'un composant d'application donné aura une stratégie de migration, au niveau de l'infrastructure, chaque actif d'infrastructure suivra une stratégie de migration donnée qui peut être différente de la stratégie établie pour le composant d'application qu'il prend en charge.
N'oubliez pas que l'arbre de décision en 6 R s'applique uniquement aux composants de l'application. La stratégie de migration de l'infrastructure est dérivée de la stratégie choisie pour l'application. Par exemple, pour un composant d'application qui sera replatformé, l'infrastructure actuelle qui l'héberge pourrait être retirée.
Assurez-vous que les stratégies de migration sont allouées à chaque composant de l'application et à son infrastructure associée. Ces informations seront un facteur clé lors de l'estimation des efforts, des capacités et des compétences nécessaires, et lors de la création de plans pour les vagues de migration.
Pour plus d'informations sur la détermination de vos 6 R, consultez les [recommandations AWS Migration Hub stratégiques](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/).
# Planification des vagues
Dans le cadre de la planification des vagues, un groupe de dépendances est un ensemble d'applications et d'infrastructures présentant des dépendances techniques et non techniques impossibles à résoudre. En raison de ces dépendances, les applications et l'infrastructure d'un groupe de dépendances doivent être migrées en même temps ou à une date précise. Par exemple, une application exécutée sur une machine virtuelle et une base de données exécutée sur une machine virtuelle distincte, soumises à des exigences de faible latence ou à des volumes de trafic élevés et à des requêtes complexes, sont susceptibles d'être migrées ensemble plutôt que d'utiliser un composant dans le cloud et l'autre sur site. De même, les applications indépendantes qui interagissent via une API présentant des exigences similaires en matière de faible latence seront également migrées en même temps.
Les vagues de migration s'étendent généralement sur 4 à 8 semaines et peuvent contenir un ou plusieurs événements migratoires. Les groupes de dépendance sont combinés en vagues afin qu'une vague puisse contenir un ou plusieurs groupes de dépendance. La vague contient également d'autres activités nécessaires à la migration. Cela inclut la configuration de AWS l'infrastructure (telle que la zone d'atterrissage, la sécurité et les opérations), les outils de migration et les activités de migration telles que la réplication des données, la planification de la transition, les tests et le support après la migration.
Pour mesurer le succès et suivre les progrès, les vagues doivent être alignées sur les résultats et les moteurs commerciaux. Cela influencera également la durée des vagues et les groupes de dépendance qu'elles contiennent. L'achèvement d'une vague doit être le reflet d'un résultat mesurable. La planification d'une vague peut également combiner d'autres facteurs, tels que des principes directeurs techniques. Par exemple, les vagues peuvent être définies par environnement (par exemple, développement, test, production) ou par stratégie de migration (par exemple, vague de rehost, vague de replateforme).
Pour créer des plans de vague de migration efficaces et fiables, vous devez obtenir une vue complète du portefeuille d'applications, de l'infrastructure associée (calcul, stockage, réseaux), du mappage des dépendances et de la stratégie de migration.
La section consacrée à l'[établissement d'une base de référence pour le portefeuille d'applications](baseline-application-portfolio.md) décrit quatre catégories de dépendances techniques. Ces dépendances contribuent à la création de vagues de migration et à la définition de groupes de dépendance. Les groupes de dépendance seront déterminés en fonction de l'importance de la dépendance. En outre, les dépendances non techniques doivent être prises en compte. Par exemple, les calendriers de lancement des applications, les fenêtres de maintenance et les dates commerciales clés telles que le traitement de fin de mois ou de fin de trimestre influenceront le plan de vague.
Déterminez si la dépendance est *souple* ou *dure*. Une dépendance souple est une relation entre deux actifs ou plus, ou entre un actif et une contrainte, qui ne dépend pas de l'emplacement des composants. Par exemple, deux systèmes fonctionnant sur le même réseau local (ou la même infrastructure) peuvent être séparés en déplaçant l'un de ces systèmes vers le cloud tandis que l'autre reste sur site. Un autre exemple est un système qui peut être migré pendant une fenêtre de maintenance sans impact sur les activités de maintenance.
Une dépendance stricte est une relation entre deux actifs ou plus, ou entre un actif et une contrainte, qui dépend de l'emplacement. Par exemple, deux systèmes qui fonctionnent sur le même réseau local et qui sont fortement tributaires d'une faible latence pour la communication entre le serveur d'applications et le serveur de base de données ont une forte dépendance. Le transfert d'un seul de ces systèmes vers le cloud entraînerait des problèmes de fonctionnalité ou de performance impossibles à résoudre. De même, des raisons non techniques, telles que la disponibilité des ressources (par exemple, l'équipe chargée de la migration) ou des contraintes opérationnelles, telles que les fenêtres de maintenance pendant lesquelles deux systèmes ne peuvent être migrés que dans un intervalle de temps donné, peuvent créer une forte dépendance pour ces actifs.
Pour créer un plan de migration, déterminez vos groupes de dépendances en analysant les dépendances, idéalement à partir d'une source de données hautement fiable telle que des outils de découverte spécialisés, et combinez ces informations avec les critères de priorisation de vos applications et les circonstances opérationnelles. Les applications figurant en haut du classement par ordre de priorité doivent être ciblées en fonction de vos vagues de migration initiales. Déterminez la capacité des vagues (le nombre d'applications qu'une vague peut contenir) en fonction de la disponibilité des ressources, de la tolérance au risque, des contraintes commerciales et techniques, de l'expérience et des compétences. Envisagez de travailler avec des services AWS professionnels ou des partenaires de compétences en matière de AWS migration, qui peuvent fournir des spécialistes pour vous aider tout au long du processus.
Les critères de priorisation sont une première indication de l'ordre dans lequel vous allez déplacer vos applications vers le cloud. Cependant, les groupes de dépendance seront le véritable déterminant des applications qui seront déplacées à un moment donné. Cela est dû au fait que les applications classées comme hautement prioritaires peuvent être fortement dépendantes des applications situées au milieu ou au bas du classement.
La stratégie migratoire influencera également la composition d'une vague. Par exemple, une application hautement prioritaire qui nécessite une stratégie de refactorisation susceptible de nécessiter plusieurs semaines ou plusieurs mois d'analyse, de conception, de test et de préparation sera probablement placée dans une vague ultérieure.
## Création d'un plan de vagues
Les données du portefeuille d'applications et l'évaluation détaillée du groupe d'applications qui seront migrées au cours de la vague sont des conditions préalables à la migration d'une vague d'applications. L'évaluation détaillée doit inclure la liste des applications incluses dans la vague, les détails de l'infrastructure associée, une conception cible et une stratégie de migration pour chaque application.
L'établissement de la propriété et de la gouvernance des vagues est essentiel pour gérer et suivre le travail des vagues, les dépendances entre les programmes, la gestion du changement, les problèmes et les risques. Assurez-vous qu'un cadre de gouvernance est en place pour gérer le plan.
Pour définir le plan de vagues, commencez par une construction de vague par défaut. Que se passe-t-il au sein d'une vague ? Une fois l'entrée initiale définie, la vague peut commencer. En règle générale, les activités seront les suivantes :
1. Affinez le plan de transition. Cette activité doit décrire les runbooks et les étapes à suivre au moment de la migration, y compris la coordination avec d'autres équipes internes et externes.
1. Affinez le plan de restauration. Que faut-il faire pour annuler les demandes en cas de problème ?
1. Préparez l'infrastructure cible. Par exemple, vous pouvez créer ou étendre la zone AWS d'atterrissage (sécuritéCompte AWS, mise en réseau, services d'infrastructure, autres infrastructures de support).
1. Testez l'infrastructure cible.
1. Utiliser les outils de migration. Par exemple, installez des agents de réplication et lancez le transfert de données.
1. Procédez à un plan de découpage et enregistrez des cycles de séchage. Regroupez tous les membres de l'équipe participants et passez en revue toutes les étapes à l'avance.
1. Surveillez la réplication des données et les déploiements d'infrastructures.
1. Confirmer l'état de préparation à l'exploitation de l'infrastructure et des applications dans AWS.
1. Vérifiez l'état de préparation en matière de sécurité
1. Confirmez les exigences réglementaires et de conformité (par exemple, validation de la charge de travail avant et après la migration), le cas échéant.
1. Migrez les applications vers AWS et effectuez des tests préalables à la mise en service.
1. Fournissez une assistance après la migration pendant une période, par exemple 3 jours, lorsque les équipes opérationnelles et les équipes de migration sont entièrement disponibles pour résoudre les problèmes et appliquer les optimisations.
1. Procéder à un examen après la migration. Documentez les leçons apprises et intégrez-les dans les futures vagues.
1. Clôturez la vague en confirmant le transfert opérationnel et en obtenant des indicateurs pour les rapports.
La durée de chacune de ces activités dépendra de la complexité de la portée, de la capacité des vagues, des personnes impliquées et de votre situation particulière. Dans la mesure du possible, des vagues plus petites sont préférables, car cela réduira l'impact des retards ou des blocages de migration. Déterminez, avec vos équipes, la durée par défaut d'une vague.
Procédez ensuite à l'analyse des dates pour créer une structure initiale de haut niveau composée de vagues vides (aucune application n'ayant encore été assignée). Réfléchissez aux questions suivantes :
+ Quelle est la durée totale du programme de migration ?
+ Quels sont les délais ?
+ Existe-t-il des dates de sortie fixes pour les centres de données ?
+ Existe-t-il des dates de fin de contrat de collocation ?
+ Quels sont les cycles d'actualisation des applications et de l'infrastructure ?
+ Quels sont les cycles de maintenance et de publication des applications ?
+ Y a-t-il des dates auxquelles les migrations devraient être évitées (par exemple, cycles de publication et de maintenance, fin d'année, vacances, traitement de fin de mois) ?
En tenant compte de ces considérations, tracez les vagues dans un plan. Pour accélérer le processus de migration, nous recommandons de superposer les vagues dans la mesure du possible. La clé du chevauchement des vagues est de définir et de prendre en compte ce qui se passe au sein d'une vague. Généralement, les activités de déploiement, la validation de l'infrastructure cible et la synchronisation des données ont lieu au cours de la première moitié d'une vague. Le second semestre se concentrera sur la migration proprement dite, les tests et le transfert opérationnel. Cela signifie que différentes équipes sont impliquées dans chaque moitié du processus et que vous pouvez gagner en efficacité. Par exemple, dès que l'équipe impliquée dans la préparation de l'infrastructure cible aura terminé son travail, elle pourra commencer à travailler sur les exigences de la prochaine vague. En général, il est préférable que la plupart des vagues aient une longueur et une structure similaires afin de faciliter une approche industrielle des migrations. Cependant, au cours du processus de planification des vagues, la taille d'une vague donnée peut être étendue pour répondre aux dépendances ou aux exigences opérationnelles.
Ensuite, en fonction des groupes de dépendance identifiés, déterminez la taille maximale d'une vague en termes de nombre de groupes de dépendance qu'elle peut contenir. La taille des vagues est généralement dictée par l'appétit pour le risque (par exemple, dans quelle mesure les changements parallèles peuvent être tolérés) et par la disponibilité des ressources (par exemple, dans quelle mesure les changements parallèles peuvent être effectués avec les ressources, les compétences et le budget disponibles). Toutefois, lors de la planification initiale, ne vous limitez pas aux besoins en ressources et à la disponibilité. Les ondes qui contiennent plusieurs groupes de dépendance peuvent être décomposées en vagues plus petites lors des prochaines itérations.
Une fois que les groupes de dépendance pour une vague donnée ont été confirmés, passez en revue les ressources nécessaires à la migration de la vague. Envisagez d'ajuster la taille de la vague (le nombre de groupes de dépendance qu'elle contient) en fonction des besoins en ressources. Cela peut entraîner des vagues plus ou moins grandes. Répétez le plan de vagues selon les besoins jusqu'à ce que toutes les vagues aient été définies.
## Gérer le changement
Le portefeuille d'applications et l'infrastructure associée évolueront au cours du cycle de vie des programmes de migration. Les programmes de migration de longue durée coexistent avec l'évolution et le changement normaux de l'entreprise. Les applications continuent d'évoluer en attendant d'être migrées. Des serveurs sont ajoutés ou supprimés, une nouvelle infrastructure est déployée sur site. On s'attend à ce que la portée d'une vague ou d'un groupe de dépendance doive être modifiée. Des modifications sont nécessaires, en particulier lorsque, à l'approche de la date de migration, une dépendance précédemment inconnue est identifiée ou qu'un nouveau serveur est inclus dans l'inventaire. Cela peut parfois se produire au cours de la migration elle-même.
Les modifications du champ d'application affectent les groupes de dépendance et les vagues. Pour gérer le changement et en minimiser l'impact, il est important de mettre en place un mécanisme de contrôle de la portée. Un mécanisme de contrôle des modifications du champ d'application nécessite la définition d'une source fiable unique pour le champ d'application. Il peut s'agir d'un outil de gestion du périmètre, d'un fichier .csv, d'une feuille de calcul ou d'une base de données, tel que défini par la gouvernance du programme de migration. Vous devez identifier les changements, analyser leur impact et communiquer les changements aux parties prenantes concernées afin qu'elles puissent prendre des mesures. Le plan de vagues sera donc itéré.
# Analyse de rentabilisation détaillée
À ce stade, nous recommandons de valider et d'élargir la portée de l'analyse de rentabilisation afin de fournir un niveau de détail plus élevé pour étayer le programme de transformation. L'analyse de rentabilisation directionnelle initiale rapidement assemblée est conçue pour apporter suffisamment de confiance pour investir dans les étapes fondamentales et le niveau suivant de planification détaillée.
L'élaboration d'une analyse de rentabilisation détaillée soutient ce processus de planification de la manière suivante :
+ Fournir des analyses financières qui éclairent les décisions sur ce qui doit être migré et modernisé, sur les options à sélectionner et sur la manière d'échelonner et de prioriser le travail
+ Valider, affiner et développer le dossier financier directionnel original en réexaminant en détail :
+ Le potentiel de réduction des coûts d'infrastructure
+ La productivité informatique interne et l'efficacité des opérations externalisées
+ Les estimations des investissements nécessaires à la configuration, à la migration et à la modernisation du programme
+ Identification, estimation de l'ampleur et mise en place du processus de suivi des autres facteurs de valeur apportés par la migration
Dans l'analyse de rentabilisation détaillée, vous établissez les points suivants :
+ La base objective sur laquelle garantir le mandat et les investissements nécessaires pour mettre en œuvre au moins la première phase de la migration
+ Les attentes de performance financière minimale de référence pour le programme
+ Clarté quant à la base financière sur laquelle les différentes décisions relatives à la conception et à la priorisation de la migration sont prises, de sorte que lorsque les circonstances et les personnes changent au cours du programme, les nouveaux dirigeants peuvent faire des choix éclairés.
+ Aperçu des domaines supplémentaires d'optimisation des coûts à explorer une fois que les données d'utilisation initiales seront disponibles au fur et à mesure que les charges de travail seront migrées et mises en service
+ Estimations de la valeur que la transformation du cloud apporte à l'entreprise grâce à une résilience et à une agilité accrues
+ Les indicateurs et hypothèses associés KPIs utilisés pour estimer le rendement financier résultant de l'amélioration de la résilience et de l'agilité, qui constituent ensuite la base de référence pour tirer parti des principaux avantages du programme
## Déterminez les scénarios nécessaires pour le cas
Lors de l'élaboration de l'analyse de rentabilisation détaillée, il est généralement nécessaire de développer plusieurs scénarios pour étayer les différents objectifs auxquels l'analyse de rentabilisation est utilisée.
**Scénario de changement minimal** — Pour évaluer les attentes en matière de performance financière minimale, préparez un scénario qui suppose le changement minimum attendu par rapport au statu quo. Ce scénario, en tant que pire des scénarios, constitue un soutien utile lors de l'obtention du mandat d'investissement dans la migration. Ce scénario modélise le degré minimum attendu de croissance des capacités et les changements minimaux pour d'autres quality-of-service besoins, tels que la disponibilité et la résilience. Le moindre changement entraîne le moindre coût et le moins d'inefficacité des ressources pour le modèle d'exploitation actuel.
**Scénario le plus probable** — Pour éclairer les décisions relatives à la stratégie du programme et à la priorisation, préparez le scénario qui reflète les attentes de l'entreprise. Ce scénario devrait inclure le pic probable de croissance ou de réduction de l'utilisation et les coûts de mise à niveau pour répondre à la demande de niveaux élevés de qualité de service (en particulier de disponibilité et de résilience) de la part de l'entreprise.
**Autres scénarios spécifiques** — Lorsqu'il est toujours nécessaire de formuler une hypothèse susceptible d'avoir un impact important sur l'analyse de rentabilisation, élaborez des scénarios pour lesquels l'hypothèse est vraie et ceux où elle ne l'est pas. Cependant, nous recommandons de limiter le nombre de ces scénarios alternatifs au strict minimum. La création de plus de trois à quatre scénarios au total ralentit la progression et devient coûteuse, confuse et difficile à gérer. Dans la mesure du possible, menez des expériences et efforcez-vous de supprimer les hypothèses plus générales.
## Valider et affiner l'infrastructure et le modèle de coûts de migration
Après avoir terminé l'analyse du portefeuille et préparé la conception et le dimensionnement de la cible Services AWS, affinez les estimations des coûts de fonctionnement pour le modèle d'exploitation actuel (COM) et le futur modèle d'exploitation (FOM) AWS pour chaque scénario. Il est généralement nécessaire d'affiner les estimations pour les éléments suivants :
+ **Coûts d'infrastructure COM** liés au serveur hôte de l'hyperviseur, au serveur bare metal, au stockage, aux périphériques réseau, à l'actualisation du matériel des dispositifs de sécurité, à l'installation et à la maintenance. Calculez-les à l'aide des prix réels et des niveaux de discount correspondant à la capacité requise pour le scénario.
+ **Coûts des centres de données COM et des installations colocalisées**, y compris l'espace, le refroidissement, l'alimentation, les racks, l'alimentation sans interruption (UPS), le câblage, les systèmes de sécurité physique, adaptés à la croissance et spécifiés pour répondre à la capacité, ainsi que les niveaux de haute disponibilité et de reprise après sinistre (DR) pour le scénario.
+ **Les coûts des services réseau COM**, y compris les coûts des liaisons WAN, des réseaux de diffusion de contenu et des réseaux privés virtuels (VPNs), calculés à l'aide des tarifs contractuels pour les besoins de connectivité, de bande passante, de débit et de latence du scénario.
+ **Coûts des applications COM et des logiciels d'infrastructure** basés sur les contrats existants afin de permettre l'augmentation ou la réduction de l'utilisation selon le scénario.
+ **Coûts des services AWS publics FOM**, y compris le support technique et les services gérés selon les besoins, en fonction de l'architecture de service raffinée, de la taille des instances, du modèle de tarification préféré, de l'utilisation prévue et de la volatilité de l'utilisation.
+ Les **licences d'applications FOM** sont basées sur la conception finale de l'application, la configuration de l'infrastructure exécutant les applications, la croissance dans le temps et les règles de transférabilité des licences.
+ **Estimations des coûts de migration et de modernisation de FOM**, affinées pour refléter le plan de base de la vague de migration du scénario, et détaillées pour indiquer les coûts de chaque charge de travail, en particulier pour celles devant être replateformes, rachetées ou refactorisées.
+ Les **coûts de mise hors service de la FOM**, y compris les estimations des coûts de radiation des actifs et de résiliation anticipée des contrats, révisés pour refléter le calendrier de mise hors service dans le plan de base de la vague de migration, la vérification des actifs pouvant être réaffectés et des actifs pouvant être réaffectés afin de minimiser les radiations, ainsi que le coût de cession des actifs physiques et des supports.
+ **Les coûts d'exécution de la migration parallèle** ont été affinés pour refléter le calendrier de chaque migration et de chaque mise hors service de service existant.
## Affiner la productivité informatique et les opérations informatiques et soutenir le modèle de valeur de l'efficacité
Comme dans le cas de l'analyse de rentabilisation directionnelle, il existe deux approches principales pour affiner et développer le modèle de valeur relatif aux opérations et au support informatiques. L'approche que vous choisissez varie selon que le COM est géré en interne ou avec des sous-traitants ou des services externalisés :
*Amélioration de la productivité des équipes internes*
Lorsque les opérations et le support informatiques sont gérés en interne, l'analyse de rentabilisation est axée sur les points suivants :
+ Identifier et quantifier les gains de productivité résultant de la migration et de toute automatisation opérationnelle incluse dans le champ d'application
+ Validation du fait que le temps libéré pour l'équipe interne peut être appliqué facilement et de manière productive à d'autres activités généralement à plus forte valeur ajoutée, offrant ainsi des opportunités de progression et une plus grande récompense à l'équipe et une valeur ajoutée à l'organisation
Évaluez le temps que chaque membre de l'équipe, quel que soit son rôle, consacre à ses diverses activités régulières, ainsi que des conseils sur la réduction attendue de la charge de travail pour les différentes activités.
Le tableau suivant fournit des indications initiales sur les niveaux habituels de réduction de la charge de travail par activité pour les tâches qui occupent la majeure partie des opérations informatiques et des efforts de soutien aux différents rôles de l'équipe. Le tableau comprend une description de la manière dont la productivité est atteinte.
**Note**
Les activités répertoriées sont généralement exécutées par des membres de l'équipe occupant plusieurs rôles différents, de sorte que les économies de productivité pour chaque tâche doivent être évaluées en fonction de l'ensemble des rôles de l'équipe. Par exemple, dans les équipes des opérations informatiques organisées par tour d'infrastructure (telles que le calcul, le stockage et le réseau), la planification et la budgétisation des dépenses d'investissement peuvent être communes aux responsables de chaque tour.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/application-portfolio-assessment-guide/detailed-business-case.html)
Le tableau suivant indique les économies attendues pour chaque niveau de réduction de la charge de travail.
| **Niveau** | **Attendu** |
| --- | --- |
| Très élevée | 85 % - 100 % |
| Élevée | 60 % à 90 % |
| Moyenne | 30 % - 70 % |
| Faible | 10 % - 35 % |
| Minimale | 0 % - 10 % |
Ces indicateurs constituent un point de départ pour évaluer les gains de productivité et les inclure dans l'analyse de rentabilisation détaillée. Les gains de productivité réels varient en fonction de la situation spécifique. Il peut être utile de calculer les économies de productivité à la fois au point médian et à l'extrémité inférieure des fourchettes afin d'estimer des scénarios classiques et prudents.
Au fur et à mesure que le programme progresse, il est utile de saisir des données réelles sur le temps consacré à chaque activité par rôle. Ces données constituent une base améliorée pour estimer les opérations et soutiennent les coûts des nouveaux projets et des extensions de services.
*Opérations informatiques externalisées et réduction des coûts de support*
[Lorsque les opérations et le support informatiques sont principalement externalisés ou gérés par des sous-traitants, la répartition des coûts pour le futur modèle d'exploitation (FOM) peut être préparée en demandant des devis aux AWS partenaires qui proposent des solutions de services gérés, y compris AWS dirigées par des partenaires AWS Managed Services (AMS).](https://aws.amazon.com/managed-services/partners/) Vous pouvez également contacter votre responsable de AWS compte et demander un prix pour AMS directement, comme décrit dans la sous-section sur l'intégration de l'[optimisation des coûts opérationnels dans](directional-business-case.md#building-operational-cost-optimization) la section [Création d'une analyse de rentabilisation directionnelle](directional-business-case.md).
Pour l'analyse de rentabilisation détaillée, remplacez tout chiffre de référence par un devis basé sur la facture de AWS services révisée et la consommation de service prévue, le package AMS et toutes les options nécessaires, ainsi que le niveau de service requis. Le coût comportera une composante de mise en œuvre unique et un taux d'exécution basé sur la consommation.
Incluez toutes les opérations informatiques restantes, le support qui doit être conservé pour tout service qui ne sera pas migré et un coût unique en cas de pénalités contractuelles (par exemple, en cas de résiliation anticipée). AWS
## Développer le modèle de valeur de la résilience
Sur AWS, vous pouvez créer un large éventail d'architectures de haute disponibilité, de reprise après sinistre et tolérantes aux pannes. La tarification basée sur la consommation signifie que les services ne sont facturés que lorsqu'ils sont utilisés. Ensemble, ces deux facteurs fournissent un rapport coût-performance exceptionnel en termes de résilience.
En outre, AWS les clients l'utilisent pour améliorer la résilience de leurs charges de travail. L'[enquête IDC 2018](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) donne des exemples de clients participants qui ont enregistré 73 % de pannes en moins par an, une réduction de 58 % du temps moyen de rétablissement (MTTR) et une réduction de 94 % de la perte de productivité. La même enquête a montré que les avantages financiers découlant d'une résilience accrue étaient 50 % supérieurs aux avantages liés à la réduction des coûts de l'infrastructure informatique.
En outre, une résilience accrue est atteinte grâce à la modernisation du cycle de développement logiciel des applications. Lorsque des CI/CD pipelines avec automatisation des tests sont introduits pour améliorer l'agilité de l'entreprise, les défauts logiciels sont détectés plus tôt dans le cycle de développement, ce qui réduit considérablement les coûts de maintenance des logiciels.
**Pour évaluer et inclure cette valeur dans l'analyse de rentabilisation, commencez par travailler avec les responsables de l'entreprise d'applications afin de vous faire une idée des *avantages totaux liés* à chaque charge de travail à migrer.**Cela peut inclure les éléments suivants :
+ Le nombre, la durée moyenne et la nature des interruptions de service :
+ Parmi les interruptions de service, on peut citer les pannes, les ralentissements des performances, le dépassement des délais de traitement par lots et de maintenance planifiés, les bogues dans les fonctions clés et les restrictions d'accès pendant les périodes de pointe.
+ Impact sur le chiffre d'affaires des interruptions de services générateurs de revenus, tels que les systèmes de commerce électronique :
+ Le nombre probable de transactions qui ne pourront pas être effectuées en raison d'interruptions de service, sur la base du temps d'interruption et des taux de transaction
+ Valeur moyenne de chaque transaction affectée
+ Le coût supplémentaire du temps consacré aux ingénieurs de support pour résoudre les défauts des systèmes de production par rapport au coût de leur découverte plus tôt dans le processus de développement
+ Impact sur la productivité des utilisateurs internes et le coût du temps perdu
Évaluez ensuite la réduction attendue et plus prudente du temps perdu en raison des interruptions de service**** que devrait entraîner une résilience accrue. Par exemple, pensez à inclure les éléments suivants :
+ Réduction du nombre de pannes et du MTTR grâce à des architectures de haute disponibilité et à des objectifs de temps de restauration (RTO) et de point de reprise (RPO) améliorés
+ Réduction des ralentissements, élimination de la limitation des capacités et prévention des dépassements de traitement par lots, grâce à des fonctionnalités telles que la mise à l'échelle automatique
+ Réduction du nombre de bogues d'application découverts uniquement en production, grâce à la mise en œuvre de CI/CD pipelines et à des tests de régression automatisés sur l'infrastructure mise en place et désactivée afin de minimiser les coûts
Réunissez-les pour le portefeuille d'applications à migrer et à moderniser, et calculez les valeurs commerciales attendues et plus prudentes pour chaque année du dossier. Les avantages devraient augmenter conformément au calendrier de migration, puis augmenter en volume en fonction des attentes de croissance de l'utilisation des applications contributrices.
## Développez le modèle de valeur de l'agilité commerciale
L'agilité commerciale est la principale raison pour laquelle AWS les clients migrent AWS. L'[enquête menée par IDC auprès des AWS clients en 2018](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) a indiqué que pour eux, les avantages liés à l'agilité commerciale représentaient 47 % du total des avantages mesurés et plus de cinq fois les avantages découlant de la réduction des coûts d'infrastructure.
Il est difficile de prévoir avec précision tous les avantages en termes d'agilité commerciale qui découleront de toute transformation. Toutefois, en vous concentrant sur les applications qui prennent en charge un grand nombre d'utilisateurs ou qui sont des sources de différenciation commerciale, vous pouvez modéliser et inclure une partie importante de cet avantage dans l'analyse de rentabilisation détaillée de base.
Au fur et à mesure de la migration, affinez et étendez progressivement le modèle de valeur de l'agilité commerciale à mesure que de nouveaux avantages deviennent quantifiables. Cela permet de maintenir la pertinence de l'analyse de rentabilisation, de sorte qu'elle puisse être utilisée comme principal outil d'aide à la décision pour orienter le programme.
Pour créer le modèle de valeur de l'agilité commerciale, suivez les conseils suivants :
+ Sélectionnez les charges de travail susceptibles d'améliorer le plus les performances de l'entreprise, telles que :
+ Charges de travail génératrices de revenus
+ Charges de travail liées aux opérations commerciales susceptibles de générer des gains d'efficacité et de réduire les coûts pour l'entreprise
+ Outils de productivité d'entreprise prenant en charge de larges bases d'utilisateurs
+ Pour des charges de travail génératrices de revenus et d'efficacité, procédez comme suit :
+ Procédez à une évaluation réaliste et plus prudente de la croissance du chiffre d'affaires ou de l'efficacité opérationnelle que les mises à niveau majeures et mineures des applications sont susceptibles de générer.
+ Estimez le nombre accru de versions majeures et mineures par an qui AWS permettent d'accélérer le développement des applications et de réduire le temps de déploiement de l'infrastructure. Certaines mesures de base à cet égard sont fournies dans le rapport IDC.
+ Calculez les attentes réalistes et plus prudentes en matière de prestations. Cartographiez-les au cours de la période couverte par l'analyse de rentabilisation, en tenant compte de la possibilité d'atteindre une efficacité maximale quelque temps après la migration des charges de travail respectives.
+ Pour les outils de productivité d'entreprise, procédez comme suit :
+ Procédez à une évaluation réaliste et plus prudente des économies de temps que les mises à niveau majeures et mineures des applications sont susceptibles de générer.
+ Estimez le coût moyen du temps et des efforts des personnes pour l'ensemble de la base d'utilisateurs concernée.
+ Utilisez les chiffres relatifs à l'augmentation de la fréquence des versions majeures et mineures, et calculez les avantages sur la durée de l'analyse de rentabilisation.
Étant donné que l'augmentation de la productivité des développeurs et la réduction du temps de lancement ne nécessitent aucune ressource supplémentaire, ajoutez les bénéfices nets pour chaque charge de travail dans le modèle de flux de trésorerie de l'analyse de rentabilisation pour les inclure dans les calculs actualisés du flux de trésorerie, de la valeur actualisée, du retour sur investissement, du MIRR et du remboursement.