Le cadre de migration des 6 R

Le framework de migration des 6 R est une approche structurée permettant de catégoriser la manière dont chaque charge de travail sur site doit être déplacée vers le cloud. Microsoft et le secteur au sens large utilisent ces six stratégies — également appelées modèles de migration — afin de rendre les décisions concernant le portefeuille efficaces et cohérentes. Plutôt que d’appliquer une approche universelle, les architectes évaluent chaque application individuellement et lui attribuent le R le plus approprié.

Le rehébergement (Lift and Shift) consiste à déplacer une charge de travail vers Azure sans modifier le code. Vous prenez l’image de VM ou le binaire d’application existant et l’exécutez sur l’IaaS Azure. Il s’agit de la stratégie la plus rapide, généralement utilisée pour les applications anciennes difficiles à modifier ou lorsque les délais de migration sont stricts. Le moteur de réplication d’Azure Migrate automatise le reh Hébergement de la plupart des VM Windows et Linux.

Le replatforming (également appelé Lift, Tinker, and Shift) consiste à effectuer de petites optimisations pendant la migration, sans modifier l’architecture fondamentale. Par exemple, vous pouvez déplacer une base de données MySQL autogérée d’une VM vers Azure Database for MySQL, ou remplacer un relais SMTP autohébergé par Azure Communication Services. Vous bénéficiez ainsi des avantages d’un service managé — correctifs, sauvegardes et mise à l’échelle — sans réécrire la logique de l’application.

La réarchitecture (ou refactorisation) consiste à modifier considérablement l’architecture de l’application afin de tirer parti des fonctionnalités natives du cloud. Une application monolithique .NET peut être divisée en microservices déployés sur Azure Container Apps, ou un système de traitement par lots fondé sur des tâches cron peut être réimplémenté avec Azure Functions. La réarchitecture offre les plus grands bénéfices à long terme en matière d’évolutivité et de coût, mais elle exige l’investissement le plus important.

La reconstruction consiste à abandonner entièrement l’application existante et à créer une nouvelle solution native du cloud. Cette stratégie est choisie lorsque l’application ancienne est trop coûteuse à maintenir, utilise une pile technologique en fin de vie ou ne peut tout simplement pas répondre aux exigences métier, même après sa migration. La reconstruction offre l’avantage maximal du cloud natif, mais son délai avant création de valeur est le plus long. Les services PaaS et sans serveur Azure, tels que Azure App Service, Azure Functions et Cosmos DB, sont des cibles courantes.

Le remplacement consiste à remplacer une application sur site existante par un produit SaaS disponible dans le commerce, offrant des fonctionnalités équivalentes ou supérieures. Par exemple, vous pouvez remplacer un CRM sur site par Dynamics 365, ou un serveur de fichiers ancien par SharePoint Online. Le remplacement élimine entièrement la gestion de l’infrastructure. En contrepartie, la personnalisation est réduite et la migration des données ainsi que la gestion du changement peuvent demander un effort considérable.

Le retrait est la stratégie la plus simple : vous identifiez les applications qui ne sont plus utilisées, qui sont redondantes ou qui ont été remplacées, puis vous les mettez hors service au lieu de les migrer. Les données de découverte recueillies par Azure Migrate révèlent souvent qu’un pourcentage important (parfois 20 à 30 %) des serveurs sur site présente une très faible utilisation ou aucun utilisateur actif. Le retrait de ces applications réduit l’étendue de la migration, les coûts de licence et la complexité opérationnelle.

Pour sélectionner le R approprié, vous devez analyser quatre facteurs pour chaque application : l’importance pour l’entreprise, la complexité technique, le calendrier de migration et le coût total de possession. Une interface web simple, sans dépendances d’intégration, est une bonne candidate au reh Hébergement. Une application comportant des centaines de procédures stockées et des fonctionnalités de base de données personnalisées peut nécessiter une réarchitecture ou une reconstruction. Les outils internes à faible valeur sont de bons candidats au retrait ou au remplacement.

Azure Migrate fournit une fonctionnalité Business Case qui suggère automatiquement une stratégie de migration pour les serveurs découverts, en fonction des données d’utilisation, des licences et des tarifs Azure. Elle regroupe les charges de travail dans les catégories Rehost, Replatform et End-of-Support, ce qui vous donne une première classification selon les 6 R. Vous pouvez remplacer toute recommandation et ajouter votre propre contexte métier avant de finaliser le plan de migration.

Une fois qu’un R a été attribué à chaque application, vous les regroupez en vagues de migration. Les candidates au reh Hébergement présentant peu de risques constituent généralement la première vague, afin de renforcer la confiance de l’équipe et sa maîtrise des outils. Les projets de réarchitecture et de reconstruction sont menés en parallèle, dans des flux de travail dont les échéances sont plus longues. Les dépendances entre les applications — par exemple, une couche web qui appelle une base de données partagée — doivent être respectées afin que les applications liées migrent ensemble ou dans le bon ordre.

Les 6 R s’alignent sur la phase Adopt du Cloud Adoption Framework de Microsoft. Le CAF fournit des modèles de planification des vagues, des matrices RACI et des questionnaires d’évaluation des charges de travail qui permettent de mettre en œuvre les 6 R à l’échelle de l’entreprise. Les garde-fous de gouvernance établis pendant la phase Ready — zones d’atterrissage, stratégies et identité — doivent être en place avant le début des vagues de migration, afin que les charges de travail migrées arrivent dès le premier jour dans un environnement conforme.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris que le framework des 6 R (Rehost, Replatform, Rearchitect, Rebuild, Replace, Retire) fournit un vocabulaire pour les décisions de migration, que chaque R implique un compromis différent entre coût et rapidité, et que le Business Case d’Azure Migrate peut suggérer automatiquement des stratégies à partir des données d’utilisation. Nous allons maintenant découvrir comment Azure Migrate détecte et évalue les serveurs sur site.