Partager via


Évaluer vos charges de travail pour la migration cloud

La phase d’évaluation garantit une visibilité complète de chaque composant, dépendance et exigence avant de passer à Microsoft Azure. En collectant des informations détaillées sur l’architecture, les performances, la sécurité, le code et les bases de données, vous pouvez anticiper les problèmes, réduire les risques et prendre des décisions de migration éclairées.

Type de charge de travail Outil de découverte Outil d’évaluation Examples
On-premises Azure Migrate Azure Migrate
Dr Migrate
• Serveurs physiques
• Machines virtuelles VMware
• machines virtuelles Hyper-V
• Bases de données SQL
• Applications web
Infrastructure AWS (IaaS, Infrastructure en tant que service) Azure Migrate Azure Migrate
• Guide de AWS vers Azure
• Instances EC2 AWS
• Bases de données AWS RDS
• Volumes EBS AWS
Google Cloud Infrastructure (IaaS) Azure Migrate Azure Migrate
• Conseils sur la migration de Google Cloud vers Azure
• Machines virtuelles du moteur de calcul Google Cloud
• Google Cloud SQL
• Disque persistant Google Cloud
Services de plateforme AWS (PaaS) Explorateur de ressources AWS • Conseils de migration AWS vers Azure
Comparaison des services AWS et Azure
Cloudockit
• AWS Lambda
• AWS Elastic Beanstalk
• AWS DynamoDB
Google Cloud Platform Services (PaaS) Inventaire des Actifs de Google Cloud • Conseils sur Google Cloud vers Azure
Comparaison des services Google Cloud et Azure
Cloudockit
• Google Cloud BigQuery
• Google Cloud App Engine
• Google Cloud Run Fonctions
Code d’application CAST Highlight
Dr Migrate
Dr Migrate
CloudPilot
CAST Highlight
CloudAtlas
GitHub Copilot
• GitHub
• Azure Repos
• GitLab

Évaluer l’architecture de la charge de travail

Une évaluation architecturale complète vous donne une visibilité sur tous les composants de charge de travail et leur interaction. Cette visibilité prend en charge la planification précise de la migration en identifiant les composants qui doivent se déplacer ensemble et les composants susceptibles de nécessiter une modification.

  1. Utilisez les outils d’évaluation. Les outils comme Azure Migrate ou d’autres produits automatisent la découverte des composants et configurations de charge de travail. Ces outils réduisent les efforts manuels et fournissent une collecte de données cohérente dans votre environnement, mais ils peuvent manquer certaines dépendances non documentées. Vous pouvez utiliser un outil comme Cloudockit pour générer vos diagrammes. Vous pouvez également créer vos propres diagrammes à l’aide d’icônes Azure ou modifier les diagrammes téléchargeables dans Le Centre d’architecture Azure.

  2. Confirmez l’architecture avec une expertise en la matière. Les propriétaires de charge de travail peuvent confirmer les résultats des outils et identifier les informations manquantes ou obsolètes. Effectuez des entrevues ou des sessions d’examen de l’architecture pour combler les lacunes dans les données de découverte automatisées.

  3. Architecture de document. Stockez des diagrammes d’architecture, des listes de composants et des données de configuration dans un format prenant en charge la planification et la validation. Utilisez des outils tels que Microsoft Visio, des feuilles de calcul ou des wikis Azure DevOps pour gérer ces informations.

Évaluer les composants de charge de travail

