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.

# Accélération de la découverte et planification initiale
<a name="portfolio-discovery-initial-planning"></a>

Cette première étape de l'évaluation du portefeuille se concentre sur les étapes initiales d'obtention et d'analyse des données au niveau du portefeuille. L'objectif principal est d'identifier les moteurs commerciaux et de collecter des données générales à partir des applications et de l'infrastructure afin d'obtenir une première vue du portefeuille. Ces données incluent des attributs techniques et commerciaux de haut niveau tels que les noms des applications, l'environnement, les versions des produits, la criticité, les valeurs de performance, etc., comme décrit dans la section sur les [exigences en matière de données](understanding-initial-assessment-data-requirements.md). L'achèvement de cette étape est essentiel pour comprendre la portée du projet, identifier les candidats initiaux à la migration et étayer l'analyse de rentabilisation.

## Principaux résultats de cette étape
<a name="discovery-outcomes"></a>
+ Facteurs commerciaux, résultats, objectifs et principes directeurs techniques documentés.
+ Inventaire initial des applications et de l'infrastructure, et identification des lacunes dans les données. Il s'agit d'une première vue du portefeuille qui sera réitérée et affinée ultérieurement.
+ Une analyse de rentabilisation directionnelle et une estimation du coût de la migration.
+ Une liste des candidats à la migration initiale (par exemple, trois à cinq candidatures).
+ Prochaines étapes définies.

# Comprendre les exigences en matière de données d'évaluation initiale
<a name="understanding-initial-assessment-data-requirements"></a>

La collecte de données peut prendre beaucoup de temps et devenir un obstacle lorsque l'on ne sait pas exactement quelles données sont nécessaires et quand elles sont nécessaires. L'essentiel est de comprendre l'équilibre entre ce qui est trop peu de données et ce qui constitue trop de données pour les résultats de cette étape. Pour vous concentrer sur les données et le niveau de fidélité requis pour cette première étape de l'évaluation du portefeuille, adoptez une approche itérative de collecte de données.

## Sources de données et exigences en matière de données
<a name="data-sources-data-requirements"></a>

La première étape consiste à identifier vos sources de données. Commencez par identifier les principales parties prenantes de votre organisation qui peuvent répondre aux exigences en matière de données. Il s'agit généralement de membres des équipes de gestion des services, des opérations, de planification des capacités, de surveillance et de support, ainsi que des propriétaires des applications. Organisez des sessions de travail avec les membres de ces groupes. Communiquez les exigences en matière de données et obtenez une liste des outils et de la documentation existante qui peuvent fournir les données.

Pour guider ces conversations, utilisez les questions suivantes :
+ Dans quelle mesure l'inventaire actuel de l'infrastructure et des applications est-il précis et à jour ? Par exemple, en ce qui concerne la base de données de gestion des configurations d'entreprise (CMDB), savons-nous déjà où se situent les lacunes ?
+ Disposons-nous d'outils et de processus actifs qui maintiennent la CMDB (ou équivalent) à jour ? Dans l'affirmative, à quelle fréquence est-il mis à jour ? Quelle est la date de dernière actualisation ?
+ L'inventaire actuel, tel que la CMDB, contient-il un mappage ? application-to-infrastructure Chaque actif d'infrastructure est-il associé à une application ? Chaque application est-elle mappée à l'infrastructure ?
+ L'inventaire contient-il un catalogue de licences et de contrats de licence pour chaque produit ?
+ L'inventaire contient-il des données de dépendance ? Notez l'existence de données de communication telles que serveur à serveur, application à application, application ou serveur à base de données.
+ Quels autres outils pouvant fournir des informations sur les applications et les infrastructures sont disponibles dans l'environnement ? Notez l'existence d'outils de performance, de surveillance et de gestion qui peuvent être utilisés comme source de données.
+ Quels sont les différents sites, tels que les centres de données, hébergeant nos applications et notre infrastructure ?

Une fois que vous aurez répondu à ces questions, dressez la liste des sources de données que vous avez identifiées. Attribuez ensuite un niveau de fidélité, ou un niveau de confiance, à chacun d'entre eux. Les données validées récemment (dans les 30 jours) à partir de sources programmatiques actives, telles que des outils, présentent le plus haut niveau de fidélité. Les données statiques sont considérées comme étant moins fidèles et moins fiables. Les exemples de données statiques sont les documents, les classeurs, les jeux de données mis à jour CMDBs manuellement ou tout autre ensemble de données non géré par programmation, ou dont la date de dernière actualisation remonte à plus de 60 jours. 

Les niveaux de fidélité des données présentés dans le tableau suivant sont fournis à titre d'exemple. Nous vous recommandons d'évaluer les exigences de votre organisation en termes de tolérance maximale aux hypothèses et aux risques associés afin de déterminer quel est le niveau de fidélité approprié. Dans le tableau, les connaissances institutionnelles font référence à toute information sur les applications et l'infrastructure qui n'est pas documentée.


| **Sources de données** | **Niveau de fidélité** | **Couverture du portefeuille** | **Commentaires** | 
| --- |--- |--- |--- |
| Connaissances institutionnelles | Faible - Jusqu'à 25 % des données exactes, 75 % des valeurs supposées ou des données datent de plus de 150 jours. | Faible | Rare, axé sur les applications critiques | 
| Base de connaissances | Moyenne-faible : 35 à 40 % des données exactes, 65 à 60 % des valeurs supposées ou des données datent de 120 à 150 jours. | Moyenne | Maintenu manuellement, niveaux de détail incohérents | 
| CMDB | Moyen : environ 50 % des données exactes, environ 50 % des valeurs supposées ou des données datent de 90 à 120 jours. | Moyenne | Contient des données provenant de sources mixtes, plusieurs lacunes | 
| VMware Exportations vers vCenter | Moyen—élevé : 75 à 80 % des données exactes, 25 à 20 % des valeurs supposées ou des données datent de 60 à 90 jours. | Élevée | Couvre 90 % du parc virtualisé | 
| Surveillance des performances des applications | Élevé - Données généralement précises, environ 5 % des valeurs supposées ou des données datent de 0 à 60 jours. | Faible | Limité aux systèmes de production critiques (couvre 15 % du portefeuille d'applications) | 

Les tableaux suivants précisent les attributs de données obligatoires et facultatifs pour chaque classe d'actifs (applications, infrastructure, réseaux et migration), l'activité spécifique (inventaire ou analyse de rentabilisation) et la fidélité des données recommandée pour cette étape de l'évaluation. Les tableaux utilisent les abréviations suivantes :
+ R, pour obligatoire
+ (D), pour l'analyse de rentabilisation directionnelle, requise pour les comparaisons du coût total de possession (TCO) et les analyses de rentabilisation directionnelles
+ (F), pour une analyse de rentabilisation directionnelle complète, requise pour la comparaison du coût total de possession et des analyses de rentabilisation directionnelles incluant les coûts de migration et de modernisation
+ O, en option
+ N/A, car non applicable

**Applications**


| **Nom d'attribut** | **Description** | **Inventaire et priorisation** | **Affaire de rentabilisation** | **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 (D) | É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 (D) | Moyenne-élevée\$1 | 
| Est-ce que COTS ? | Oui ou non Qu'il s'agisse d'une application commerciale ou d'un développement interne | R | R (D) | Moyenne-élevée\$1 | 
| Produit et version COTS | Nom et version du produit logiciel commercial  | R | R (D) | Moyenne | 
| Description | Fonction et contexte principaux de l'application | R | O | Moyenne | 
| Criticité | Par exemple, une application stratégique ou génératrice de revenus, ou le soutien d'une fonction critique | R | O | Moyenne-élevée\$1 | 
| Type | Par exemple, base de données, gestion de la relation client (CRM), application Web, multimédia, service informatique partagé | R | O | Moyenne | 
| Environnement | Par exemple, production, pré-production, développement, test, bac à sable | R | R (D) | Moyenne-élevée\$1 | 
| 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 (D) | Moyenne-élevée\$1 | 
| 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) | O | O | Moyenne-basse\$1 | 
| Cartographie des infrastructures | Mappage vers les actifs and/or virtuels physiques qui constituent l'application | O | O | Moyenne | 
| Licence | Type de licence logicielle standard (par exemple, Microsoft SQL Server Enterprise) | O | R | Moyenne-élevée\$1 | 
| Cost | Coûts de licence logicielle, d'exploitation des logiciels et de maintenance | N/A | O | Moyenne | 

**Infrastructures**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **Nom de l'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 | O | Moyenne-élevée\$1 | 
| Nom DNS (nom de domaine complet, ou FQDN) | Nom du DNS | O | O | Moyenne | 
| Adresse IP et masque réseau | Adresses IP and/or publiques internes | R | O | Moyenne-élevée\$1 | 
| Type de ressource | Serveur physique ou virtuel, hyperviseur, conteneur, appareil, instance de base de données, etc. | R | R | Moyenne-élevée\$1 | 
| Nom du produit | Fournisseur commercial et nom du produit (par exemple VMware ESXi, IBM Power Systems, Exadata) | R | R | Moyenne | 
| Système d’exploitation | Par exemple, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Moyenne-élevée\$1 | 
| Configuration | Processeur alloué, nombre de cœurs, nombre de threads par cœur, mémoire totale, stockage, cartes réseau | R | R | Moyenne-élevée\$1 | 
| Utilisation | Pic et moyenne du processeur, de la mémoire et du stockage. Débit des instances de base de données. | R | O | Moyenne-élevée\$1 | 
| Licence | Type de licence de produit (par exemple, RHEL Standard) | R | R | Moyenne | 
| 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 (D) | Moyenne | 
| Cartographie des applications | Applications ou composants d'application qui s'exécutent dans cette infrastructure | O | O | Moyenne | 
| 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 rackspace et les frais généraux des centres de données | N/A | O | Moyenne-élevée\$1 | 

