Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure Migration Hub fournit des conseils préscriptifs et opinionés pour aider les équipes de charge de travail à planifier et à implémenter leur migration vers Azure. Il couvre les migrations à partir d’environnements locaux et de plateformes cloud telles qu’Amazon Web Services (AWS) et Google Cloud Platform (GCP).
Important
Ce contenu couvre les migrations à charge de travail unique. Il ne couvre pas les migrations complètes de centres de données, les réinstallations de régions ou les charges de travail hybrides qui s’exécutent simultanément sur plusieurs clouds.
La migration vers Azure implique la mise en réseau, l’identité, les bases de données, le calcul, le stockage et les intégrations personnalisées que votre équipe a créées au fil des ans. Plusieurs articles et guides fournissent des conseils pour ces composants.
Cet article vous aide à identifier les conseils qui s’appliquent à votre situation. Selon la charge de travail actuelle, il vous oriente vers le bon guide de migration. Il explique également la terminologie et les stratégies générales de migration.
Qui doit lire cet article
Cet article aide les architectes de charge de travail et les ingénieurs à commencer à migrer des charges de travail vers Azure à partir d’AWS, GCP ou d’un centre de données local. Utilisez ces conseils pour déterminer si vous devez réhéberger, replatformer ou refactoriser.
Ces conseils concernent les éléments suivants :
Architectes de charge de travail qui remanient les aspects de l’architecture et valident la conception globale pour répondre aux exigences métier sur Azure. Les architectes répondent aux lacunes en tenant compte des caractéristiques spécifiques de la charge de travail et des contraintes métier.
Les membres de l’équipe de charge de travail qui doivent comprendre comment leurs responsabilités changent pendant et après la migration. Par exemple, les administrateurs de base de données qui gèrent des scripts et effectuent des sauvegardes quotidiennes sur Amazon Relational Database Service doivent s’adapter à l’exécution des mêmes tâches sur Azure SQL Database.
Cet article vous dirige vers le guide de migration spécifique de votre scénario, ce qui vous permet de commencer à planifier immédiatement.
Stratégies de migration
Les stratégies de migration varient en risques, en effort et en récompense. Choisissez une stratégie basée sur la complexité, la chronologie et le niveau de modification souhaité de votre charge de travail.
Réhébergement (lift-and-shift) : Déplacez la charge de travail vers l’infrastructure Azure sans modification du code. Cette approche est rapide et à faible risque. Cela fonctionne bien pour les charges de travail simples où la vitesse importe le plus. Par exemple, vous pouvez migrer une application web d’une machine virtuelle Windows Server vers une machine virtuelle Azure. Vous bénéficiez des avantages de l’infrastructure Azure sans modifier l’architecture ou le code de la charge de travail. Vous modifiez l’emplacement d’exécution de l’application web, et non la façon dont elle s’exécute.
Migration de plateforme (lever, ajuster et déplacer) : Effectuez des modifications minimales pour tirer avantage des services de la plateforme Azure. Par exemple, migrez une base de données SQL Server vers Azure SQL Managed Instance pour obtenir des avantages opérationnels sans réécrire l’application.
Refactor: Restructurez le code pour améliorer les performances, l’extensibilité ou la maintenance sans modifier le comportement externe de la charge de travail. Par exemple, refactorisez une application .NET monolithique à exécuter sur Azure App Service en remplaçant la gestion des chemins d’accès de fichiers spécifiques à Windows, la gestion des états de session et la journalisation des disques locaux. La refactorisation nécessite davantage d’efforts initiaux, mais réduit la surcharge opérationnelle à long terme.
Réarchitecture : Redéfinissez la charge de travail pour tirer pleinement parti des fonctionnalités natives Azure. Par exemple, reconcevoir une application web pour utiliser Azure Functions et Azure Cosmos DB au lieu de machines virtuelles et SQL Server. Cette approche nécessite des modifications significatives du code, mais offre les améliorations les plus importantes en matière d’extensibilité, de performances et de coût.
Retraite: Désaffectez les charges de travail dont vous n’avez plus besoin. Utilisez cette stratégie pour les charges de travail obsolètes ou redondantes, ou quand une solution SaaS (Software as a Service) peut remplacer les fonctionnalités. Par exemple, retirez un serveur de fichiers local après avoir migré ses données vers Azure Files et entraînez les utilisateurs à accéder aux fichiers sur le nouvel emplacement.
Remplacer: Adoptez un service cloud prêt à l’emploi au lieu de migrer votre implémentation existante. Envisagez cette option lorsqu’une solution SaaS répond mieux à vos besoins que le déplacement de la charge de travail vers Azure.
Reconstruire: Créez une nouvelle implémentation lorsque le coût des autres stratégies de migration dépasse leurs avantages. La reconstruction fonctionne bien pour les charges de travail héritées qui nécessitent des modifications fondamentales pour s’exécuter efficacement dans le cloud. Par exemple, regénérer un système de gestion des relations client (CRM) personnalisé à l’aide de Dynamics 365 lorsque le codebase existant est difficile à gérer ou ne s’aligne pas correctement avec les services Azure.
Conserver: Conservez la charge de travail localement lorsque la conformité, la latence ou les contraintes techniques rendent la migration impraticable. Par exemple, conservez un système mainframe hérité que vous ne pouvez pas réhéberger ou refactoriser facilement ou qui ne dispose pas d’un chemin de migration clair vers Azure.
La plupart des migrations de charge de travail dans Azure Migration Hub utilisent une approche réhébergement ou ré-plateformage. Ces stratégies réduisent les risques en conservant la charge de travail fonctionnellement identique. Les fonctionnalités doivent respecter les mêmes indicateurs de performance clés (KPI), les contrats de niveau de service (SLA) et les objectifs de niveau de service (SLA) sur Azure qu’ils ont rencontrés sur la plateforme source. Effectuez d’abord la migration, puis optimisez et moderniser.
Pour plus d’informations, consultez Sélectionner une stratégie de migration cloud.
Parcours de migration
Chaque migration suit cinq phases. Certaines phases se chevauchent et vous pouvez revoir les phases antérieures au fur et à mesure que vous en apprenez davantage sur les exigences de la charge de travail, mais la séquence vous aide à suivre la progression.
| Phase | Tasks | Résultat |
|---|---|---|
| Planification | Évaluez votre charge de travail actuelle, identifiez les dépendances, mappez les services sources à des équivalents Azure et définissez les critères de réussite. | Documentation claire sur l’étendue de la migration, les modifications requises et les critères d’achèvement. |
| Préparer | Configurez votre environnement Azure, notamment les zones d’atterrissage, la mise en réseau, l’identité et la gouvernance. Concevoir l’architecture d’état cible. | L’environnement Azure configuré est prêt à recevoir la charge de travail, avec toutes les décisions architecturales résolues avant le début de la migration. |
| Exécuter | Migrez les composants d’infrastructure, de données et d’application. Effectuez des tests itératifs et une transition. | Composants de charge de travail migrés vers Azure. Le trafic de production a été redirigé vers Azure après la validation réussie de la charge de travail. |
| Évaluer | Vérifiez que la charge de travail migrée répond aux exigences fonctionnelles, de performances, de sécurité et de coût par rapport à la base de référence que vous avez définie à la phase 1. | Confirmation que la migration réussit et que la charge de travail s’exécute correctement sur Azure. |
| Mise hors service | Mettre hors service l’environnement source. Supprimez les ressources, annulez les abonnements et arrêtez l’ancienne plateforme. | La charge de travail d'origine est arrêtée. Azure exécute désormais la charge de travail exclusivement. |
Conseils sur la migration
Cette section répertorie les types de conseils de migration fournis par Azure. Chaque guide vous aide à planifier et à gérer votre migration.
Framework d’adoption du cloud pour Azure
Cloud Adoption Framework pour Azure couvre la planification au niveau de l’organisation. Il décrit comment structurer votre migration, les étapes à suivre et la configuration avant de déplacer des charges de travail.
Si vous débutez avec Azure, commencez ici. Le Framework d’adoption du cloud vous guide tout au long de la préparation organisationnelle. Il décrit la mise en place de l'abonnement Azure, le déploiement de la zone d'accueil de la plateforme et la hiérarchisation du plan de migration. Effectuez ces étapes fondamentales avant de déplacer des charges de travail.
Centre d’architecture Azure
Le Centre d’architecture Azure fournit des idées de solution, des architectures, des modèles de conception et des guides d’architecture pour la création de charges de travail sur Azure.
La plupart des migrations impliquent un changement de plateforme. Vous déplacez la couche d’infrastructure et de gestion de votre cloud source vers Azure. Tous les composants sources ne disposent pas d’un équivalent Azure direct. Vous devrez peut-être modifier les parties de l’architecture. Le Centre d’architecture Azure fournit une vue d’ensemble des choix technologiques et vous aide à trouver la correspondance la plus proche.
Azure Well-Architected Framework
Azure Well-Architected Framework fournit des principes pour la création de systèmes cloud fiables, sécurisés, rentables et efficaces. Il inclut des conseils généraux sur l’architecture et des guides spécifiques au service pour les services Azure. Ces guides décrivent les meilleures pratiques essentielles pour vous aider à prendre des décisions architecturales pour votre charge de travail. Utilisez-les pour évaluer votre architecture après la migration et trouver des zones à améliorer.
Commencer par votre plateforme source
Pour commencer, comparez les fonctionnalités de votre charge de travail et de ses services avec leurs équivalents Azure les plus proches. Les articles suivants incluent des exemples de scénarios et des guides de migration au niveau du service pour illustrer les comparaisons.
Outils de migration
Utilisez les outils suivants pour prendre en charge les tâches de migration quel que soit votre plateforme source. Ils vous aident à mesurer la réussite de la migration par rapport aux objectifs métier.
| Tool | Objectif |
|---|---|
| Azure Migrate et Modernize | Découvrez et évaluez les ressources de migration, notamment l’infrastructure, les applications et les composants de données. |
| Well-Architected Passer en revue l’évaluation de la plateforme source | Passez en revue et mesurez les objectifs métier de votre architecture sur la plateforme source. Cette évaluation de votre fournisseur de cloud source vous aide à définir une base de référence pour vos attentes sur Azure. |
| Évaluation de la révision d’Azure Well-Architected | Évaluez vos décisions d’architecture pour identifier les régressions de la base de référence source et explorer les opportunités d’optimisation. |
Étape suivante
Le Cloud Adoption Framework couvre le séquencement de migration, la planification des vagues, le mappage des dépendances et l’alignement des parties prenantes. Pour une planification au niveau de l’organisation ou pour choisir une stratégie de migration, consultez Planifier votre migration.