Pour chaque charge de travail, collectez des métriques détaillées de performances et d’utilisation de référence à partir de l’environnement actuel. Ces données sont essentielles pour dimensionnement approprié des ressources Azure et pour comparer les performances après la migration.

  1. Rassemblez les métriques de charge de travail. Suivez l’utilisation du processeur, l’utilisation de la mémoire, les E/S disque (lectures/écritures, E/S par seconde), le débit réseau et la concurrence maximale ou la charge utilisateur. Identifiez les pics quotidiens ou hebdomadaires pour comprendre les besoins de capacité. Mesurez les temps de réponse moyens pour les transactions utilisateur, le débit des travaux traités par heure et toutes les métriques liées au contrat SLA. Ces informations permettent de garantir que les charges de travail migrées répondent aux mêmes exigences en matière de performances métier.

  2. Capturez les détails de configuration. Notez les configurations de mise à l’échelle, les tailles de machine virtuelle actuelle, les spécifications de serveur physique (cœurs de processeur, RAM), le type et la version du système d’exploitation, le type de stockage (SSD/HDD) et la capacité, ainsi que tout matériel spécial comme les GPU. Ces détails informent le choix des tailles de machine virtuelle Azure ou des services PaaS. Enregistrez également les informations de licence logicielle. Ces informations peuvent activer l’utilisation d’Azure Hybrid Benefit ou nécessiter une migration de licence.

  3. Documentez toutes les configurations de sécurité et d’identité. Stockez toutes les configurations de sécurité et d’identité : répertorier les comptes de service, les informations d’identification codées en dur, les méthodes de chiffrement utilisées et les règles de pare-feu. Ces configurations doivent être répliquées ou ajustées dans Azure.

    Composant de sécurité Action Purpose
    Inventaire des identités Enregistrer tous les comptes de service, comptes d’utilisateur et clés API que les applications utilisent pour l’authentification Affecte le séquencement de la migration lorsque vous choisissez entre les approches de "lift-and-shift" ou de modernisation.
    Documentation sur le chiffrement Documenter les méthodes de chiffrement actuelles pour les données au repos et en transit Associer ces exigences aux services de chiffrement Azure afin de respecter les normes de sécurité.
    Configuration de la sécurité réseau Capturer des règles de sécurité réseau, des configurations de pare-feu et des listes de contrôle d’accès Utilisez ces informations pour concevoir des groupes de sécurité réseau Azure et des stratégies d’accès
  4. Identifiez les problèmes de compatibilité. Les outils automatisés fournissent une analyse systématique des systèmes d’exploitation, des intergiciels et des infrastructures d’application par rapport aux stratégies de support Azure. Ces outils signalent les composants qui ne sont pas pris en charge, déconseillés ou approchent de la fin de la prise en charge. Les outils tels qu’Azure Migrate et d’autres outils d’évaluation peuvent détecter ces problèmes dans votre environnement sans révisions manuelles de configuration.

  5. Répertorier les corrections requises. Créez une liste complète de tous les problèmes de compatibilité et de leurs exigences de correction. Hiérarchiser celles qui doivent être corrigées avant la migration (bloqueurs) et celles qui peuvent être traitées après la migration si nécessaire. Engagez les fournisseurs si nécessaire pour comprendre les chemins de mise à niveau pour les logiciels commerciaux.