**Réseaux**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **Nom de l'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) | O | R | Moyenne | 
| Utilisation des liens | Utilisation maximale et moyenne, transfert de données sortants (Go/mois) | O | R | Moyenne | 
| Latence (ms) | Latence actuelle entre les sites connectés. | O | O | Moyenne | 
| Cost | Coût actuel par mois | N/A | O | Moyenne | 

**Migration**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **Nom de l'attribut** | **Description** | **Inventaire et priorisation** | **Affaire de rentabilisation** | **Niveau de fidélité recommandé (minimum)** | 
| Réhéberger | Effort du client et du partenaire pour chaque charge de travail (jours-personnes), taux de coûts par jour pour les clients et les partenaires, coût des outils, nombre de charges de travail | N/A | R (F) | Moyenne-élevée\$1 | 
| Recréation de plateforme | Effort du client et du partenaire pour chaque charge de travail (jours-personnes), taux de coûts par jour pour les clients et les partenaires, nombre de charges de travail | N/A | R (F) | Moyenne-élevée\$1 | 
| Refactoriser | Effort du client et du partenaire pour chaque charge de travail (jours-personnes), taux de coûts par jour pour les clients et les partenaires, nombre de charges de travail | N/A | O | Moyenne-élevée\$1 | 
| Mise hors service | Nombre de serveurs, coût moyen de mise hors service | N/A | O | Moyenne-élevée\$1 | 
| Zone d'atterrissage | Réutilisation de l'existant (Y/N), liste des AWS régions nécessaires, coût | N/A | R (F) | Moyenne-élevée\$1 | 
| Les gens et le changement | Nombre d'employés à former aux opérations et au développement du cloud, coût de la formation par personne, coût du temps de formation par personne | N/A | R (F) | Moyenne-élevée\$1 | 
| Duration | Durée de la migration de la charge de travail visée (mois) | O | R (F) | Moyenne-élevée\$1 | 
| Coût parallèle | Période et taux auxquels les coûts tels quels peuvent être supprimés pendant la migration | N/A | O | Moyenne-élevée\$1 | 
| Période et rythme auxquels les AWS produits et services, ainsi que les autres coûts d'infrastructure, sont introduits pendant la migration | N/A | O | Moyenne-élevée\$1 | 

## Évaluation du besoin d'outils de découverte
<a name="discovery-tooling"></a>

Votre organisation a-t-elle besoin d'outils de découverte ? L'évaluation du portefeuille nécessite des up-to-date données hautement fiables sur les applications et l'infrastructure. Les étapes initiales de l'évaluation du portefeuille peuvent utiliser des hypothèses pour combler les lacunes dans les données. 

Cependant, au fur et à mesure des progrès, les données haute fidélité permettent de créer des plans de migration réussis et d'estimer correctement l'infrastructure cible afin de réduire les coûts et de maximiser les avantages. Il réduit également les risques en permettant des implémentations qui tiennent compte des dépendances et en évitant les pièges liés à la migration. Le principal cas d'utilisation des outils de découverte dans les programmes de migration vers le cloud est de réduire les risques et d'accroître le niveau de confiance dans les données par les moyens suivants :
+ Collecte de données automatisée ou programmatique, aboutissant à des données validées et hautement fiables
+ Accélération du taux d'obtention des données, amélioration de la vitesse des projets et réduction des coûts
+ Niveaux accrus d'exhaustivité des données, y compris les données de communication et les dépendances qui ne sont généralement pas disponibles dans CMDBs
+ Obtenir des informations telles que l'identification automatique des applications, l'analyse du coût total de possession, les taux d'exécution prévus et les recommandations d'optimisation
+ Planification des vagues de migration en toute confiance

En cas d'incertitude quant à l'existence de systèmes à un emplacement donné, la plupart des outils de découverte peuvent scanner les sous-réseaux du réseau et découvrir les systèmes qui répondent au ping ou aux requêtes SNMP (Simple Network Management Protocol). Notez que toutes les configurations de réseau ou de système n'autorisent pas le trafic ping ou SNMP. Discutez de ces options avec votre réseau et vos équipes techniques.

Les étapes ultérieures de l'évaluation et de la migration du portefeuille d'applications reposent en grande partie sur des informations précises de mappage des dépendances. Le mappage des dépendances permet de comprendre l'infrastructure et la configuration qui seront requises AWS (par exemple, les groupes de sécurité, les types d'instances, le placement des comptes et le routage réseau). Cela permet également de regrouper les applications qui doivent se déplacer en même temps (telles que les applications qui doivent communiquer sur des réseaux à faible latence). En outre, la cartographie des dépendances fournit des informations permettant de faire évoluer l'analyse de rentabilisation.

Lorsque vous choisissez un outil de découverte, il est important de prendre en compte toutes les étapes du processus d'évaluation et d'anticiper les exigences en matière de données. Les lacunes dans les données peuvent devenir des bloqueurs. Il est donc essentiel de les anticiper en analysant les futures exigences en matière de données et les sources de données. L'expérience sur le terrain montre que la plupart des projets de migration bloqués disposent d'un ensemble de données limité dans lequel les applications concernées, l'infrastructure associée et leurs dépendances ne sont pas clairement identifiées. Ce manque d'identification peut entraîner des mesures, des décisions et des retards incorrects. L'obtention up-to-date de données est la première étape d'un projet de migration réussi.

*Comment sélectionner un outil de découverte ?*

Plusieurs outils de découverte disponibles sur le marché offrent des fonctionnalités et des capacités différentes. Tenez compte de vos besoins. Et choisissez l'option la plus appropriée pour votre organisation. Les facteurs les plus courants lors du choix d'un outil de découverte pour les migrations sont les suivants :

*Sécurité*
+ Quelle est la méthode d'authentification pour accéder au référentiel de données de l'outil ou aux moteurs d'analyse ? 
+ Qui peut accéder aux données et quels sont les contrôles de sécurité pour accéder à l'outil ? 
+ Comment l'outil collecte-t-il les données ? A-t-il besoin d'informations d'identification dédiées ? 
+ Quels sont les identifiants et le niveau d'accès dont l'outil a besoin pour accéder à mes systèmes et obtenir des données ? 
+ Comment les données sont-elles transférées entre les composants de l'outil ? 
+ L'outil prend-il en charge le chiffrement des données au repos et en transit ? 
+ Les données sont-elles centralisées dans un seul composant à l'intérieur ou à l'extérieur de mon environnement ? 
+ Quelles sont les exigences en matière de réseau et de pare-feu ? 

Assurez-vous que les équipes de sécurité participent aux premières discussions sur les outils de découverte.

*La souveraineté des données*
+ Où sont stockées et traitées les données ? 
+ L'outil utilise-t-il un modèle de logiciel en tant que service (SaaS) ? 
+ Est-il possible de conserver toutes les données dans les limites de mon environnement ? 
+ Les données peuvent-elles être filtrées avant qu'elles ne quittent les limites de mon organisation ? 

Tenez compte des besoins de votre organisation en termes d'exigences en matière de résidence des données.

*Architecture*
+ Quelle est l'infrastructure requise et quels en sont les différents composants ?
+ Plusieurs architectures sont-elles disponibles ? 
+ L'outil permet-il d'installer des composants dans des zones de sécurité verrouillées ?

*Performances*
+ Quel est l'impact de la collecte de données sur mes systèmes ? 

*Compatibilité et champ d'application*
+ L'outil est-il compatible avec la totalité ou la plupart de mes produits et versions ? Consultez la documentation de l'outil pour vérifier les plateformes prises en charge par rapport aux informations actuelles concernant votre champ d'application. 
+ La plupart de mes systèmes d'exploitation sont-ils pris en charge pour la collecte de données ? Si vous ne connaissez pas les versions de votre système d'exploitation, essayez de limiter la liste des outils de découverte à ceux qui proposent le plus grand nombre de systèmes pris en charge.

*Méthodes de collecte*
+ L'outil nécessite-t-il l'installation d'un agent sur chaque système cible ?
+ Prend-il en charge les déploiements sans agent ? 
+ Les fonctionnalités avec agent et sans agent offrent-elles les mêmes fonctionnalités ? 
+ En quoi consiste le processus de collecte ?

*Fonctions*
+ Quelles sont les fonctionnalités disponibles ? 
+ Peut-il calculer le coût total de possession (TCO) et le taux de AWS Cloud fonctionnement estimé ? 
+ Soutient-il la planification de la migration ? 
+ Mesure-t-il les performances ? 
+ Peut-il recommander une AWS infrastructure cible ? 
+ Effectue-t-il un mappage des dépendances ? 
+ Quel niveau de mappage des dépendances fournit-il ? 
+ Fournit-il un accès à l'API ? (par exemple, peut-on y accéder par programmation pour obtenir des données ?)

Pensez aux outils dotés de puissantes fonctions de mappage des dépendances des applications et des infrastructures et à ceux qui peuvent déduire des applications à partir de modèles de communication. 

*Coût*
+ Qu'est-ce que le modèle de licence ? 
+ Quel est le coût de la licence ? 
+ Le prix est-il valable pour chaque serveur ? S'agit-il d'une tarification échelonnée ? 
+ Existe-t-il des options avec des fonctionnalités limitées qui peuvent être licenciées à la demande ? 

Les outils de découverte sont généralement utilisés tout au long du cycle de vie des projets de migration. Si votre budget est limité, considérez au moins 6 mois. Cependant, l'absence d'outils de découverte entraîne généralement une augmentation des efforts manuels et des coûts internes.

*Modèle de support*
+ Quels sont les niveaux de support fournis par défaut ? 
+ Un plan de support est-il disponible ? 
+ Quels sont les délais de réponse aux incidents ?

*Services professionnels*
+ Le fournisseur propose-t-il des services professionnels pour analyser les résultats de découverte ? 
+ Peuvent-ils couvrir les éléments de ce guide ? 
+ Existe-t-il des remises ou des offres groupées pour les services Tooling \$1 ?

