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.
À propos des stratégies de migration
Une stratégie de migration est l'approche utilisée pour migrer une charge de travail vers le AWS Cloud. Il existe sept stratégies de migration pour déplacer des applications vers le cloud, connues sous le nom de « 7 R » :
Les stratégies courantes pour les migrations de grande envergure incluent le réhébergement, la replateforme, la relocalisation et le retrait. Le refactorisation n'est pas recommandé pour les grandes migrations car il implique la modernisation de l'application pendant la migration. Il s'agit de la stratégie de migration la plus complexe, et elle peut être compliquée à gérer pour un grand nombre d'applications. Nous recommandons plutôt de réhéberger, de déplacer ou de reconfigurer l'application, puis de la moderniser une fois la migration terminée.
La sélection de stratégies de migration est essentielle pour une migration de grande envergure. Vous avez peut-être sélectionné des stratégies de migration lors de la phase de mobilisation ou lors de l'évaluation initiale du portefeuille. Cette section passe en revue chaque stratégie de migration et leurs cas d'utilisation courants.
Mise hors service
Il s'agit de la stratégie de migration pour les applications que vous souhaitez mettre hors service ou archiver. Le retrait de l'application signifie que vous pouvez arrêter les serveurs de cette pile d'applications. Les cas d'utilisation courants de la stratégie de retraite sont les suivants :
-
Il n'y a aucun intérêt commercial à conserver l'application ou à la déplacer vers le cloud.
-
Vous souhaitez éliminer les coûts de maintenance et d'hébergement de l'application.
-
Vous souhaitez réduire les risques de sécurité liés à l'exploitation d'une application qui utilise une version du système d'exploitation (OS) ou des composants qui ne sont plus pris en charge.
-
Vous souhaiterez peut-être retirer des applications en fonction de leurs performances. Par exemple, vous souhaiterez peut-être retirer les applications dont l'utilisation moyenne du processeur et de la mémoire est inférieure à 5 %, appelées applications zombies. Vous pouvez également choisir de mettre hors service certaines applications dont l'utilisation moyenne du processeur et de la mémoire se situe entre 5 et 20 % sur une période de 90 jours, appelées applications inactives. Vous pouvez utiliser les données d'utilisation et de performance de votre outil de découverte pour identifier les applications zombies et inactives.
-
Aucune connexion entrante n'a été établie vers l'application au cours des 90 derniers jours.
Pour plus d'informations, consultez Bonnes pratiques pour évaluer les applications à retirer lors d'une migration vers le AWS Cloud.
Conserver
Il s'agit de la stratégie de migration pour les applications que vous souhaitez conserver dans votre environnement source ou pour les applications que vous n'êtes pas prêt à migrer. Il se peut que vous choisissiez de migrer ces applications à l'avenir.
Les cas d'utilisation courants de la stratégie de rétention sont les suivants :
-
Sécurité et conformité : vous souhaiterez peut-être conserver les applications afin de respecter les exigences relatives à la résidence des données.
-
Risque élevé : vous pouvez décider de conserver une application car elle nécessite une évaluation et un plan détaillés avant la migration.
-
Dépendances : vous pouvez décider de conserver une application si vous devez d'abord migrer une ou plusieurs autres applications.
-
Applications récemment mises à niveau : vous souhaiterez peut-être reporter la migration de l'application à la prochaine actualisation technique, car vous avez récemment investi dans la mise à niveau de votre système actuel.
-
Aucune valeur commerciale à migrer — La migration de certaines applications vers le cloud n'a aucun intérêt commercial, comme celles qui ne comptent que quelques utilisateurs internes.
-
Plans de migration vers le logiciel en tant que service (SaaS) : vous pouvez choisir de conserver une application jusqu'à ce que la version SaaS soit publiée par le fournisseur. Il s'agit d'une stratégie courante pour les applications basées sur les fournisseurs.
-
Dépendances physiques non résolues : vous pouvez choisir de conserver une application qui dépend d'un matériel spécialisé qui n'a pas d'équivalent dans le cloud, comme les machines d'une usine de fabrication.
-
Applications mainframe ou de milieu de gamme et applications Unix non x86 : ces applications nécessitent une évaluation et une planification minutieuses avant de les migrer vers le cloud. Parmi les applications de milieu de gamme, citons IBM AS/400 et Oracle Solaris.
-
Performances : vous souhaiterez peut-être conserver les applications en fonction de leurs performances. Par exemple, vous souhaiterez peut-être conserver les applications zombies ou inactives dans votre environnement source.
Réhéberger
Cette stratégie est également connue sous le nom de lift and shift. Grâce à cette stratégie, vous déplacez vos applications de votre environnement source vers le AWS Cloud sans apporter de modifications à l'application. Par exemple, vous migrez votre pile d'applications de votre environnement local vers le AWS Cloud.
Avec Rehost, vous pouvez migrer un grand nombre de machines depuis plusieurs plateformes sources (physiques, virtuelles ou autre cloud) vers le AWS Cloud sans vous soucier de la compatibilité, des perturbations des performances, des longues périodes de transition ou des réplications de données sur de longues distances.
Votre application continue de servir les utilisateurs pendant la migration des charges de travail, ce qui minimise les interruptions et les temps d'arrêt. Le temps d'arrêt dépend de votre stratégie de transition.
Cette stratégie vous permet de faire évoluer vos applications sans mettre en œuvre d'optimisations cloud susceptibles de vous faire gagner du temps ou de l'argent. Les applications sont plus faciles à optimiser ou à réorganiser lorsqu'elles s'exécutent déjà dans le cloud, car il est plus facile de les intégrer aux AWS services et de gérer vos charges de travail.
Vous pouvez automatiser le réhébergement en utilisant les services suivants :
Pour obtenir une liste des modèles de migration pour la stratégie de migration de réhébergement, voir Rehost sur le site Web des directives AWS prescriptives.
Déménager
Grâce à cette stratégie, vous pouvez transférer un grand nombre de serveurs, comprenant une ou plusieurs applications, à un moment donné d'une plateforme sur site vers une version cloud de la plateforme. Vous pouvez également utiliser la stratégie de relocalisation pour déplacer des instances ou des objets vers un autre cloud privé virtuel (VPC) Région AWS, ou. Compte AWS Par exemple, vous pouvez utiliser cette stratégie pour transférer une instance de base de données Amazon Relational Database Service (Amazon RDS) vers un autre VPC ou. Compte AWS
La stratégie de relocalisation ne nécessite pas l'achat de nouveau matériel, la réécriture d'applications ou la modification de vos opérations existantes. Pendant le déménagement, l'application continue de servir les utilisateurs, ce qui minimise les perturbations et les temps d'arrêt. La relocalisation est le moyen le plus rapide de migrer et d'exploiter votre charge de travail dans le cloud, car cela n'a aucun impact sur l'architecture globale de votre application.
Pour obtenir une liste des modèles de migration pour la stratégie de migration par relocalisation, voir Relocate sur le site Web des directives AWS prescriptives.
Rachat
Cette stratégie est également connue sous le nom de drop and shop. Vous remplacez votre application par une autre version ou un autre produit. La nouvelle application devrait apporter une valeur commerciale supérieure à celle de l'application existante sur site, notamment des fonctionnalités telles que l'accessibilité depuis n'importe où, l'absence d'infrastructure à maintenir et pay-as-you-go des modèles de tarification. Le rachat de l'application réduit généralement les coûts associés à la maintenance, à l'infrastructure et aux licences.
Les cas d'utilisation les plus courants de la stratégie de migration du rachat sont les suivants :
-
Passer d'une licence traditionnelle au SaaS : cela élimine le fardeau de la gestion et de la maintenance de l'infrastructure et contribue à réduire les problèmes de licence.
-
Mises à niveau de version ou équivalents tiers : en remplaçant votre application sur site existante par la dernière version du fournisseur ou un équivalent tiers dans le cloud, vous pouvez tirer parti des nouvelles fonctionnalités, intégrer les services cloud et faire évoluer l'application plus facilement.
-
Remplacement d'une application personnalisée : vous pouvez éviter de recoder et de réorganiser une application personnalisée en rachetant une application SaaS ou basée sur le cloud auprès d'un fournisseur.
Avant d'acheter, vous devez évaluer l'application en fonction des exigences de votre entreprise, notamment en matière de sécurité et de conformité.
Après avoir acheté la nouvelle application, voici les étapes suivantes :
-
Former votre équipe et vos utilisateurs avec le nouveau système
-
Migration de vos données vers l'application que vous venez d'acheter
-
Intégration de l'application dans vos services d'authentification, tels que Microsoft Active Directory, pour centraliser l'authentification
-
Configuration du réseau pour sécuriser les communications entre l'application achetée, vos utilisateurs et votre infrastructure
Généralement, le fournisseur de l'application vous aide dans ces activités pour une transition en douceur.
Recréation de plateforme
Cette stratégie est également connue sous le nom de lift, tinker et shift ou lift and reshape. À l'aide de cette stratégie de migration, vous déplacez l'application vers le cloud et vous introduisez un certain niveau d'optimisation afin de faire fonctionner l'application efficacement, de réduire les coûts ou de tirer parti des fonctionnalités du cloud. Par exemple, vous pouvez reconfigurer une base de données Microsoft SQL Server vers Amazon RDS for SQL Server.
En utilisant cette stratégie, vous pouvez apporter quelques ou plusieurs modifications à l'application, en fonction de vos objectifs commerciaux et de votre plateforme cible.
Les cas d'utilisation courants de la stratégie de migration de replateforme sont les suivants :
-
Vous souhaitez gagner du temps et réduire les coûts en optant pour un service entièrement géré ou un service sans serveur dans le AWS Cloud.
-
Vous souhaitez améliorer votre position en matière de sécurité et de conformité en mettant à niveau votre système d'exploitation vers la dernière version. À l'aide du programme de migration de fin de support (EMP) pour Windows Server
, vous pouvez migrer vos anciennes applications Windows Server vers les dernières versions prises en charge de Windows Server sur Windows Server AWS, sans aucune modification de code. Vous pouvez utiliser cet arbre de décision dans le guide de l'utilisateur d'AWS EMP pour Windows Server pour vous aider à déterminer vos charges de travail EMP. -
Vous pouvez réduire les coûts en utilisant les processeurs AWS Graviton, des processeurs
personnalisés développés par. AWS -
Vous pouvez réduire les coûts en passant d'un système d'exploitation Microsoft Windows à un système d'exploitation Linux. Vous pouvez porter vos applications .NET Framework vers .NET Core, qui peut être exécuté sur un système d'exploitation Linux. L'assistant de portage pour .NET
est un outil d'analyse qui vous aide à porter vos applications vers Linux. -
Vous pouvez améliorer les performances en migrant des machines virtuelles vers des conteneurs, sans apporter de modifications au code. Vous pouvez moderniser vos applications .NET et Java en applications conteneurisées à l'aide de l'outil de migration AWS App2Container
.
La stratégie de replateforme permet à votre ancienne application de fonctionner sans compromettre la sécurité et la conformité.
La replateforme réduit les coûts et améliore les performances en migrant vers un service géré ou sans serveur, en déplaçant les machines virtuelles vers un conteneur et en évitant les dépenses de licence.
Pour une liste des modèles de migration pour la stratégie de migration de replateforme, voir Replatform sur le site Web des directives AWS prescriptives.
Refactoriser ou réorganiser
Grâce à cette stratégie, vous déplacez une application vers le cloud et modifiez son architecture en tirant pleinement parti des fonctionnalités natives du cloud pour améliorer l'agilité, les performances et l'évolutivité. Cela est motivé par la forte demande des entreprises qui souhaitent évoluer, accélérer le lancement de produits et de fonctionnalités et réduire les coûts.
Les cas d'utilisation courants de la stratégie de migration refactorisée sont les suivants :
-
L'ancienne application mainframe ne peut plus répondre à la demande de l'entreprise en raison de ses limites ou de son coût de maintenance élevé.
-
Vous avez une application monolithe qui entrave déjà les efforts visant à livrer rapidement des produits ou à répondre aux besoins et aux demandes des clients.
-
Vous avez une ancienne application que personne ne sait comment gérer, ou le code source n'est pas disponible.
-
L'application est difficile à tester ou la couverture des tests est très faible. Cela affecte la qualité et la fourniture des nouvelles fonctionnalités et correctifs de l'application. En redessinant l'application pour le cloud, vous pouvez augmenter la couverture des tests et intégrer des outils de test automatisés.
-
Pour des raisons de sécurité et de conformité, lorsque vous déplacez une base de données vers le cloud, vous devrez peut-être extraire certaines tables (telles que les informations sur les clients, les patients ou les tables de diagnostic des patients) et les conserver sur site. Dans ce cas, vous devez refactoriser votre base de données afin de séparer les tables qui seront migrées de celles qui seront conservées sur site.
Pour une liste des modèles de migration pour la stratégie de migration refactorisée, voir Re-architect sur le site Web AWS Prescriptive Guidance.
