La plupart des programmes de migration vers le cloud commencent par une analyse de l'infrastructure. Azure Migrate détecte les machines virtuelles. AWS Application Discovery Service cartographie les serveurs. Google Migration Center recense les charges de travail. En quelques jours, l'équipe dispose d'un tableau récapitulatif de chaque serveur, de son utilisation du processeur, de son empreinte mémoire et d'une estimation du coût d'exécution d'une configuration équivalente dans le cloud cible. L'évaluation de l'infrastructure est terminée. La planification peut commencer.
Sauf que non. L'inventaire de l'infrastructure indique quel matériel exécute vos applications, mais pas si ces applications peuvent fonctionner dans le cloud, ni le coût de leur adaptation, ni celles qui présentent des dépendances incompatibles lors de la migration, ni celles qui utilisent des API obsolètes non prises en charge par la plateforme cloud, ni celles qui contiennent une logique métier non documentée, fruit de dix ans d'expérience, qu'il faudra comprendre avant toute validation de conversion. La découverte de l'infrastructure est un prérequis à l'évaluation de la migration vers le cloud. Elle ne constitue pas l'évaluation elle-même.
Évaluez votre code avant de le déplacer.
SMART TS XL cartographie chaque dépendance, chaque blocage et chaque candidat à la refactorisation dans l'ensemble de votre portefeuille d'applications.
En savoir plusQu’est-ce qu’une évaluation de migration vers le cloud ?
Une évaluation de migration vers le cloud est une analyse structurée qui détermine si, comment et à quel coût un ensemble de charges de travail peut être transféré vers le cloud. Elle fournit les éléments nécessaires à trois décisions : la stratégie de migration à appliquer à chaque charge de travail, le coût réel de la migration en termes d’efforts et de dépenses cloud, et l’ordre de migration des charges de travail afin de gérer les risques liés aux dépendances.
Une évaluation complète de la migration vers le cloud s'articule autour de cinq dimensions distinctes. Les outils de découverte d'infrastructure en couvrent une. Les quatre autres requièrent des outils, des techniques et une expertise différents.
| Dimension d'évaluation | Ce à quoi il répond | Outils primaires |
|---|---|---|
| Infrastructure | Quels serveurs, machines virtuelles et services existent ? Quels sont leurs profils d'utilisation ? | Azure Migrate, AWS Application Discovery, Google Migration Center |
| Code d'application | Le code est-il compatible avec les cibles cloud ? Que faut-il modifier ? | CAST Highlight, SMART TS XLModernisation des applications CloudPilot et GitHub Copilot |
| Centres de données | Quels sont les volumes de données existants ? Où sont stockées les données ? Quelles sont la complexité de la migration et les contraintes de conformité ? | AWS Database Migration Service, Azure Database Migration Service, Striim |
| Sécurité et conformité | Quelles sont les exigences réglementaires applicables ? Quelles failles de sécurité existent ? Quelles modifications sont nécessaires en matière de gestion des identités et des accès (IAM) et de chiffrement ? | AWS Security Hub, Microsoft Defender for Cloud, Prisma Cloud |
| Coût et TCO | Quel est le coût total de la migration et le coût total de possession après la migration ? | Calculateur de prix AWS, Calculateur de coût total de possession Azure, Infracost, Capacité cloud d'Apptio |
Les organisations qui ne gèrent que l'infrastructure élaborent des plans de migration dont la portée est incertaine. Elles découvrent les problèmes liés aux applications, aux données, à la sécurité et aux coûts lors de la migration, au moment où le coût de leur résolution est le plus élevé.
Les cinq dimensions de l'évaluation de la migration vers le cloud
Évaluation des infrastructures
L'évaluation de l'infrastructure est le point de départ. Elle recense l'environnement source : chaque serveur, machine virtuelle, conteneur et service, avec sa configuration, ses données d'utilisation et ses dépendances vis-à-vis des autres composants de l'infrastructure.
Des outils comme Azure Migrate, ou d'autres produits similaires, automatisent la découverte des composants et des configurations des charges de travail. Ces outils réduisent les interventions manuelles et assurent une collecte de données cohérente dans votre environnement, même s'ils peuvent ne pas détecter certaines dépendances non documentées.
Azure Migrate est la solution de référence pour les organisations qui migrent vers Azure. Elle effectue une découverte sans agent des environnements VMware vSphere, Hyper-V et des serveurs physiques, et génère des évaluations de préparation, des recommandations de dimensionnement basées sur les performances et des estimations de coûts avant même le déplacement de la moindre charge de travail.
AWS Application Migration Service (MGN) et AWS Application Discovery Service remplissent la même fonction pour les cibles AWS. Discovery Service collecte les données de configuration et de performance sur site, soit sans agent, soit via un agent installé localement.
Google Migration Center offre une solution unifiée de découverte et d'évaluation des migrations vers Google Cloud, combinant l'inventaire des actifs, l'analyse des dépendances et la modélisation du coût total de possession (TCO) dans une seule console.
Les outils d'infrastructure permettent de fournir : un inventaire des serveurs, des données de référence sur leur utilisation, des cartographies des dépendances réseau entre les composants de l'infrastructure et des recommandations de dimensionnement pour le niveau de cloud cible. En revanche, ils ne permettent pas d'évaluer la compatibilité des applications exécutées sur ces serveurs avec le cloud, d'estimer le coût des modifications de code ni de modéliser la migration des données au sein de ces applications.
Évaluation du code d'application
L'analyse du code applicatif permet d'identifier les problèmes de compatibilité et les opportunités de modernisation susceptibles d'affecter la réussite de la migration. Cette analyse est essentielle pour garantir le bon fonctionnement des applications sur Azure et planifier efficacement les phases de migration. Il est impératif d'analyser le code applicatif afin de détecter rapidement les obstacles, de réduire le risque d'échec de la migration et d'orienter les décisions relatives à l'architecture cible.
L'évaluation du code applicatif identifie quatre catégories de problèmes que l'analyse de l'infrastructure ne peut pas détecter :
Des problèmes de compatibilité peuvent survenir : API, frameworks ou fonctionnalités d’exécution inexistants ou présentant un comportement différent dans l’environnement cloud cible. Une application Java conçue pour un serveur d’applications Java EE non disponible sur la plateforme PaaS cible nécessite des modifications de code avant son déploiement. Une application utilisant une convention de chemin d’accès spécifique à Windows ne peut pas s’exécuter sur une instance cloud Linux sans modification.
Les hypothèses d'infrastructure codées en dur (adresses IP, chemins de fichiers, noms de serveurs ou numéros de ports) intégrées au code ne seront plus valides dans le cloud. Ces éléments constituent des obstacles à la migration et ne seront pas détectés par une analyse d'infrastructure, car ils se trouvent dans le code applicatif et non dans la configuration de l'infrastructure.
L'utilisation d'API obsolètes , c'est-à-dire les appels à des API, des bibliothèques ou des fonctionnalités de la plateforme non prises en charge par l'environnement cloud cible ou qui ont été remplacées, est problématique. Les fournisseurs de plateformes cloud rendent régulièrement obsolètes les anciennes versions d'API ; les applications qui les utilisent ne fonctionneront donc plus sur la nouvelle plateforme, même si elles fonctionnent correctement actuellement.
La complexité des dépendances , c'est-à-dire la structure interne de l'application, détermine la difficulté de sa migration et sa capacité à être décomposée en services déployables indépendamment. Une application monolithique fortement couplée est plus difficile et plus coûteuse à migrer qu'une application faiblement couplée, indépendamment des informations fournies par l'inventaire de l'infrastructure.
CAST Highlight réalise une évaluation automatisée du code applicatif au niveau du portefeuille, en analysant le code source dans plusieurs langages afin de générer des scores de préparation au cloud, d'identifier les obstacles et d'effectuer une analyse des risques liés aux logiciels libres. Il est référencé dans le cadre d'adoption du cloud Azure de Microsoft comme outil recommandé pour les charges de travail autres que .NET et Java.
CloudPilot est spécialisé dans l'évaluation détaillée de la préparation au cloud, avec un système de notation de la compatibilité et la génération de feuilles de route de migration pour JavaScript, Python, Node.js et Go.
GitHub Copilot App Modernization combine les capacités d'évaluation AppCAT de CAST avec la correction de code assistée par l'IA pour les charges de travail .NET et Java en particulier.
Pour les environnements d'entreprise utilisant COBOL, JCL, PL/I, RPG et d'autres langages mainframe, ainsi que des technologies modernes, ces outils ne sont pas adaptés. L'évaluation du code applicatif des systèmes existants requiert une catégorie d'outils entièrement différente.
Évaluation des données
L'évaluation des données détermine la complexité, le volume, les exigences de conformité et la méthode de migration de chaque base de données concernée. Elle est souvent sous-estimée car l'opération paraît simple : déplacer la base de données, déplacer les données… jusqu'à ce que la complexité réelle se révèle.
Les questions clés auxquelles l'évaluation des données doit répondre :
Volume et débit : Quelle est la quantité de données existantes ? Quel est le taux de changement ? Peut-on les migrer sans interruption de service, ou faut-il utiliser une réplication continue pour obtenir une transition avec un temps d’arrêt quasi nul ?
Compatibilité du schéma : Le service de base de données cible prend-il en charge les mêmes fonctionnalités de schéma, types de données et procédures stockées que la source ? Les constructions PL/SQL spécifiques à Oracle nécessitent une conversion avant la migration vers PostgreSQL ou une alternative native du cloud.
Souveraineté et conformité des données : où les données doivent-elles légalement résider ? Le RGPD, la loi HIPAA, la norme PCI-DSS et les réglementations sectorielles peuvent restreindre les régions cloud autorisées à héberger certaines catégories de données.
Couplage de l'application : Dans quelle mesure le code de l'application est-il couplé au schéma de base de données spécifique ? Une modification de schéma techniquement simple peut nécessiter d'importantes modifications du code de l'application pour être prise en compte.
AWS Database Migration Service et Azure Database Migration Service prennent en charge la réplication continue avec un temps d'arrêt minimal pour les migrations homogènes (Oracle vers Oracle, SQL Server vers SQL Server) et la conversion de schéma pour les migrations hétérogènes (Oracle vers PostgreSQL, SQL Server vers Aurora).
Striim et Attunity assurent la diffusion et la réplication de données en temps réel pour les scénarios de migration à haute disponibilité où les interruptions de service de la base de données sont inacceptables.
Évaluation de la sécurité et de la conformité
L'évaluation de sécurité cartographie la posture de sécurité actuelle de chaque charge de travail et identifie les changements nécessaires pour se conformer aux normes de sécurité du cloud, aux cadres de conformité et aux principes d'architecture zéro confiance.
Les dimensions que l'évaluation de la sécurité doit couvrir :
Gestion des identités et des accès (IAM) : Les applications sur site utilisent souvent des comptes de service dotés de privilèges étendus et une authentification par mot de passe. Les environnements cloud requièrent un contrôle d’accès basé sur les rôles, des identités de service à privilèges minimaux et une authentification par certificat ou jeton. L’écart entre l’IAM actuel et l’IAM requis représente un effort de migration indépendant de l’inventaire de l’infrastructure.
Chiffrement : Les exigences de chiffrement des données au repos et en transit diffèrent entre les environnements sur site et le cloud. Les applications qui gèrent leur propre chiffrement au niveau applicatif doivent s’intégrer aux services de gestion des clés du cloud. Les données non chiffrées, acceptables sur les réseaux privés, doivent être chiffrées avant d’être transférées vers des services hébergés dans le cloud.
Sécurité réseau : Les règles de pare-feu, la segmentation du réseau et l’inspection du trafic mises en œuvre dans le matériel réseau sur site doivent être reconstruites sous forme de groupes de sécurité cloud, de configurations de réseau virtuel et de règles de pare-feu natives du cloud.
Alignement avec les cadres de conformité : Chaque secteur réglementé possède des exigences de conformité spécifiques qui correspondent à des configurations cloud spécifiques. Les charges de travail HIPAA nécessitent des choix de configuration spécifiques pour le stockage, la journalisation des accès et le chiffrement. La norme PCI-DSS exige une segmentation du réseau qui doit être mise en œuvre différemment dans un VPC cloud que dans une infrastructure réseau physique.
Microsoft Defender for Cloud fournit une évaluation de la posture de sécurité et une évaluation de la conformité aux référentiels CIS, NIST, PCI-DSS et autres cadres pour les charges de travail Azure.
Prisma Cloud (Palo Alto Networks) et AWS Security Hub offrent une évaluation de sécurité multicloud et une surveillance de la conformité équivalentes.
Évaluation des coûts et du coût total de possession
L'évaluation des coûts est le livrable de migration le plus visible pour les parties prenantes et celui qui est le plus souvent mal réalisé. L'erreur courante consiste à comparer les coûts du matériel sur site actuel aux coûts de calcul et de stockage dans le cloud, ce qui aboutit à une comparaison incomplète et généralement trompeuse.
Une évaluation complète du coût total de possession (TCO) comprend :
Coûts de l'infrastructure cloud : coûts de calcul, de stockage, de réseau et de services gérés dans la configuration cloud cible. Un dimensionnement précis basé sur les données d'utilisation réelles (et non sur la capacité provisionnée) permet d'éviter des estimations surévaluées.
Coûts de migration : heures d’ingénierie nécessaires pour réaliser les modifications du code applicatif, la migration des données, la reconfiguration de la sécurité et les tests. Les évaluations portant uniquement sur l’infrastructure sous-estiment systématiquement ces coûts, car elles ne tiennent pas compte de la complexité de l’application.
Évolution des licences : Le passage de licences perpétuelles sur site à des modèles de licences basés sur le cloud, ou de logiciels spécifiques à un fournisseur à des alternatives natives du cloud, modifie fondamentalement la structure des coûts de licence.
Évolution du modèle opérationnel : les équipes d’exploitation sur site gérant le matériel physique sont remplacées par des équipes d’exploitation cloud gérant les services cloud. Les compétences, les outils et les effectifs évoluent.
Coûts de formation et de transition : Les équipes qui apprennent de nouvelles plateformes cloud, de nouveaux modèles de déploiement et de nouvelles procédures opérationnelles subissent des coûts de productivité pendant la transition.
Les calculateurs de prix AWS , Azure TCO et Google Cloud permettent d'évaluer le coût de l'infrastructure cloud. Infracost propose une estimation des coûts intégrée aux pipelines IaC, générant des estimations dans le cadre du processus CI/CD. Apptio Cloudability et d'autres outils FinOps similaires assurent une visibilité continue des coûts après la migration.
Les sept stratégies migratoires : comment l’évaluation détermine laquelle s’applique
Le cadre des « 7 R » décrit les stratégies disponibles pour chaque migration de charge de travail. L’évaluation détermine la stratégie appropriée ; une mauvaise évaluation conduit à l’application d’une stratégie inadaptée, principale cause des dépassements de coûts lors des migrations.
| de Marketing | Ce que cela veut dire | Signal d'évaluation qui suggère que |
|---|---|---|
| Réhéberger (lift-and-shift) | Migration vers le cloud sans modification du code | Faible complexité de l'application, aucun problème de compatibilité, compatible avec l'infrastructure |
| Replateforme | Modifications mineures pour tirer parti des services cloud (par exemple, passer à une base de données gérée) | Couplage modéré, possibilité de mise à niveau de la plateforme, étendue des modifications de code acceptable |
| Refactoriser | Repenser l'architecture pour adopter des modèles natifs du cloud (microservices, conteneurs) | Couplage monolithique élevé, exigences importantes en matière d'évolutivité, justifiées par la croissance prévue du trafic. |
| Réarchitecte | Refonte importante de l'architecture de l'application | Application fondamentalement incompatible avec le cloud ; la nouvelle architecture offre un avantage commercial majeur |
| Reconstruire | Réécrire entièrement | L'application est irréparable d'un point de vue économique ; le remplacement est moins coûteux que la réparation. |
| remplacer | Abandonnez l'application personnalisée et adoptez une alternative SaaS. | L'application offre des fonctionnalités standard mieux prises en charge par un service cloud existant. |
| Prendre ma retraite | Mise hors service, l'application n'est plus nécessaire | Application identifiée comme obsolète, redondante ou remplacée lors de l'évaluation |
L'inventaire de l'infrastructure ne permet pas de distinguer les candidats aux opérations de réhébergement, de replatformage, de refactorisation et de reconstruction, car ils apparaissent tous identiques au niveau de l'infrastructure. Seule l'analyse du code applicatif permet de faire la distinction.
Évaluation de la migration vers le cloud pour les systèmes hérités et les systèmes mainframe
Les outils d'évaluation standard de migration vers le cloud sont conçus pour les infrastructures modernes : machines virtuelles, conteneurs, microservices et applications natives du cloud. Leurs performances sont médiocres, voire nulles, pour les charges de travail mainframe, les programmes COBOL exécutés sur IBM z/OS, les flux de travaux JCL gérant le traitement par lots, les applications PL/I traitant les transactions financières et les programmes RPG embarqués dans les systèmes AS/400.
L'évaluation de la migration des systèmes mainframe vers le cloud exige une approche fondamentalement différente, car la contrainte ne réside pas dans la couche infrastructure. La contrainte, c'est le code applicatif, fruit de décennies de logique métier accumulée, les dépendances implicites liées aux ensembles de données et aux copybooks partagés, ainsi que les comportements d'exécution qu'aucune analyse d'infrastructure ne peut révéler.
Les huit analyses nécessaires à la planification responsable de toute migration mainframe – inventaire des programmes, cartographie des dépendances, extraction de la logique métier, identification du code mort, classification de la complexité, analyse de l'ordonnancement des traitements par lots, évaluation de la qualité des données et cartographie d'intégration – sont décrites en détail dans le cadre de la réduction des risques liés à la migration mainframe . Chacune de ces analyses porte sur le code, et non sur l'infrastructure.
Comparatif des outils d'évaluation de la migration vers le cloud
Le tableau ci-dessous associe les principaux outils d'évaluation de la migration vers le cloud à la dimension d'évaluation qu'ils abordent et au scénario le plus adapté.
| Outil | Couche d'évaluation | cible nuage | Idéal pour |
|---|---|---|---|
| Migration Azure | Infrastructure | Azure | Découverte des machines virtuelles et des serveurs, dimensionnement optimal, estimation des coûts Azure |
| Service de découverte d'applications AWS | Infrastructure | AWS | Découverte des serveurs sur site pour les migrations AWS |
| Centre de migration Google | Infrastructure | GCP | Inventaire des actifs et coût total de possession (TCO) pour les migrations GCP |
| Temps forts du casting | Code d'application | Multi-cloud | Évaluation de la maturité du code à l'échelle du portefeuille pour différentes langues |
| CloudPilot | Code d'application | Multi-cloud | Analyse détaillée de la compatibilité pour Python, JS, Node.js et Go |
| SMART TS XL | Code applicatif + cartographie des dépendances | Multi-cloud | Analyse de portefeuille COBOL, JCL, mainframe et multilingue |
| AWSDMS | Centres de données | AWS | Migration de base de données avec conversion de schéma |
| Service de migration de base de données Azure | Centres de données | Azure | Migration de SQL Server, MySQL et PostgreSQL vers Azure |
| STRIM | Centres de données | Multi-cloud | Réplication en temps réel pour une migration de données sans interruption de service |
| Microsoft Defender pour le cloud | Sécurité | Azure / Multicloud | Évaluation de la posture de sécurité et de la conformité |
| Nuage de prisme | Sécurité | Multi-cloud | CSPM et conformité sur AWS, Azure et GCP |
| Coût des infrastructures | Prix | Multi-cloud | Estimation des coûts intégrée à l'IaC dans les pipelines CI/CD |
| Apptio Cloudabilité | Prix | Multi-cloud | Gestion des coûts FinOps et du cloud en continu |
| Corent SurPaaS | Infrastructure + application | Multi-cloud | Découverte, évaluation et orchestration de la migration pilotées par l'IA |
Comment SMART TS XL Effectue une évaluation du code applicatif en vue de la migration vers le cloud.
SMART TS XL Il aborde la couche d'évaluation du code applicatif que les outils d'infrastructure ne peuvent pas atteindre, en particulier pour les environnements d'entreprise et les environnements existants où le portefeuille d'applications couvre plusieurs langages, plateformes et générations technologiques.
Pour un programme de migration qui inclut des programmes COBOL, des flux de travaux JCL, des services Java, des pipelines Python et des schémas SQL, SMART TS XL construit un modèle de dépendance unifié pour l'ensemble d'entre eux simultanément. Avant que l'équipe de migration ne décide quoi réhéberger, quoi refactoriser et quoi mettre hors service, SMART TS XL fournit:
Inventaire complet des programmes : Chaque programme source, copybook, procédure et schéma dans chaque langage de l’environnement, l’inventaire réel, et non l’inventaire documenté, qui dans les environnements existants diverge généralement de 20 à 30 %.
Cartographie des dépendances interlangages : La fonctionnalité de cartographie des dépendances d’une application permet de suivre la manière dont un programme COBOL se connecte à un schéma DB2 interrogé par un service Java, lequel alimente un pipeline Python produisant un résultat utilisé par une interface React moderne. Cette chaîne de dépendances interlangages détermine l’ordre de migration ; les composants ayant de nombreuses dépendances doivent migrer une fois que leurs propres dépendances sont prêtes.
Identification du code mort : les programmes et procédures qui ne sont jamais appelés par aucun chemin d’exécution en production peuvent être entièrement exclus du périmètre de migration. Dans les grands environnements existants, cela représente généralement 10 à 25 % du total, ce qui représente une réduction de coût significative dès la phase d’évaluation.
Classification de la complexité : L’ analyse statique du code classe chaque programme selon sa complexité cyclomatique, le nombre de dépendances au copybook, le nombre d’appels et d’autres indicateurs permettant de déterminer la difficulté de migration. Les programmes complexes comportant de nombreux appels sont candidats à une refactorisation ou à une reconstruction. Les programmes peu complexes et comportant peu de dépendances sont candidats à une réinstallation.
Analyse d'impact avant toute modification : La fonction d'analyse d'impact répond à la question « Qu'est-ce qui sera affecté si ce programme change ? » avant toute activité de migration, transformant ainsi un risque inconnu en un périmètre structuré et énuméré.
Pour les organisations qui planifient des programmes de migration du mainframe vers le cloud, SMART TS XL's modernisation de l'héritage L'analyse produit l'évaluation préalable à la migration dont les fournisseurs de migration ont besoin avant le début des travaux de conversion : inventaire structurel complet, graphe de dépendance, classification de la complexité et rapport d'exclusion du code mort.
Ce que devrait produire une évaluation complète de la migration vers le cloud
Une évaluation n'a de valeur que si elle permet de prendre des décisions. Une évaluation complète de la migration vers le cloud doit produire cinq livrables qui, ensemble, définissent le programme de migration :
Inventaire du portefeuille d'applications avec attribution de stratégie de migration : Chaque application concernée est classée comme étant réhébergée, replatformée, refactorisée, réarchitecturée, reconstruite, remplacée ou mise hors service, avec les preuves d'évaluation qui soutiennent chaque classification.
Plan de migration par vagues basé sur les dépendances : séquence de migration des applications, établie à partir du graphe de dépendances et non de regroupements arbitraires. Les applications sans dépendances entrantes provenant d’autres applications concernées peuvent migrer lors des premières vagues. Les applications dont dépendent de nombreuses autres applications migrent ultérieurement, une fois que leurs dépendances sont prêtes.
Estimation du coût total de la migration : efforts d’ingénierie, coûts des outils de migration, coûts d’exécution en parallèle temporaire et coûts de formation, et non seulement les différences de coûts d’infrastructure.
Modèle de coût total de possession (TCO) post-migration : Dépenses cloud projetées basées sur des configurations adaptées et des données d’utilisation réelles, comparées aux coûts opérationnels actuels sur site, avec des hypothèses réalistes concernant les changements de licences et les transitions du modèle opérationnel.
Registre des risques : Les risques identifiés, les blocages de compatibilité, les migrations de données complexes, les dépendances non documentées, les contraintes de conformité, avec leur probabilité, leur impact et les mesures d'atténuation proposées pour chacun.
Les organisations qui produisent ces cinq livrables avant le début de la migration disposent des informations nécessaires à la réussite du programme. Celles qui négligent l'évaluation du code applicatif, des données ou de la sécurité produisent des versions incomplètes de ces livrables et découvrent les éléments manquants pendant la migration, ce qui engendre des coûts supplémentaires pour leur correction.