**Astuce**  
Pour rechercher et évaluer les outils de découverte, utilisez le site [Discovery, Planning, and Recommendation](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/).

*Fonctionnalités recommandées pour l'outil de découverte*

Pour éviter de provisionner et de combiner des données provenant de plusieurs outils au fil du temps, un outil de découverte doit couvrir les fonctionnalités minimales suivantes : 
+ **Logiciel** — L'outil de découverte doit être capable d'identifier les processus en cours d'exécution et les logiciels installés.
+ **Cartographie des dépendances** — Il doit être capable de collecter des informations de connexion réseau et de créer des cartes de dépendance entrantes et sortantes des serveurs et des applications en cours d'exécution. En outre, l'outil de découverte doit être capable de déduire des applications provenant de groupes d'infrastructures en fonction des modèles de communication.
+ **Découverte du profil et de la configuration** — Il doit être en mesure de signaler le profil de l'infrastructure tel que la famille de processeurs (par exemple, x86, PowerPC), le nombre de cœurs de processeur, la taille de la mémoire, le nombre de disques et leur taille, ainsi que les interfaces réseau.
+ **Découverte du stockage réseau** — Il doit être capable de détecter et de profiler les partages réseau à partir du stockage rattaché au réseau (NAS).
+ **Performances** — Il doit être en mesure de signaler l'utilisation maximale et moyenne du processeur, de la mémoire, du disque et du réseau.
+ **Analyse des lacunes** — Elle doit être en mesure de fournir des informations sur la quantité et la fidélité des données.
+ **Analyse du réseau** — Il doit être capable de scanner les sous-réseaux du réseau et de découvrir des actifs d'infrastructure inconnus.
+ **Rapports** — Il doit être en mesure de fournir l'état de la collecte et de l'analyse.
+ **Accès à l'API** — Il devrait être en mesure de fournir des moyens programmatiques pour accéder aux données collectées.