Mapper les dépendances internes et externes

  1. Mappez les dépendances internes. Mapper la façon dont les composants d’une charge de travail communiquent entre eux et avec d’autres systèmes au sein de votre organisation. Utilisez les outils de supervision réseau ou la surveillance des performances des applications pour voir les connexions d’exécution entre les services. Ce mappage vous permet de déterminer le regroupement dans les vagues de migration. Par exemple, si l’application A appelle constamment la base de données B, vous les migrez ensemble ou fournissez une connectivité réseau entre Azure et l’environnement source jusqu’à ce que les deux soient dans le cloud.

  2. Identifiez toutes les dépendances externes. Répertoriez les services externes avec lesquels la charge de travail interagit. Ces dépendances incluent les plateformes SaaS, les API partenaires, les systèmes locaux et les services tiers dont les applications ont besoin pour fonctionner correctement. Vous devez cataloguer toutes les intégrations en amont et en aval, les services partagés et les pipelines de données pour comprendre le paysage complet des dépendances. Documentez les API, les systèmes de messagerie, les processus ETL, les bases de données partagées, les méthodes d’authentification, les modèles d’échange de données et les contrats de niveau de service. Passez en revue la documentation d’intégration et effectuez des entretiens avec les propriétaires d’applications pour garantir une visibilité complète de toutes les connexions externes. Ce mappage complet empêche les échecs d’intégration et prend en charge le séquencement de migration précis.

  3. Impliquer les responsables de charge de travail pour validation et complétion des données de dépendance. Les propriétaires de charge de travail offrent des insights critiques sur le comportement du système, les ressources partagées et les intégrations informelles que les outils peuvent ne pas détecter. Vous devez effectuer des entretiens structurés ou des ateliers avec les propriétaires d’applications et de charges de travail pour valider les données générées par les outils et identifier les dépendances non documentées. Cette étape garantit l’exhaustivité et la précision de la carte de dépendances et permet de capturer le contexte métier qui informe le séquencement de migration.

  4. Documentez toutes les dépendances dans un référentiel central. Stockez les données de dépendance dans un format prenant en charge la collaboration entre équipes et la planification de la migration, telles que les feuilles de calcul, les diagrammes d’architecture ou les outils de mappage de dépendances. Vérifiez que le référentiel est accessible et régulièrement mis à jour pour refléter les modifications pendant le processus de migration.

  5. Utilisez des dépendances pour planifier les migrations. Organisez les charges de travail en vagues de migration qui réduisent les dépendances rompues. Pour plus d’informations, consultez planification des vagues de migration.

Évaluer la conformité et les exigences opérationnelles

  1. Identifiez les exigences de conformité réglementaire. Une compréhension claire des exigences de conformité réglementaire garantit que votre architecture Azure s’aligne sur les obligations légales, sectorielles et organisationnelles. Ces exigences influencent la sélection de la région, la disponibilité du service, la protection des données et les décisions architecturales. Les normes réglementaires et de conformité incluent des politiques globales, régionales, spécifiques au secteur et internes. Ces normes peuvent inclure LE RGPD, HIPAA, FedRAMP, ISO 27001 ou des réglementations financières telles que SOX. Chaque norme impose des exigences spécifiques sur la gestion des données, le contrôle d’accès, le chiffrement et l’auditabilité. Vous devez identifier toutes les normes applicables pour chaque charge de travail en consultant les parties prenantes juridiques, de conformité et de sécurité.

  2. Documentez les SLA, les RPO et les RTO. Les contrats de niveau de service (SLA), les objectifs de point de récupération (RPO) et les objectifs de temps de récupération (RTO) définissent des niveaux acceptables de disponibilité et de perte de données. Les métriques orientent la conception des stratégies de sauvegarde, de réplication et de basculement. Vous devez documenter ces valeurs pour chaque charge de travail pour vous assurer que l’architecture répond aux attentes en matière de continuité d’activité. Consultez Définir les exigences de fiabilité.

  3. Classifiez chaque environnement de charge de travail. Les charges de travail s’exécutent généralement dans des environnements de production, de test ou de développement. Chaque environnement a des exigences de disponibilité, de sécurité et de performances différentes. Vous devez documenter la classification de l’environnement pour chaque charge de travail afin d’informer le séquencement de migration, les contrôles d’accès et l’allocation des ressources.

  4. Valider l’intégration d’ISV à Azure. De nombreuses charges de travail dépendent des logiciels des éditeurs de logiciels indépendants (ISV). Vous devez confirmer que tous les logiciels ISV sont compatibles avec Azure avant la migration. Utilisez la documentation du fournisseur, les environnements de test ou effectuez une validation directe avec le fournisseur indépendant de logiciels. Identifiez les mises à jour, remplacements ou modifications de configuration nécessaires. Déterminez également si Azure Hybrid Benefit ou d’autres modèles de licence s’appliquent. Incluez les coûts de licence et les ajustements de compatibilité dans votre plan de migration pour un budget et une planification précis.

