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.
# Bonnes pratiques
Choisir de retirer des applications peut s'avérer une décision complexe, en particulier lors d'une migration vers le AWS cloud. Les sections suivantes présentent les meilleures pratiques à utiliser dans le cadre de votre processus décisionnel.
**Topics**
+ [Envisagez une approche basée sur une usine de migration](best-practice-1.md)
+ [Identifiez et retirez les applications dès le début de votre migration](best-practice-2.md)
+ [Soyez guidé par les données et utilisez des outils de découverte pour éviter les interruptions](best-practice-3.md)
+ [Planifiez un arrêt contrôlé](best-practice-4.md)
+ [Réévaluez si l'application doit être migrée](best-practice-5.md)
+ [Supprimer l'application](best-practice-6.md)
# Envisagez une approche basée sur une usine de migration
Un élément important de toute migration à grande échelle consiste à établir une *usine de migration* après la migration des charges de travail pilotes initiales.
Une usine de migration est composée d'équipes, d'outils et de processus qui travaillent ensemble pour rationaliser les migrations de manière systématique, en intégrant les leçons tirées des vagues de migration précédentes. L'usine de migration applique des modèles qui accélèrent les migrations de charges de travail et améliorent le résultat final.
En fonction de la taille du portefeuille informatique dont vous avez besoin pour prendre votre retraite, il convient de déterminer s'il est utile de mettre en œuvre une approche basée sur la migration en usine. Les méthodologies et les principes décrits dans ce guide compléteront également cette approche et peuvent être intégrés à ses mécanismes.
En général, 20 à 50 % du portefeuille d'applications d'une entreprise est constitué de modèles répétés qui peuvent être optimisés en utilisant une approche basée sur une usine de migration. Pour un exemple de modèle, consultez la [solution AWS Cloud Migration Factory](https://aws.amazon.com//solutions/implementations/cloud-migration-factory-on-aws/), qui peut être mise en œuvre par une équipe de migration pour coordonner et automatiser les migrations.
L'équipe doit commencer par les applications dont la criticité métier est la plus faible, avant de passer progressivement à des systèmes plus critiques. Lorsque l'équipe commencera à migrer des systèmes critiques, elle aura migré des centaines, voire des milliers de charges de travail et en aura tiré de nombreuses leçons.
Avant le début de la phase d'évaluation, vous pouvez créer un processus pour capturer un mois de données de dépendance pour les applications identifiées pour le retrait. Une équipe est avertie et a accès aux données lorsqu'elles sont prêtes. L'équipe attribue ensuite aux données un score basé sur le potentiel d'impact d'une application. Les propriétaires de l'application peuvent ensuite effectuer une analyse plus approfondie des connexions avant le début des prochaines étapes.
Pour plus d'informations sur la méthodologie Migration Factory, consultez le [Guide pour les AWS grandes migrations](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/).
# Identifiez et retirez les applications dès le début de votre migration
Il est important d'identifier puis de retirer les applications au début du processus de migration, et cela doit être fait pendant la migration des charges de travail.
Les projets de migration donnent souvent la priorité à la migration des charges de travail. Il est donc courant que les systèmes identifiés comme devant être retirés (et non migrés) soient ciblés vers la fin du projet. Cependant, il existe un risque que le fait de laisser ces applications jusqu'à la fin du projet ne laisse que très peu de temps pour les inclure dans la migration si l'application est jugée importante par la suite.
Le retrait anticipé des charges de travail pendant un projet de migration réduit la charge de travail des équipes chargées de leur maintenance. Par exemple, le retrait de serveurs au cours des premières phases d'un projet de migration signifie que les équipes chargées des systèmes d'exploitation ont moins de serveurs à corriger, à mettre à niveau, à entretenir ou à prendre en charge. Ces équipes peuvent ensuite se concentrer sur le projet de migration lui-même.
Enfin, certaines des meilleures pratiques de ce guide sont plus efficaces lorsque vous les suivez pendant de longues périodes. Si vous entamez le processus de retraite plus tôt mais que vous déterminez par la suite qu'une demande est réellement requise par un autre service, vous pourrez modifier votre plan de migration et l'inclure dans une future vague de migration.
# Soyez guidé par les données et utilisez des outils de découverte pour éviter les interruptions
Il est essentiel d'être piloté par les données lorsque l'on envisage de retirer des applications. Les schémas d'architecture et les connaissances institutionnelles peuvent facilement être périmés ou incomplets. Parfois, des problèmes imprévus peuvent également survenir, par exemple une autre application qui devient dépendante de votre système sans engagement formel en raison d'un scénario de dépannage.
Une approche axée sur les données constitue la base sur laquelle vous pouvez prendre des décisions ou valider une approche. Lorsque vous évaluez si une application peut être retirée, vous devez vérifier que les charges de travail que vous migrez n'en dépendent pas. La migration de ces charges de travail puis la suppression d'une dépendance peuvent entraîner une dégradation du service ou, pire encore, une interruption de service.
Heureusement, il est assez simple de comprendre ces dépendances en utilisant les données pour surveiller les connexions réseau entrantes et sortantes sur un serveur dont la mise hors service est prévue. Les connexions réseau entrantes, telles qu'une application se connectant à votre application, et les connexions sortantes, telles que le téléchargement de fichiers vers un partage NFS (Network File System), indiquent une éventuelle dépendance en amont. Cette dépendance doit être étudiée, car si une charge de travail devant être migrée vers le AWS cloud se connecte à l'application, il existe un risque d'interruption de service si l'application est mise hors service ultérieurement. Ce processus peut nécessiter une analyse approfondie pour suivre la chaîne de dépendance. Comme dans l'exemple précédent, si l'application télécharge un fichier sur un partage NFS, l'étape suivante consiste à déterminer quel système consomme ce fichier et quel est le statut de cette application.
Vous pouvez décider d'étudier ces connexions et d'évaluer le niveau d'impact. Pour ce faire, vous pouvez utiliser des outils de découverte pour afficher les connexions initiées à un serveur dont la mise hors service est prévue. Vous remarquerez peut-être que la plupart des connexions proviennent de serveurs de gestion et peuvent être ignorées, car il s'agit d'outils qui collectent des mesures de performance ou d'instances de proxy d'administrateur système. Toutefois, si des applications se connectant au serveur sont planifiées pour la migration, vous devez approfondir votre analyse et vérifier l'impact potentiel de la migration sur ces applications.
[AWS Application Discovery Service](https://aws.amazon.com/application-discovery/)aide les clients à planifier des projets de migration en collectant des informations sur les centres de données locaux qu'ils envisagent de mettre hors service. Après avoir déployé l'agent sur vos serveurs, Application Discovery Service enregistre l'activité réseau entrante et sortante pour chaque serveur, ainsi que d'autres informations. En utilisant [Amazon Athena](https://aws.amazon.com/athena/) pour analyser ces données, vous pouvez identifier si d'autres applications dépendent de serveurs dont la mise hors service est prévue.AWS Les [partenaires spécialisés dans les compétences en migration](https://aws.amazon.com//migration/partner-solutions/) peuvent également fournir des outils de découverte et de planification approfondis.
**Note**
Application Discovery Service n'est plus ouvert aux nouveaux clients. Vous pouvez également utiliser celui AWS Transform qui fournit des fonctionnalités similaires. Pour plus d'informations, consultez [AWS Application Discovery Service la section Modification de la disponibilité](https://docs.aws.amazon.com/application-discovery/latest/userguide/application-discovery-service-availability-change.html).
Par exemple, l'illustration d'écran suivante montre quatre adresses IP sources se connectant au serveur sur le port 22 (destination = 172.31.1.117).
![\[Exemple d'analyse de connexions.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-retiring-applications/images/best-practices-4.png)
Il s'agit d'hôtes bastions utilisés par les administrateurs système et qui peuvent être ignorés. L'image montre également deux serveurs se connectant à cette application sur le port 80, dans le cadre d'une migration planifiée. À ce stade, vous devrez approfondir vos connaissances et comprendre les applications connectées. Cette analyse approfondie vous permettra d'évaluer s'il y aura un impact en amont après le départ à la retraite.
# Planifiez un arrêt contrôlé
Dans votre plan de migration, veillez à prévoir un arrêt contrôlé pendant le processus de migration. Un arrêt contrôlé interrompt le processus de migration afin d'identifier le risque d'interruption en cas de mise hors service d'une application. Il simule le retrait de l'application et permet d'en observer les conséquences. Lorsque la période d'arrêt contrôlée est terminée, la migration peut facilement reprendre.
L'approche d'arrêt contrôlé varie en fonction du type d'application et des processus associés avec lesquels vous travaillez. Les modèles d'arrêt contrôlés courants incluent :
+ Implémentation d'un pare-feu basé sur l'hôte pour bloquer tout le trafic, simulant le retrait
+ Suspension d'une machine virtuelle
+ Arrêt d'un service sur l'hôte
+ Blocage de tout le trafic à l'aide d'un pare-feu externe
Les responsables du projet de migration et de l'application doivent définir la durée d'un arrêt contrôlé, en fonction du type d'application. Par exemple, si vous supprimez une charge de travail par lots qui ne s'exécute qu'une fois par mois ou une fois par trimestre, un arrêt contrôlé d'une semaine peut ne pas être suffisant pour déterminer l'impact sur les autres systèmes.
En reprenant l'exemple de la section précédente, une autre application était en train de se connecter au serveur dont la mise hors service était prévue. Une première évaluation a conclu qu'il ne devrait pas y avoir d'impact sur les serveurs en amont. Un arrêt contrôlé peut désormais être effectué pour comprendre l'impact.
Cet arrêt contrôlé serait effectué en implémentant un pare-feu basé sur l'hôte pour bloquer tout le trafic, simulant ainsi l'effet de l'arrêt du serveur. Si cela entraîne des problèmes de service pour les applications dont la migration vers le AWS cloud est planifiée, une règle de pare-feu est ajoutée et tout le trafic reprend. Après l'arrêt contrôlé, la mise hors service du serveur est reconsidérée en raison de cette dégradation ou interruption du service.
# Réévaluez si l'application doit être migrée
Les deux dernières pratiques exemplaires dont nous avons discuté aident à déterminer s'il est approprié de poursuivre les mesures concernant les systèmes dont la mise à la retraite est prévue. Si ces meilleures pratiques mettent en évidence un impact commercial potentiel en amont, vous devez envisager de réévaluer le modèle de migration de l'application. En entamant le processus de retrait anticipé des applications, vous disposez désormais de suffisamment de temps pour inclure l'application dans une vague de migration ultérieure si vous rencontrez des problèmes ou des dépendances qui vous empêchent de la retirer.
Si, après avoir suivi ces bonnes pratiques, vous n'êtes pas totalement sûr de pouvoir retirer l'application, demandez-vous s'il convient de la réhéberger dans le AWS cloud. Cela est particulièrement important si votre migration a une date de fin définie, telle que l'expiration du bail d'un centre de données.
Des services tels que le [service de migration AWS d'applications](https://aws.amazon.com/application-migration-service/) simplifient l'approche de migration de réhébergement. Lorsque vous migrez des applications vers AWS, vous pouvez prendre un instantané quotidien des volumes Amazon Elastic Block Store (Amazon EBS) et résilier l'instance Amazon Elastic Compute Cloud (Amazon EC2) afin de réduire les coûts et de tester le retrait de l'application sur une longue période. En cas d'impact ou de problème, vous avez alors la certitude de pouvoir créer les volumes EBS sur la base du cliché pour reprendre l'instance EC2.
**Important**
Testez ce processus de restauration avant de mettre fin à l'instance EC2.
# Supprimer l'application
Après avoir suivi les cinq meilleures pratiques précédentes de ce guide, vous avez peut-être déterminé que vous pouvez retirer une application en toute sécurité. Vous avez déployé une approche basée sur une usine de migration, entamé le processus de retrait à un stade précoce, utilisé des outils de données et de découverte pour surveiller les connexions entrantes, effectué un arrêt contrôlé réussi et évalué si l'application devait être retirée. Le retrait de l'application est désormais possible dans le cadre de votre stratégie de migration.
À ce stade, vous devez vérifier si l'application contient des données susceptibles d'être utiles à l'avenir. L'apprentissage automatique (ML) et l'analyse ont donné aux données une valeur plus importante que jamais. Bien que vous ne développiez peut-être pas d'algorithmes de machine learning pour le moment, les données historiques peuvent s'avérer bénéfiques à l'avenir. Vous pouvez également avoir des exigences réglementaires ou de conformité pour stocker les données pendant une période définie, même si l'application a été retirée.
AWS propose un ensemble complet de services de stockage dans le cloud pour la conservation à long terme, la conformité et la conservation numérique. AWS les solutions de stockage pour l'archivage des données offrent une évolutivité illimitée, une durabilité de 99,999999999 %, une fiabilité et une sécurité des données.
Pour vous aider dans vos efforts de mise en conformité, réalise AWS régulièrement des validations par des tiers pour des milliers d'exigences de conformité mondiales. Ils sont surveillés en permanence pour vous aider à respecter les normes de sécurité et de conformité dans les domaines de la finance, du commerce de détail, de la santé, du gouvernement et au-delà.
Pour plus d'informations sur l'archivage des données avec AWS, consultez la section [Archivage des données](https://aws.amazon.com//archive/) sur le AWS site Web.