*Fonctionnalités supplémentaires à prendre en compte*
+ **Analyse du coût total de possession** pour fournir une comparaison des coûts entre le coût actuel sur site et le coût prévu AWS .
+ **Analyse des licences et recommandations d'optimisation** pour les systèmes Microsoft SQL Server et Oracle dans les scénarios de réhébergement et de replateforme.
+ **Recommandation de stratégie de migration** (l'outil de découverte peut-il émettre des recommandations de type R de migration par défaut en fonction de la technologie actuelle ?)
+ **Exportation de l'inventaire** (au format CSV ou similaire)
+ **Recommandation de dimensionnement correct** (par exemple, peut-elle cartographier une AWS infrastructure cible recommandée ?)
+ **Visualisation des dépendances** (par exemple, le mappage des dépendances peut-il être visualisé en mode graphique ?)
+ **Vue architecturale** (par exemple, les diagrammes architecturaux peuvent-ils être produits automatiquement ?)
+ **Priorisation des applications** (peut-elle attribuer du poids ou de la pertinence aux attributs de l'application et de l'infrastructure afin de créer des critères de priorisation pour la migration ?)
+ **Planification des vagues** (par exemple, groupes d'applications recommandés et possibilité de créer des plans de vagues de migration)
+ **Estimation des coûts de migration** (estimation de l'effort de migration)

*Considérations relatives au déploiement*

Après avoir sélectionné et acheté un outil de découverte, posez-vous les questions suivantes pour engager des conversations avec les équipes responsables du déploiement de l'outil dans votre organisation :
+ Les serveurs ou les applications sont-ils gérés par un tiers ? Cela pourrait dicter les équipes à impliquer et les processus à suivre.
+ Quel est le processus de haut niveau pour obtenir l'autorisation de déployer des outils de découverte ?
+ Quel est le principal processus d'authentification pour accéder à des systèmes tels que les serveurs, les conteneurs, le stockage et les bases de données ? Les informations d'identification du serveur sont-elles locales ou centralisées ? Quelle est la procédure à suivre pour obtenir des informations d'identification ? Des informations d'identification seront nécessaires pour collecter des données à partir de vos systèmes (par exemple, des conteneurs, des serveurs virtuels ou physiques, des hyperviseurs et des bases de données). Il peut être difficile d'obtenir des informations d'identification permettant à l'outil de découverte de se connecter à chaque ressource, en particulier lorsque ces ressources ne sont pas centralisées.
+ Quelles sont les grandes lignes des zones de sécurité du réseau ? Les diagrammes de réseau sont-ils disponibles ?
+ Quelle est la procédure à suivre pour demander des règles de pare-feu dans les centres de données ?
+ Quels sont les accords de niveau de service d'assistance actuels (SLAs) relatifs aux opérations des centres de données (installation d'outils de découverte, demandes de pare-feu) ?

# Facteurs commerciaux et principes directeurs techniques
<a name="business-drivers-technical-guiding-principles"></a>

## Facteurs commerciaux
<a name="business-drivers"></a>

Que votre entreprise ait déjà décidé de passer au cloud ou soit sur le point de le faire, la définition et la documentation des facteurs commerciaux de la migration vers le cloud clarifieront les raisons de cette migration. Une fois les raisons documentées, vous pouvez définir ce qui sera migré et comment il sera migré. Cette activité est importante. Nous recommandons que cela ait lieu le plus tôt possible dans le processus afin d'informer et d'orienter les prochaines étapes. 

Identifiez les parties prenantes qui devraient participer à la discussion afin de documenter les facteurs déterminants. Généralement CxOs, les cadres supérieurs et les principaux leaders technologiques de l'organisation, ainsi que vos propres clients. Il est peu probable que vos clients prennent part à cette discussion, mais nous recommandons qu'une ou plusieurs personnes de votre organisation soient désignées pour représenter les points de vue et les objectifs de vos clients.

Les moteurs commerciaux doivent être liés à un indicateur qui peut être mesuré tout au long du processus de migration afin de valider si les résultats ont été atteints. Les objectifs stratégiques et les rapports annuels de l'entreprise peuvent servir de point de départ. 

Concentrez la conversation sur les objectifs de l'entreprise, en fonction des indicateurs existants et prévus, suite à la migration vers le cloud. Tenez compte des objectifs et des résultats commerciaux. Réfléchissez également à ce à quoi ressemble le succès à mesure que l'adoption du cloud augmente. 

Ensuite, déterminez le niveau d'importance pour chaque facteur. Quelles sont les priorités ? Quels sont les bénéfices attendus ? Comment les avantages favorisent-ils les objectifs et les résultats commerciaux ? Dans le contexte de l'évaluation du portefeuille d'applications, les réponses aideront à hiérarchiser les charges de travail pour la migration et à établir des principes directeurs techniques. Cependant, les moteurs commerciaux définiront et influenceront le programme de migration dans son ensemble.

## Principes directeurs techniques
<a name="technical-guiding-principles"></a>

Les principes directeurs techniques guident le choix de la stratégie de migration lors des étapes ultérieures de l'évaluation du portefeuille. À l'étape actuelle, l'objectif est de les identifier. 

Les principes directeurs peuvent être établis sous forme de décisions générales liées à la technologie et à l'approche dérivées des objectifs et des résultats commerciaux.

Par exemple, l'objectif principal d'une entreprise est de réduire ses coûts, et le résultat souhaité est de fermer un centre de données sur site à une date donnée dans un délai de 6 à 12 mois. Le principe directeur qui en résulte est de transférer et de transférer toutes les applications vers le cloud en utilisant une stratégie de migration de réhébergement ou de relocalisation chaque fois que cela est possible. Dans ce cas, l' lift-and-shiftapproche accélère les résultats de migration à court terme. Une fois que les applications ont quitté le centre de données sur site, l'entreprise peut se concentrer sur les principaux moteurs commerciaux afin d'optimiser ou de moderniser les charges de travail migrées.

Pour établir les principes directeurs techniques, commencez par analyser les moteurs commerciaux. Dressez une liste de technologies et de techniques qui permettront d'atteindre les objectifs et les résultats de l'entreprise. Ensuite, affinez la liste et attribuez un ordre de pertinence en fonction de l'adéquation ou des préférences pour obtenir le résultat souhaité.

Documenter et communiquer les principes directeurs aux personnes impliquées dans la planification et la réalisation de la migration. Soulignez les préoccupations et les conflits potentiels entre les principes et la mise en œuvre réelle.

Le tableau suivant fournit un exemple de moteurs commerciaux et de principes directeurs techniques.


| **Moteur commercial** | **Résultat** | **Métriques** | **Principe directeur technique** | 
| --- |--- |--- |--- |
| Accélérez l'innovation. | Compétitivité améliorée, agilité commerciale accrue | Nombre de déploiements par jour ou par mois, nouvelles fonctionnalités publiées par trimestre, scores de satisfaction client, nombre d'expériences | Refactorisez la différenciation des applications en utilisant les microservices et le modèle DevOps d'exploitation pour accroître l'agilité et la rapidité de mise sur le marché des nouvelles fonctionnalités. | 
| Réduisez les coûts d'exploitation et d'infrastructure. | Base de coûts élastique adaptée à l'offre et à la demande (payez pour ce que vous utilisez) | Variation des dépenses au fil du temps | 1. Réhébergez les applications en adaptant l'infrastructure à la bonne taille. 2. Supprimez les applications dont le taux d'utilisation est faible ou nul. | 
| Améliorez la résilience opérationnelle. | Temps de disponibilité amélioré, temps moyen de restauration réduit | SLAs, nombre d'incidents | 1. Reconfigurez les applications vers les versions les plus récentes et les mieux prises en charge du système d'exploitation. 2. Mettez en œuvre des architectures de haute disponibilité pour les applications critiques. | 
| Quittez le centre de données. | Fermeture du centre de données avant une date comprise entre 6 et 12 mois | Rapidité des migrations de serveurs | Réhébergez des applications à l'aide de la solution Cloud Migration Factory. | 
| Restez sur site, mais augmentez l'agilité et la résilience. | Compétitivité et disponibilité améliorées tout en restant sur site | Nombre de déploiements par jour ou par mois, lancement de nouvelles fonctionnalités par trimestre SLAs, nombre d'incidents | 1. Modernisez les systèmes en étendant leurs fonctionnalités dans le cloud.2. Évaluez pour le réhébergement ou la replateforme vers. AWS Outposts | 

# Lancement de la collecte de données
<a name="initiating-data-collection"></a>

La collecte de données est le processus de collecte de métadonnées à partir d'applications et d'infrastructures. Le processus est itératif à toutes les étapes de l'évaluation. À chaque étape, la quantité et la fidélité des données augmenteront. À ce stade, l'accent est mis sur la collecte de données générales qui peuvent aider à établir un inventaire initial. L'inventaire sera utilisé pour créer une analyse de rentabilisation directionnelle et pour identifier les candidats initiaux à la migration.

Une fois que les sources de données actuelles ont été identifiées, nous recommandons de recueillir des informations auprès du plus grand nombre de systèmes possible. Pour plus d'informations, consultez les [exigences en matière de données](understanding-initial-assessment-data-requirements.md) pour cette étape.

Cette approche a l'avantage de contribuer à mettre à jour la vision actuelle du portefeuille et les connaissances de l'organisation sur ses applications et services. Cela aide également à déterminer ce qui doit être déplacé. L'approche recommandée consiste à examiner les données existantes, telles que les sorties de la base de données de gestion des configurations (CMDB) et les systèmes de gestion des services informatiques (ITSM). Établissez ensuite une liste des actifs ciblés pour la collecte de données. Si votre organisation sait parfaitement ce qui est inclus dans le champ d'application de la migration et ce qui ne l'est pas, vous pouvez limiter la collecte de données aux systèmes concernés.

Lorsque vous créez votre portefeuille, tenez compte des applications et de leurs environnements ou du cycle de vie des versions logicielles. Par exemple, au lieu d'identifier une application de gestion de la relation client (CRM) et de spécifier qu'elle possède des environnements de test, de développement et de production, listez trois applications (par exemple, CRM-Test, CRM-Dev, CRM-Prod). Vous pouvez également utiliser le nom du CRM, mais attribuer un identifiant unique à chaque environnement et les présenter sous forme d'enregistrements distincts dans votre référentiel de données. Cela facilitera la planification et le suivi de la migration de ces environnements individuellement. Par exemple, vous souhaiterez peut-être d'abord migrer des environnements non liés à la production. En listant les instances de votre application en fonction de l'environnement, vous pouvez clairement gérer et gouverner leur transition.

Lors de la collecte de données, il peut y avoir une incertitude quant aux applications ou aux serveurs qui se trouvent dans un centre de données ou un emplacement source donné. Dans ces cas, il est utile d'obtenir des listes complètes et d'hyperviseurs à partir des outils de gestion existants. Par exemple, vous pouvez vous connecter à un hyperviseur pour obtenir des listes de machines virtuelles à cibler pour la collecte de données. 

Notez que le résultat initial, lors de la combinaison de sources de données existantes, peut être incomplet. L'essentiel est de réaliser une analyse des lacunes en termes de [données requises](understanding-initial-assessment-data-requirements.md) pour cette étape et de ce qui peut être obtenu à partir des sources existantes. Il est important de comparer le pourcentage d'exhaustivité au niveau de fidélité des données. Des niveaux d'exhaustivité plus élevés provenant de sources peu fidèles contiendront plusieurs hypothèses susceptibles de fausser l'analyse. Bien que cette étape de l'évaluation n'exige pas une fidélité maximale des données, nous recommandons que les sources de données soient au moins de moyenne à moyenne-haute fidélité. Comparez ces chiffres à la tolérance au risque de votre organisation, notamment en utilisant des hypothèses pour combler les lacunes dans les données. 

L'analyse des écarts vous aide à comprendre la quantité et la qualité des données avec lesquelles vous travaillez. L'analyse vous aide également à établir le niveau d'hypothèses qui doivent être formulées pour créer une analyse de rentabilisation directionnelle et hiérarchiser les applications à migrer. Les outils de découverte peuvent aider à combler les lacunes et à collecter des données de haute fidélité. Pour augmenter le niveau de confiance dans les données et accélérer les résultats de la migration, nous recommandons de déployer les outils de découverte le plus tôt possible. Il est également important d'agir rapidement, car les processus internes d'approvisionnement, de sécurité et de mise en œuvre des nouveaux outils peuvent prendre plusieurs semaines, voire plusieurs mois.

Nous recommandons d'établir un plan ou une cadence de communication et un mécanisme de contrôle du changement de portée à ce stade. Cela vous permet de tenir les parties prenantes informées afin qu'elles puissent planifier à l'avance et atténuer les risques. Pour des communications claires, il est essentiel de définir une source fiable unique pour le portefeuille d'applications et l'infrastructure associée. Évitez de conserver plusieurs systèmes d'enregistrement et listes d'applications et d'infrastructures. Conservez les données au même endroit (par exemple, une base de données, un outil ou une feuille de calcul) qui prend en charge le contrôle de version et la collaboration en ligne, et attribuez-leur un propriétaire.

# Priorisation et stratégie de migration
<a name="prioritization-and-migration-strategy"></a>

Un élément clé de la planification de la migration consiste à établir des critères de priorisation. Le but de cet exercice est de comprendre l'ordre dans lequel les applications seront migrées. La stratégie consiste à adopter une approche itérative et progressive pour faire évoluer le modèle de priorisation.

## Hiérarchisation des applications
<a name="prioritizing-applications"></a>

Cette étape de l'évaluation se concentre sur l'établissement de critères initiaux pour prioriser les charges de travail à faible risque et à faible complexité. Ces charges de travail sont de bons candidats pour les applications pilotes. L'utilisation de charges de travail peu risquées et peu complexes lors des migrations initiales réduit les risques et donne aux équipes la possibilité d'acquérir de l'expérience. Ces critères seront développés au cours des étapes d'évaluation ultérieures afin d'aligner la priorisation sur les moteurs commerciaux lors de la création du plan de vague de migration.

Les critères initiaux devraient donner la priorité aux applications présentant un petit nombre de dépendances, exécutées dans une infrastructure supportée par le cloud et issues d'environnements non liés à la production. Par exemple, les applications avec 0 à 3 dépendances sont prêtes à être réhébergées telles quelles dans un environnement de développement ou de test. Ces critères sont valables pour définir les applications pilotes et éventuellement les première et deuxième vagues de migration, en fonction du niveau de maturité de l'adoption du cloud et des niveaux de confiance. 

*Déterminer les critères initiaux à utiliser*

Sélectionnez 2 à 10 points de données à utiliser pour hiérarchiser vos premières charges de travail. Ces points de données proviennent de votre inventaire initial d'applications et d'infrastructures (voir la section sur la [collecte de données](initiating-data-collection.md)). 

Définissez ensuite un score, ou un poids, pour chaque valeur possible de chaque point de données. Par exemple, si l'attribut d'environnement est sélectionné et que les valeurs possibles sont production, développement et test, un score est attribué à chaque valeur, un nombre supérieur représentant une priorité plus élevée. Bien que cela soit facultatif, nous recommandons d'attribuer un facteur multiplicateur d'importance ou de pertinence à chaque point de données. Cette étape facultative fournit un facteur de différenciation de niveau supérieur pour mettre l'accent sur ce qui est le plus important, ce qui permet de maintenir l'alignement des critères au fur et à mesure que vous attribuez des scores aux valeurs.

Sur la base de la stratégie visant à prioriser les applications simples à faible risque pour les premières vagues de migration, le tableau suivant présente des exemples de sélection d'attributs et leurs attributions de valeur.


| **Attribut (point de données)** | **Valeurs possibles** | **Résultat (0-99)** | **Facteur multiplicateur de l'importance ou de la pertinence** | 
| --- |--- |--- |--- |
| Environnement | test | 60 | Haut (1 x) | 
| Développement | 40 | 
| Production | 20 | 
| Criticité commerciale | Faible | 60 | Haut (1 x) | 
| Moyenne | 40 | 
| Élevée | 20 | 
| Cadre réglementaire ou de conformité | Aucune | 60 | Haut (1 x) | 
| FedRAMP | 10 | 
| Support du système d'exploitation | Prêt pour le cloud | 60 | Moyen-élevé (0,8 x) | 
| Non pris en charge dans le cloud | 10 | 
| Nombre d'instances de calcul | 1 à 3 | 60 | Moyen-élevé (0,8 x) | 
| 4-10 | 40 | 
| 11 ou plus | 20 | 
| Stratégie de migration | Réhéberger | 70 | Moyen (0,6x) | 
| Recréation de plateforme | 30 | 
| Refactoriser ou réorganiser | 10 | 

Assurez-vous de sélectionner des attributs qui peuvent constituer des éléments de différenciation essentiels entre les applications. Dans le cas contraire, les critères se traduiront par le partage de la même priorité par de nombreuses charges de travail. Après avoir appliqué le modèle, nous vous recommandons de regarder en haut et en bas du classement obtenu pour voir si vous êtes d'accord. Si vous n'êtes pas généralement d'accord, vous pouvez revoir les critères que vous avez utilisés pour évaluer les charges de travail. 

Après avoir obtenu un classement, examinez la répartition des scores sur l'ensemble du portefeuille. Les scores eux-mêmes n'ont pas d'importance. C'est la différence entre les scores qui compte. Par exemple, vous pourriez constater que le score total le plus élevé est de 8 000 et le score le plus bas est de 800. Envisagez de tracer les scores obtenus sous forme d'histogramme afin de vérifier que vous avez une bonne distribution. La distribution idéale ressemble à une courbe en cloche standard, avec quelques charges de travail très prioritaires et quelques charges de travail très peu prioritaires. La majorité des candidatures se situeront quelque part entre les deux.

Un autre aspect clé de la priorisation initiale consiste à inclure les équipes internes ou les unités commerciales qui souhaitent adopter le cloud de manière précoce. Ils peuvent constituer un levier considérable pour obtenir un soutien commercial pour migrer une application donnée, en particulier au début. Si tel est le cas dans votre organisation, incluez l'attribut business unit dans le tableau précédent. Attribuez un score élevé aux unités commerciales qui sont prêtes à présenter leurs candidatures. L'utilisation de l'attribut business unit aidera à placer ces applications en haut de la liste.

Une fois que vous êtes d'accord avec le classement obtenu, sélectionnez les 5 à 10 meilleures applications. Il s'agira de vos premiers candidats à la migration de votre candidature. Affinez la liste afin de confirmer 3 à 5 candidatures. Cela vous permet d'adopter une approche ciblée lors de l'évaluation détaillée d'une application. Pour plus d'informations, consultez [la section Évaluation des applications prioritaires](prioritized-applications-assessment.md).

 

## Déterminer le type R pour la migration
<a name="migration-r-type"></a>

Le choix d'une stratégie de migration pour chaque application et l'infrastructure associée aura des répercussions sur la vitesse de migration, le coût et le niveau des avantages. Il est essentiel de déterminer la stratégie en fonction d'une combinaison équilibrée de facteurs, notamment les moteurs commerciaux, les principes directeurs techniques, les critères de priorisation et la stratégie commerciale.

Ces facteurs créent parfois des points de vue contradictoires. Par exemple, le principal moteur de la migration peut être l'innovation et l'agilité. Dans le même temps, il se peut que vous deviez réduire les coûts rapidement. La modernisation de toutes les applications concernées réduira les coûts à long terme, mais elle nécessitera un investissement initial plus important. Dans ce cas, l'une des approches consiste à migrer les applications en utilisant des stratégies nécessitant moins d'efforts, telles que le réhébergement ou la replateforme. Cela peut permettre des gains d'efficacité rapides et une réduction des coûts à court terme. Réinvestissez ensuite les économies réalisées dans la modernisation de l'application à un stade ultérieur et réduisez encore les coûts. 

Cependant, le fait de commencer par un réhébergement complet de toutes les applications retarde les avantages de la modernisation. L'essentiel est de trouver un équilibre entre les stratégies de migration afin que les applications stratégiques de l'entreprise soient priorisées en matière de modernisation, tandis que les autres applications puissent être réhébergées ou replateformes d'abord, puis modernisées.

*Comment définir une stratégie de migration pour vos applications ?*

À ce stade de l'évaluation, l'objectif est d'intégrer un modèle initial pour guider le choix de la stratégie de migration. Pour valider la stratégie de migration pour les applications initiales, utilisez le modèle conjointement avec les moteurs commerciaux et les critères de priorisation. La logique par défaut de l'arbre de décision vous aidera à déterminer le traitement initial du scope. Dans l'arborescence, les approches les plus complexes, telles que la refactorisation ou la réarchitecture, sont réservées à vos charges de travail stratégiques.

![\[Le processus de décision des 6 R décrit dans ce guide.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/application-portfolio-assessment-guide/images/6Rs-DecisionTree-baseModel.png)


Une version [draw.io](https://github.com/jgraph/drawio-desktop/releases) personnalisable de ce diagramme est disponible dans la section *[Pièces jointes](#attachments)*.

La première étape d'un modèle initial consiste à mettre à jour les facteurs commerciaux situés en haut de l'arborescence avec ceux définis par votre organisation. Appliquez ensuite l'arborescence aux composants de l'application plutôt qu'aux applications dans leur ensemble. Par exemple, dans le cas d'une application à trois niveaux comportant trois composants (interface, couche d'application et base de données), chaque composant doit transiter par l'arbre indépendamment et se voir attribuer une stratégie et un modèle spécifiques. En effet, dans certains cas, vous souhaiterez peut-être réhéberger ou replatformater un niveau donné et refactoriser (réorganiser) d'autres niveaux. 

L'attribution indépendante des composants vous permettra de définir une stratégie de migration pour l'infrastructure associée. La stratégie d'infrastructure peut être identique à celle du composant d'application qu'elle prend en charge, ou elle peut être différente. Par exemple, un composant d'application qui sera transformé en une nouvelle machine virtuelle dotée d'un système d'exploitation plus récent suivra la stratégie de replateforme tandis que la machine virtuelle actuelle qui l'héberge sera retirée. La stratégie de migration pour l'infrastructure est calculée en fonction de la stratégie choisie pour les composants de l'application.

Avant d'utiliser l'arbre de décision pour établir des stratégies de migration, testez la logique avec quelques applications et vérifiez si vous êtes généralement d'accord avec le résultat. L'arbre décisionnel à 6 R est un guide qui ne remplace pas l'analyse requise pour déterminer son exactitude. La logique de l'arborescence peut ne pas s'appliquer à des cas particuliers. Traitez ces cas comme des exceptions et passez outre à la décision dictée par l'arborescence en documentant la justification de la dérogation plutôt que de modifier la logique de l'arborescence. Cela permet d'éviter les versions multiples de l'arbre de décision, qui pourraient devenir difficiles à gérer. D'une manière générale, l'arbre doit être valide pour au moins 70 à 80 % des charges de travail. Pour le reste, il y aura des exceptions. Tout ajustement apporté à la logique de l'arbre, à ce stade de l'évaluation, doit être axé sur l'établissement d'un modèle initial. D'autres itérations et améliorations seront apportées au cours des étapes ultérieures, telles que l'[analyse du portefeuille et la planification de la migration](portfolio-analysis-migration-planning.md).

## Pièces jointes
<a name="attachments"></a>

[attachment.zip](samples/attachment.zip)

# Création d'une analyse de rentabilisation directionnelle
<a name="directional-business-case"></a>

Les parties prenantes de l'ensemble de l'entreprise doivent comprendre et accepter l'analyse de rentabilisation en faveur de la transformation à chaque étape du processus. 

Au début, il est important de démontrer rapidement la valeur potentielle d'un programme de migration, afin de pouvoir obtenir les ressources nécessaires à la planification et à la mise en place du programme. L'analyse de rentabilisation directionnelle est conçue pour apporter une confiance raisonnable quant à l'obtention d'une valeur commerciale convaincante avec les données limitées qui peuvent être collectées à un stade précoce.

Une fois le programme établi, l'analyse de rentabilisation est développée plus avant. Le cas détaillé fournit une plus grande précision, une image plus complète de la valeur du programme et un aperçu des priorités de planification. Il définit et quantifie les résultats commerciaux prévus auxquels l'organisation adhère, et il définit la base de référence par rapport à laquelle votre bureau de gouvernance du programme peut ensuite orienter le programme et mesurer ses réalisations.

## Définition de la portée de l'analyse de rentabilisation directionnelle
<a name="fix-scope"></a>

Une analyse de rentabilisation directionnelle est généralement assemblée rapidement, en 2 à 4 semaines. Il doit générer suffisamment de confiance pour que vous puissiez obtenir les ressources nécessaires pour constituer l'équipe principale, engager des AWS partenaires si nécessaire et, au minimum, terminer l'[évaluation des applications prioritaires](prioritized-applications-assessment.md), l'[analyse du portefeuille et les étapes de planification de la migration](portfolio-analysis-migration-planning.md).

Généralement, les analyses de rentabilisation directionnelles qui prennent en charge les migrations de portefeuilles sont créées comme suit :
+ Une simple**** comparaison *du coût total de possession (TCO)* entre le paysage d'infrastructure tel quel et l'architecture Service AWS post-migration. La comparaison montre la différence entre les taux d'exécution attendus pour des volumes de charge de travail donnés.
+ Une analyse de rentabilisation**** qui montre la valeur actuelle nette (VAN), le retour sur investissement (ROI), la période de remboursement, le taux de rendement interne modifié (MIRR) et des analyses des flux de trésorerie sur 3 à 5 ans pour une migration AWS incluant les coûts de migration plutôt que de rester en l'état. 

La portée de l'analyse de rentabilisation directionnelle est généralement limitée à l'un des éléments suivants :
+ Comparaison des coûts des technologies d'infrastructure
+ Comparaison de l'infrastructure, de la technologie et des coûts d'exploitation

En général, plus le portefeuille est important, moins le dossier doit être développé. Cela est dû au fait que des hypothèses plus larges peuvent être formulées sans affecter de manière significative le résultat. Pour un portefeuille plus petit, tout changement aura un impact plus important, c'est pourquoi plus de détails sont nécessaires.

Commencez par établir la comparaison des coûts d'infrastructure de base. Décidez ensuite si la comparaison est suffisamment convaincante avant de poursuivre. En général, les portefeuilles de plus de 400 serveurs présentent une analyse de rentabilisation positive sur la seule base de la réduction des coûts d'infrastructure dans les 3 ans suivant leur exploitation AWS, ou 250 serveurs dans les 5 ans, bien que cela puisse varier. Pour les petits portefeuilles, des détails supplémentaires peuvent être nécessaires.

À l'inverse, il est rarement utile d'examiner d'autres éléments de valeur commerciale à ce stade, tels que la valeur dérivée d'une résilience ou d'une agilité commerciale améliorée, sauf si l'étendue totale de la migration est inférieure à environ 5 charges de travail ou 50 serveurs.

## Facteurs de valeur focalisés
<a name="focus-value-drivers"></a>

La comparaison du coût total de possession des technologies d'infrastructure compare un modèle des coûts d'infrastructure tels quels à un modèle de base de la Service AWS nomenclature nécessaire pour exécuter vos charges de travail avec des performances et une disponibilité équivalentes. De nombreuses optimisations peuvent être effectuées. À ce stade, toutefois, l'accent est mis sur la liste suivante, car ils sont plus faciles à évaluer et permettent généralement de réaliser des économies d'environ 30 % sur le coût total de possession, ce qui est suffisant pour aller de l'avant :
+ **Élasticité de calcul** — Mappez les serveurs dont l'utilisation n'est pas de 100 %, tels que les serveurs de développement ou UAT fonctionnant 8 x 5 (24 % d'utilisation), 10 x 5 (30 %) ou 10 x 6 (36 %), et les serveurs de reprise après sinistre (DR) fonctionnant à 2 %, vers des services à la demande facturés uniquement lorsqu'ils sont utilisés.
+ **Achetez avec un plan d'économies** : planifiez l'achat de serveurs de production et d'autres serveurs très utilisés (plus de 36 %) avec un plan d'économies approprié pour réduire les coûts jusqu'à 75 %. Les options incluent des engagements d'un an et de 3 ans, avec différents niveaux de paiements initiaux pour garantir des remises plus importantes.
+ **Supprimez les zombies** : identifiez les serveurs dont l'utilisation du processeur est inférieure à 2 % et dont vous pouvez confirmer qu'ils ne sont plus nécessaires, et retirez-les de l'analyse des coûts.
+ **Calcul adapté : utilisez** les séries chronologiques d'utilisation du processeur et de la mémoire pour évaluer la puissance de calcul et la mémoire nécessaires pour chaque serveur. Sélectionnez ensuite l'instance Amazon Elastic Compute Cloud (Amazon EC2) adaptée.
+ **Dimensionnement correct des licences du système de gestion de base de données relationnelle (RDBMS)** : réévaluez vos besoins en matière de licences RDBMS après avoir calculé le bon dimensionnement sur vos serveurs de base de données, comparez Bring Your Own License (BYOL) et Procuring license from, et explorez le potentiel AWS d'Amazon Relational Database Service (Amazon RDS) pour augmenter les économies.
+ **Stockage** : dimensionnez correctement le volume de stockage total nécessaire et identifiez les besoins en input/output opérations par seconde (IOPS) sur l'ensemble du portefeuille. Déterminez la quantité qui peut être transférée vers le stockage d'objets avec SLAs des coûts différents.

## Besoins en données
<a name="data-needs"></a>

Le tableau de la [section Comprendre les exigences en matière de données d'évaluation initiale](understanding-initial-assessment-data-requirements.md) indique les données requises pour élaborer chaque partie d'une analyse de rentabilisation directionnelle, et indique si elles sont obligatoires ou facultatives. 

Pour étayer le dossier, vous avez besoin du sous-ensemble d'infrastructure composé des données de planification initiales et des données de coûts. La détermination de la manière d'identifier l'infrastructure à inclure dépend de votre objectif commercial : 
+ Si l'objectif du programme est de migrer et de moderniser des applications spécifiques, créez le portefeuille d'infrastructures en fonction des besoins des applications, en tenant compte de l'infrastructure partagée. 
+ Si l'objectif du programme est centré sur l'infrastructure, par exemple la migration depuis un centre de données dont le bail arrive à expiration, le mappage des applications n'est pas nécessaire pour comparer le coût total de possession de l'infrastructure. 

Les données marquées comme facultatives (telles que l'utilisation maximale du processeur et de la mémoire pour les serveurs) peuvent généralement être remplacées par des valeurs de référence standard. Vous pouvez en discuter avec un AWS partenaire ou des services AWS professionnels. Vous pouvez également extrapoler les valeurs à partir de points de données disponibles dans une partie de votre portefeuille (comme les données collectées par un hyperviseur). Plus le portefeuille est grand, plus il est précis.

## Comparaisons du coût total de possession des infrastructures du bâtiment
<a name="building-infrastructure-tco-comparisons"></a>

Les outils sont essentiels pour établir des comparaisons du coût total de possession des infrastructures. [AWS Les services professionnels](https://aws.amazon.com/professional-services/) ou un [AWS partenaire](https://aws.amazon.com/migration/partner-solutions/) peuvent fournir de l'aide pour tous les types de cas directionnels, en particulier si vous prévoyez de les engager pour vous aider dans le cadre du processus de migration plus large. 

Des outils sont disponibles pour effectuer les opérations suivantes :
+ Collectez les données d'inventaire.
+ Collectez les données d'utilisation.
+ Fournissez des données d'analyse comparative des coûts d'infrastructure précises telles quelles.
+ Identifiez et éliminez les zombies.
+ Procédez à des évaluations de la bonne taille.
+ Recommandez des options d'achat.
+ Comparez les options de licences logicielles.
+ Produisez des analyses graphiques simples des flux de trésorerie.

[Migration Evaluator](https://aws.amazon.com/migration-evaluator/) from AWS est une option. Il fournit toutes ces fonctionnalités sous forme de **service géré gratuit. Vous** pouvez demander Migration Evaluator par l'intermédiaire de votre responsable de AWS compte ou de votre partenaire de compétence en matière de AWS migration ou en soumettant [une demande](https://pages.awscloud.com/Migration-Evaluator-request.html) en ligne. Migration Evaluator a été conçu spécifiquement comme une solution ponctuelle permettant de comparer rapidement le coût total de possession des technologies d'infrastructure.

Principaux avantages : 
+ Sans frais
+ Découverte sans agent ou configuration manuelle des données d'inventaire lorsque la découverte basée sur des outils est limitée
+ Support dédié pour faciliter le déploiement, la configuration, la collecte de données et l'élaboration du scénario de base ou de l'analyse de rentabilisation directionnelle
+ Facilité d'utilisation du SaaS, mais possibilité d'exécuter la collecte de données entièrement au sein du réseau du client pour faciliter le nettoyage avant le chargement dans le moteur d'analyse
+ Support solide pour le dimensionnement correct des licences Microsoft
+ Capacités complètes d'exportation de données 

Principales limites : 
+ Évalue uniquement les serveurs d'architecture x86 (Windows et Linux) 
+ Options limitées pour configurer ou calibrer les données de coûts de référence telles quelles
+ Aucun support pour l'optimisation des coûts des opérations de modélisation
+ Aucun support pour la modélisation des coûts de migration 
+ Aucun soutien direct pour l'élaboration d'analyses de rentabilisation autres que les comparaisons du coût total de possession

Si vous décidez d'utiliser un outil de découverte commercial pour des fonctionnalités de découverte et d'analyse de portefeuilles telles que la pile d'applications et la découverte des interdépendances, il fournira généralement également une comparaison du coût total de possession de l'infrastructure. Pour obtenir des conseils sur l'utilisation des outils de découverte et d'évaluation du portefeuille, voir [Évaluation du besoin d'outils de découverte.](understanding-initial-assessment-data-requirements.md#discovery-tooling) Pour examiner et comparer les principales fonctionnalités des principaux outils du marché, consultez la section Outils de [migration de découverte, de planification et de recommandation](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/).

## Intégrer l'optimisation des coûts opérationnels
<a name="building-operational-cost-optimization"></a>

L'amélioration de la productivité des opérations informatiques contribue souvent de manière significative à la valeur des migrations. En moyenne, après la migration vers AWS, la productivité du personnel opérationnel informatique augmente de 62 % grâce à la migration, selon le livre blanc [Fostering Business and Organizational Transformation to Generate Business and Organizational Transformation to Generate Business Value with Amazon Web Services](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770). Cependant, le dimensionnement et l'intégration de ces avantages dans le cas directionnel présentent deux défis.

Tout d'abord, l'évaluation de la gamme complète des gains de productivité nécessite une collecte de données approfondie et convient mieux à l'analyse de [rentabilisation détaillée](detailed-business-case.md). Ce défi peut être résolu en se concentrant sur quelques éléments qui sont plus faciles à évaluer et à dimensionner à l'aide de simples données de référence, mais qui présentent tout de même un avantage significatif. 

Deuxièmement, le fait de se concentrer sur la productivité comme source de réduction des coûts peut susciter des inquiétudes et de la négativité chez les principaux clients, les parties prenantes et les membres du programme. Assurez-vous de préciser comment l'avantage sera réalisé et ce que cela signifie pour les personnes touchées. De tels problèmes peuvent être évités en précisant que cela ne fera que renforcer les rôles de l'équipe :
+ Le programme de migration comprend une piste permettant de développer et de transférer le personnel des opérations internes vers de nouveaux rôles, tels que rejoindre des DevSecOps équipes pour créer une infrastructure sous forme d'automatisations de code et de tests automatisés qui stimuleront la croissance de l'équipe.
+ L'avantage peut être obtenu en redimensionnant et en redimensionnant les opérations, les contrats d'externalisation, afin que le personnel interne puisse se concentrer davantage sur les activités à plus forte valeur ajoutée

Approche de construction de cet élément d'analyse de rentabilisation en fonction des transformations opérationnelles que vous souhaitez envisager :
+ Si vous disposez déjà d'une équipe opérationnelle interne, améliorez les compétences des membres de l'équipe et montrez l'amélioration de productivité attendue.
+ Vous pouvez également passer de votre solution d'exploitation actuelle à AWS Managed Services (AMS) ou à une autre offre de services gérés proposée par un AWS partenaire.

Pour la première transformation, afin d'obtenir une estimation financière prudente de l'amélioration de la productivité pouvant être incluse dans le cas, nous recommandons ce qui suit :

1. Concentrez-vous spécifiquement sur la productivité des opérations de gestion des serveurs. Cela représente généralement une part importante de l'effort opérationnel, peut être plus facilement évalué et est plus facilement vérifié ultérieurement. 

1. Calculez le personnel nécessaire sur la base de points de référence relatifs au nombre de serveurs pouvant être gérés par chaque employé équivalent temps plein (ETP). Sur site, ce nombre est d'environ 150 serveurs. Non AWS, il s'agit d'environ 400 serveurs.

1. Appliquez ces mesures au nombre de serveurs sur site par rapport au nombre d'instances EC2. 

1. Multipliez le temps économisé par un taux de coût combiné pour l'ensemble de l'équipe opérationnelle.

Vous pouvez ensuite vérifier vos résultats avec l'une ou l'autre approche en vérifiant que le résultat ne dépasse pas largement les gains de productivité moyens par rôle fournis dans le tableau suivant (données provenant du livre blanc d'IDC « [Favoriser la transformation commerciale et organisationnelle pour générer de la valeur commerciale avec Amazon](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) Web Services »).

 


| **Rôle** | **Gain d'efficacité** | 
| --- |--- |
| Gestion de l'infrastructure informatique | 62 % | 
| Support informatique | 59 % | 
| Gestion des applications | 43 % | 
| Gestion de base de données | 19 % | 
| Développement d’applications | 25% | 

Pour la deuxième transformation, vous pouvez ajouter les économies de coûts d'exploitation en comparant directement le total actuel des opérations et des coûts de support pour le portefeuille concerné avec le coût du service géré considéré. 

Pour obtenir le coût du service géré, fournissez à votre responsable de AWS compte ou à tout [AWS Managed Services partenaire](https://aws.amazon.com/managed-services/partners/) votre AWS facture proposée, votre choix de niveau de service (Plus ou Premium) et votre package AMS (AMS Accelerate ou AMS Advanced). Cela vous fournira le coût total des services gérés pour : les Service AWS composants de la solution transformée. De même, vous pouvez obtenir des tarifs auprès d'un AWS partenaire qui propose son propre package de services gérés en fonction de ses propres paramètres.

## Élargissement vers une analyse de rentabilisation complète
<a name="full-directional-business-case"></a>

En général, pour élaborer une analyse de rentabilisation complète, établir une comparaison du coût total de possession, avec ou sans l'élément de productivité informatique, et estimer tous les coûts de migration et de modernisation. Créez ensuite un flux de trésorerie qui couvre des paires de scénarios migrate-and-modernize et de t-migrate-and-modernize scénarios à ne pas faire.

Le cas le plus simple est la préparation d'une seule paire de scénarios, dans lesquels le t-migrate-and-modernize scénario à ne pas faire correspond à votre situation actuelle et le migrate-and-modernize scénario présente les caractéristiques suivantes :
+ Aucune augmentation ou diminution du volume transactionnel, de la capacité de calcul ou de mise en réseau
+ Croissance régulière des faibles volumes des besoins de stockage
+ Quality-of-service des fonctionnalités (telles que la disponibilité, la durabilité, le débit et les performances) correspondant aux capacités du système existant

Pour tous les portefeuilles, à l'exception des très petits portefeuilles, cela correspond à l'objectif consistant à bien élaborer un argumentaire directionnel. Il démontre rapidement une valeur suffisante pour obtenir le mandat nécessaire pour aller de l'avant. 

Pour les portefeuilles plus petits, il peut être utile d'ajouter des paires de scénarios migrate-and-modernize et de t-migrate-and-modernize scénarios à ne pas faire qui mettent en évidence d'autres aspects de la valeur accrue de la migration vers le cloud, tels que :
+ Une combinaison d'exigences de croissance de capacité modérées et élevées pour les charges de travail pour lesquelles cette croissance est attendue
+ Intégration d'une résilience améliorée, telle que la haute disponibilité, la reprise après sinistre et la tolérance aux pannes
+ Performances mondiales améliorées grâce à l'informatique de pointe, au réseau de diffusion de contenu (CDN) et à la réplication de bases de données multirégionales.
+ Toute autre amélioration spécifique de la qualité de service dont vous avez fait une priorité commerciale pour le programme

Pour ces scénarios, assurez-vous que les coûts et les implications en termes de flux de trésorerie liés à la mise à niveau de l'architecture d'infrastructure non cloud actuelle pour qu'elle corresponde à la nouvelle spécification sont estimés avec précision. Le moyen le plus direct d'obtenir cette estimation peut être de demander un devis à un intégrateur de systèmes, en particulier s'il s'agit également d'un partenaire AWS consultant compétent en matière de migration, qui peut vous aider à trouver des solutions à la fois pour les scénarios migrate-and-modernize et pour les scénarios à éviter. t-migrate-and-modernize 

Pour chaque paire de scénarios, assemblez un boîtier comprenant les éléments suivants :
+ Les coûts du t-migrate-and-modernize scénario « Don't ». Dans le cas le plus élémentaire, cela inclut :
  + Le coût total de possession sur la durée de l'analyse de rentabilisation pour la configuration actuelle de l'infrastructure
  + Augmentations périodiques de la consommation de calcul, de stockage et de trafic réseau 
+ Les coûts du scénario migrate-and-modernize, y compris :
  + Configuration du programme, qui comprend la découverte détaillée, la planification de la migration, l'élaboration d'une analyse de rentabilisation détaillée, la mise en place de l'équipe principale et le renforcement de ses compétences, l'établissement d'une zone de destination si ce n'est déjà fait, et la mise en place d'une gestion de la sécurité et d'une intégration des opérations pour les charges de travail migrées
  + Les coûts de migration et de modernisation de la charge de travail 
  + Les coûts de l'infrastructure de migration, y compris les connexions réseau, les services de migration de données tels que [AWS Snowball Edge](https://aws.amazon.com/snowball/)et [AWS DataSync](https://aws.amazon.com/datasync/), et les coûts AWS utilitaires liés à l'architecture requise pendant le processus de migration lui-même (par exemple, pour les tests)
  + L'augmentation des coûts des AWS services publics au cours de la migration au fur et à mesure de la mise en service des vagues, et la réduction des coûts d'infrastructure existants au fur et à mesure de leur remplacement par des services AWS basés et de leur mise hors service
+ Les coûts de mise hors service et les amortissements de tous les actifs bloqués

## Estimation de la configuration du programme de migration et de modernisation
<a name="estimating-migration-and-modernization-program-setup"></a>

Pour mettre en place un programme couronné de succès, vous devrez peut-être exécuter une série d'activités de base pour renforcer les capacités de base et le plan détaillé si cela n'a pas été fait auparavant. Ces activités fondamentales sont notamment les suivantes :

1. Réalisation de la découverte détaillée du portefeuille, de la planification de la migration et de l'élaboration d'une analyse de rentabilisation détaillée, comme décrit dans la section [Analyse du portefeuille et planification de la migration](portfolio-analysis-migration-planning.md), ainsi que de la documentation du coût de tous les outils de découverte utilisés.

1. Mettre en place une équipe principale commerciale et technique dans le cloud et développer les compétences internes par le biais de la formation et du recrutement. Identifiez les membres du service informatique qui auront besoin d'une formation et allouez un budget de formation à chaque personne.

1. Établir une [zone d'atterrissage](https://aws.amazon.com/solutions/implementations/aws-landing-zone/) et la configurer pour prendre en charge les capacités de gouvernance des coûts, des opérations et de la sécurité dont vous aurez besoin.

AWS Les partenaires consultants peuvent vous aider à fournir des estimations pour les articles 1 et 3. 

*Estimation des coûts de migration et de modernisation*

Pour atteindre les objectifs d'une analyse de rentabilisation directionnelle et démontrer un potentiel commercial *juste suffisant* pour passer à la phase suivante, veillez à ce que l'estimation des coûts de migration et de modernisation soit aussi simple que possible. 

À cette fin, nous vous recommandons de préparer l'analyse de rentabilisation directionnelle en vous concentrant sur les applications répondant aux stratégies de migration suivantes : 
+ Mise hors service
+ Conserver
+ Déménager
+ Réhéberger
+ Recréation de plateforme
+ Rachat

En général, environ 70 % des charges de travail peuvent être réhébergées, déplacées ou replateformes, et 5 % peuvent être supprimées. L'évaluation des applications par stratégie de migration porte généralement sur l'essentiel du cas de réduction des coûts. 

**L'estimation des coûts de refactorisation ou de réarchitecture peut s'avérer complexe.** Il n'est pas pratique de tenter de le faire dans le délai imparti pour préparer une analyse de rentabilisation directionnelle. Comme indiqué précédemment dans [Déterminer le type R pour la migration](prioritization-and-migration-strategy.md#migration-r-type), envisagez d'utiliser des stratégies de réhébergement, de relocalisation ou de replateforme pour votre première phase de migration et de modernisation. Ces stratégies R accéléreront probablement le retour sur investissement initial, réduiront les risques liés à la mise en œuvre et amélioreront l'analyse de rentabilisation à court terme. Il est également nettement plus facile pour vos équipes d'application de moderniser les applications qui s'exécutent dans l' AWS environnement que celles qui ne le sont pas. Il est préférable d'ajouter des estimations pour la refactorisation (réarchitecture) d'applications spécifiques lorsque l'analyse de [rentabilisation détaillée](detailed-business-case.md) est préparée. 

*Estimation de l'effort de migration par stratégie*

Chaque migration est différente. Avant d'engager des budgets ou des plans, établissez des estimations de la charge de travail pour les activités de migration auprès de l'équipe qui sera responsable du projet, qu'il s'agisse de vos équipes internes chargées des applications, des services AWS professionnels ou d'une organisation AWS partenaire. 

Pour aider à établir le dossier directionnel, le tableau suivant fournit des plages indicatives d'effort pour les différents traitements. Ces plages supposent qu'un medium-to-large portefeuille est en cours de migration et que l'équipe de migration est formée et expérimentée. Pour les petits portefeuilles, il est préférable que l'équipe responsable de la migration prépare l'estimation, même dans le cas d'un scénario directionnel.


| Stratégie de migration | Processus d'estimation | Eléments | Heures par personne | Heures par personne | 
| --- |--- |--- |--- |--- |
| Conserver | Ne rien faire, sans frais, sans avantages et sans réduction de la dette technologique. | – | – | – | 
| Mise hors service | Estimez la mise hors service de l'équipement matériel utilisé, le cas échéant. | – | – | – | 
| Déménager | Estimez la copie de la charge de travail à VMware l'aide VMware d'outils. Cela inclut la copie des données, les tests de fumée à des fins de vérification et la mise hors service du matériel. L'effort de relocalisation VMs est généralement moindre que pour les modèles de réhébergement peu complexes. | – | – | – | 
| Réhéberger | Estimez la charge de travail et les données à l'aide d'une copie d'image, de tests de détection de fumée, de tests de haute disponibilité (HA) et de reprise après sinistre (DR), le cas échéant, pour les serveurs de production et de toute mise hors service du matériel. La meilleure pratique consiste à utiliser des outils tels que [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/). Divisez les charges de travail en niveaux de complexité faible, moyenne et élevée, en fonction de facteurs tels que l'exécution d'une base de données ou d'un autre logiciel d'infrastructure, la complexité de la base de données, son caractère clusterisé, la complexité de l'intégration et les volumes de données. | Effort par application et par serveur | Migration | Test HA/DR | 
| Faible | 10 à 14 | 3 à 5 | 
| Moyenne | 16 à 24 ans | 4—6 | 
| Élevée | 26—38 | 8 à 12 | 
| Recréation de plateforme | Pour les migrations de replateforme qui incluent des mises à niveau vers le système d'exploitation ou la version du SGBDR, faites une estimation pour un réhébergement et ajoutez du temps pour effectuer un test de reconstruction et de fumage sur la nouvelle plateforme. Si la replateforme inclut une modification de la technologie de la plate-forme, estimez le temps supplémentaire pour l'utilisation des outils de conversion, tels que [AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/)et, et [AWS Database Migration Service](https://aws.amazon.com/dms/)un test d'application plus complet. Un exemple de changement de technologie est la migration d'une base de données commerciale propriétaire vers une base de données open source de remplacement. | Effort par application et par serveur | Version supérieure | Changements technologiques | 
| Faible | Ajoutez 1 à 3 | Ajoutez 10 à 15 | 
| Moyenne | Ajoutez 2 à 5 | Ajoutez 20—30 | 
| Élevée | Ajoutez 4 à 8 | Ajoutez 40 à 60 | 
| Rachat | Estimez l'extraction, la transformation et le téléchargement des données dans le cadre du remplacement du service SaaS récemment acheté et de toute mise hors service du matériel. | – | – | – | 

*Estimation des coûts de l'infrastructure de migration*

Incluez des estimations pour l'infrastructure que vous utiliserez au cours de la migration. En général, ces estimations comprennent :
+ Un budget pour les services de connectivité et d'échange de données pour la charge de travail et la migration des données de l'environnement actuel vers AWS
+ Un budget Services AWS (en particulier pour le calcul et le stockage) nécessaires à l'hébergement des charges de travail migrées pendant les processus de migration, de test et de transition
+ L'augmentation des coûts des AWS services publics à mesure que chaque vague de migration est terminée
+ Les coûts de mise hors service de l'infrastructure existante qui n'exécutera plus les charges de travail migrées

Pour l'échange de données, examinez vos volumes de données totaux et évaluez la faisabilité de l'utilisation du réseau. Si vous avez configuré AWS à l'avance une [AWS Direct Connect](https://aws.amazon.com/directconnect/)liaison ou [Site-to-Site VPN](https://aws.amazon.com/vpn/)depuis un point de votre réseau étendu pour une utilisation opérationnelle après la migration, vous pouvez utiliser cette ressource dans la limite de son quota de service. 

Si la capacité de votre réseau est insuffisante, une augmentation à court terme de la bande passante Internet grâce à un réseau privé virtuel (VPN) est souvent une solution très rentable. Sinon, AWS les dispositifs d'échange multimédia tels que [AWS Snowball Edge](https://aws.amazon.com/snowball/)et [AWS Snowball Edge](https://aws.amazon.com/snowcone/)offrent des solutions dans la plupart des cas Régions AWS. En outre, pour la migration de très gros volumes de données, pensez à prévoir un budget [AWS DataSync](https://aws.amazon.com/datasync/), ce qui améliore la fiabilité et peut accélérer les transferts, quel que soit le support utilisé.

La modélisation de l'augmentation des AWS services et de la réduction de l'infrastructure existante est importante pour l'élément d'analyse des flux de trésorerie de l'analyse de rentabilisation. À ce stade, il est peu probable que vous disposiez d'un plan de vagues permettant de déterminer exactement quand les coûts seront engagés. Nous vous recommandons la procédure suivante :
+ Augmenter les coûts à un taux constant AWS tout au long de la migration. 
+ Réduire les coûts de l'infrastructure existante que vous prévoyez de mettre hors service à un rythme constant pendant la même durée.

Commencer l'augmentation des AWS coûts 1 à 2 mois avant la réduction de l'infrastructure existante. Cela permet d'utiliser l' AWS utilitaire pendant un mois pour effectuer la migration pour chaque vague. Cela inclut du temps pour les tests et du temps supplémentaire pour terminer les travaux de mise hors service nécessaires afin de ne plus encourir de coûts sur l'infrastructure remplacée.

*Estimation des coûts de mise hors service*

La mise hors service des équipements qui ne peuvent pas être redéployés et leur élimination de manière légale et respectueuse de l'environnement peuvent entraîner de faibles coûts. Cependant, pour une analyse de rentabilisation directionnelle, la seule somme potentiellement significative est généralement le coût de la radiation de la valeur comptable restante des actifs remplacés.

Pour l'analyse de rentabilisation directionnelle, nous vous recommandons de procéder comme suit :
+ Passez en revue votre liste d'actifs.
+ Identifiez ceux qui seraient mis hors service.
+ Pour réduire les amortissements, examinez les possibilités de changer d'appareil afin que les nouveaux appareils de la liste puissent être utilisés pour remplacer des actifs plus anciens et plus entièrement amortis. 
+ Faites une évaluation de la future valeur comptable des actifs qui seraient mis hors service à ce moment-là.
+ Incluez ce montant dans le coût de migration lié à la mise hors service.

*Assemblage et ajustement de l'analyse de rentabilisation entièrement directionnelle*

Après avoir préparé l'ensemble complet des coûts pour chaque paire de scénarios, établissez un tableau des flux de trésorerie actualisés pour chacun d'eux et représentez-les sous forme de graphique. Nous recommandons d'élaborer des analyses de rentabilisation directionnelles au cours de la même période que le cycle d'actualisation du matériel. Ce délai est généralement de 5 ans pour les serveurs, le stockage et les périphériques réseau. Lorsque vous utilisez la même période que le cycle d'actualisation du matériel, les coûts d'une seule actualisation sont inclus dans les coûts tels quels pour chaque scénario.

Calculez ensuite les indicateurs financiers clés dont vous avez besoin pour obtenir l'approbation nécessaire pour passer à la phase suivante du programme. Nous incluons généralement les éléments suivants :
+ La valeur actuelle nette (VAN) pour évaluer la valeur absolue des réductions de coûts et des gains de productivité évalués
+ Le délai de remboursement en mois pour vérifier que les retours sont suffisamment rapides
+ Comparaison finale du taux d'exécution pour vérifier si le processus réduit suffisamment les coûts sur le terme
+ Le retour sur investissement (ROI) et le taux de rendement d'investissement modifié (MIRR) pour évaluer la performance financière relative du programme par rapport aux autres demandes de capital auxquelles votre organisation pourrait donner la priorité

Utilisez la première itération du cas pour déterminer si les performances financières attendues nécessitent des améliorations, comme dans les exemples suivants :
+ Si le retour sur investissement est trop lent, envisagez des options pour accélérer et réduire le coût de la migration, telles que les suivantes :
  + Faites appel à AWS des partenaires ou à des services AWS professionnels pour étendre les ressources disponibles et paralléliser davantage la migration des charges de travail avec des modèles plus basiques. 
  + Pour les charges de travail entrantes VMware, comparez la stratégie de relocalisation à la stratégie de réhébergement ou de replateforme, au moins pour la phase initiale. L'utilisation de la stratégie de relocalisation peut réduire les coûts de migration et augmenter la vitesse de migration.
  + Lorsque cela est techniquement possible, reportez les charges de travail qui nécessitent des stratégies de replateforme ou de refactorisation (réarchitecture) plus complexes à une phase future, en dehors du cadre de l'analyse de rentabilisation initiale.
+ Si le retour sur investissement et le MIRR sont trop faibles, considérez les points suivants :
  + Les scénarios que vous envisagez sont-ils trop conservateurs ? Avez-vous un scénario qui reflète la croissance des capacités et les besoins d'élasticité les plus probables ? Avez-vous des scénarios qui comparent les coûts, y compris l'augmentation de la qualité de service, dans le cadre de vos objectifs ?
  + Pouvez-vous affiner l'étendue du portefeuille d'applications à migrer au cours de la première phase afin de vous concentrer sur les charges de travail les plus rentables, telles que celles dont le taux d'utilisation actuel est plus faible ou les besoins coûteux en matière de reprise après sinistre (DR) ?
  + Est-il possible d'affiner la portée du portefeuille d'applications pour exclure dans un premier temps les charges de travail spécifiques moins rentables sur le plan commercial ? Par exemple, pouvez-vous reporter les charges de travail pour lesquelles les licences de logiciels tiers deviennent plus chères en raison de conditions de déploiement différentes dans une infrastructure de cloud public ?
+ Si la comparaison finale de la fréquence d'exécution n'atteint pas l'objectif attendu, explorez les points suivants :
  + Tout d'abord, confirmez que les autres indicateurs répondent aux attentes. L'analyse de rentabilisation directionnelle vise principalement à démontrer qu'il existe des opportunités financières suffisantes pour justifier le lancement de la phase suivante de préparation de la migration. 
  + Identifiez une liste des opportunités permettant de continuer à améliorer les performances en termes de coûts AWS après la phase initiale de migration.

Incluez une évaluation de la liste des opportunités lors de la préparation de l'analyse de rentabilisation détaillée. En outre, incluez une évaluation des opportunités dans le cadre de la maintenance continue du dossier et du processus month-to-month d'optimisation des coûts une fois la migration terminée.