Évaluer le code de l’application

Une évaluation du code d’application identifie les problèmes de compatibilité et les opportunités de modernisation qui peuvent affecter la réussite de la migration. Cette évaluation est essentielle pour garantir que les applications s’exécutent de manière fiable dans Azure et pour planifier efficacement les vagues de migration. Vous devez évaluer le code d’application pour détecter les bloqueurs tôt, réduire le risque d’échec de migration et informer les décisions d’architecture cibles.

Utiliser des outils automatisés pour évaluer le code d’application

  1. Utilisez l’outil de modernisation des applications GitHub Copilot (.NET et Java). La modernisation des applications GitHub Copilot fournit des évaluations détaillées pour les charges de travail .NET et Java. Il combine les fonctionnalités d’évaluation d’AppCAT avec l’assistance basée sur l’IA de Copilot pour accélérer et faciliter la modernisation. Cette intégration agit en tant que partenaire de codage, ce qui vous aide à :

    • Capturer les dépendances liées à l’application
    • Réviser et optimiser le code source pour les services Azure
    • Mettre à jour le code et corriger les vulnérabilités et expositions courantes (CVE)
    • Conteneuriser des applications pour un déploiement flexible
    • Générer des fichiers de déploiement pour simplifier la migration
    • Réduire les efforts avec le codage assisté par l’IA
  2. Utilisez des outils tiers pour d’autres langages d’application. Les outils tels que CloudPilot et CAST Highlight prennent en charge des langages tels que Python, JavaScript, Node.jset Go. Ces outils identifient les modifications au niveau du code requises pour la compatibilité Azure et fournissent des insights de modernisation. Utilisez ces outils pour évaluer les charges de travail non-.NET et non Java.

  3. Utilisez les résultats de l’évaluation pour informer les décisions d’architecture cibles. Les résultats de compatibilité des applications peuvent influencer la sélection des services Azure. Par exemple, une application qui n’est pas compatible avec un service peut être compatible avec une autre avec des modifications de code minimales. Par exemple, les services comme Azure App Service nécessitent généralement moins de modifications de code, tandis que les services de plateforme de conteneurs peuvent nécessiter davantage de mises à jour de code avant le déploiement. Utilisez cette flexibilité pour migrer les applications plus tôt et différer la modernisation du code vers une phase ultérieure. Cette approche réduit le risque de migration et accélère le temps vers le cloud.

Valider la compatibilité du framework et du SDK

  1. Comprendre la compatibilité du code. La compatibilité du framework et du SDK garantit que les applications s’exécutent de manière fiable dans Azure. Les versions non prises en charge ou les kits SDK incompatibles peuvent entraîner des défaillances d’exécution ou nécessiter une rework importante. Vous devez vérifier qu’Azure prend en charge la version et l’infrastructure linguistiques de votre application.

  2. Vérifiez la prise en charge d’Azure pour le langage et l’infrastructure de votre application. Vérifiez qu’Azure prend en charge votre version de .NET, Java, Python, JavaScript, Node.jset Go. Utilisez la documentation Azure officielle pour valider la compatibilité.

  3. Évitez les modifications inutiles du framework. Migrez uniquement vers un nouveau framework (par exemple, Microsoft .NET Framework vers .NET Core) s’il existe une justification métier forte. Les modifications du framework nécessitent des efforts de développement et des tests importants.

Évaluer les bases de données

Les dépendances de base de données déterminent souvent la réussite de la migration d’applications. Les bases de données partagées, les dépendances inter-applications et les modèles d’intégration peuvent compliquer la planification de la migration. Vous devez évaluer les bases de données qui prennent en charge vos applications et comprendre leurs dépendances. Suivez ces instructions :

  1. Identifiez toutes les bases de données utilisées par l’application. Créez un inventaire complet de toutes les bases de données utilisées par l’application. Incluez les types de moteur de base de données (SQL Server, MySQL), les versions et les modèles d’hébergement (par exemple, locaux, IaaS, PaaS). Utilisez des outils, tels qu’Azure Migrate, pour collecter ces informations systématiquement. Spécifiez si la base de données est auto-hébergée, hébergée sur des machines virtuelles ou remise en tant que service managé. Ces informations permettent de déterminer la préparation de la migration et la compatibilité de la plateforme cible.

  2. Mapper les dépendances entrantes et sortantes. Une vue claire de la façon dont les données circulent vers et hors de chaque base de données est essentielle pour le séquencement des migrations et éviter les interruptions de service. Les dépendances couvrent souvent plusieurs applications, services et systèmes externes. Incluez des applications internes, des API, des travaux par lots, des outils de création de rapports et d’autres intégrations. Spécifiez si la dépendance est en lecture seule, en écriture seule ou bidirectionnelle. Ce détail permet de hiérarchiser les charges de travail et d’identifier les bloqueurs de migration potentiels.

  3. Déterminez la stratégie de migration de base de données. Déterminez s’il faut déplacer la base de données en tant qu’instance partagée ou la fractionner par charge de travail. Les bases de données partagées simplifient la gestion, mais peuvent retarder la migration si plusieurs applications en dépendent. Le fractionnement des bases de données permet une migration indépendante, mais nécessite une coordination et des tests prudents. Assurez-vous que le plan de migration de base de données prend en charge le séquencement des déplacements d’applications et réduit les temps d’arrêt ou les interruptions de service.

Créer et gérer un registre de risques

Un registre de risques est un document ou un outil que vous utilisez pour identifier, évaluer, hiérarchiser et surveiller les risques potentiels susceptibles d’affecter l’adoption du cloud. Il décrit les stratégies d’atténuation. Le maintien de ce registre garantit une gestion proactive des risques.

  1. Établissez un registre de risques pour toutes les charges de travail. Enregistrer les risques liés aux facteurs techniques, opérationnels et organisationnels. Ce registre fournit une visibilité sur les bloqueurs potentiels et leur valeur.

  2. Définissez des stratégies d’atténuation et suivez leur état. Pour chaque risque, documentez les actions d’atténuation, les parties responsables et les chronologies de résolution. Ce suivi garantit que vous gérez et résolvez activement les risques.

Pour plus d’informations, consultez CAF Govern - Évaluer les risques cloud

Ressources et outils Azure

Category Tool Description
Découverte et évaluation Azure Migrate Découverte et évaluation complètes pour les serveurs, bases de données et applications locaux
Serveurs avec Arc Azure Arc Étend la gestion Azure aux environnements locaux et multiclouds
Évaluation du code GitHub Copilot Analyse de compatibilité automatisée pour les applications .NET et Java
Migration de base de données Assistant de migration des données Outil d’évaluation et de migration pour les bases de données SQL Server
Cartographie multicloud Mappage de service AWS vers Azure Guide de comparaison des services pour AWS vers Azure
Cartographie multicloud Le mappage de services de Google Cloud vers Azure Guide de comparaison des services pour la migration de Google Cloud vers Azure
Développement Azure .NET sur Azure Conseils pour accéder aux services Azure à partir d’applications .NET
Développement Azure Java sur Azure Ressources pour les développeurs Java qui s’appuient sur Azure
Développement Azure Python sur Azure Ressources pour les développeurs Python qui s’appuient sur Azure
Développement Azure JavaScript et Node.js sur Azure Conseils pour le développement JavaScript et Node.js sur Azure
Développement Azure Accéder à Azure Ressources pour les développeurs Go qui s’appuient sur Azure
Framework d’adoption du cloud Définir les exigences de fiabilité Conseils pour la définition des exigences de fiabilité pour les charges de travail cloud

Étapes suivantes