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.
Migration Azure Cette solution est la norme pour les organisations migrant vers Azure. Elle effectue une découverte sans agent des environnements VMware vSphere, Hyper-V et 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 d'une seule charge de travail.
Service de migration d'applications AWS (MGN) et Service de découverte d'applications AWS Ce service remplit une fonction équivalente 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.
Centre de migration Google Il 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 :
Bloqueurs de compatibilitéLes API, frameworks ou fonctionnalités d'exécution qui n'existent pas ou qui se comportent différemment dans l'environnement cloud cible peuvent poser problème. 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 aux fichiers spécifique à Windows ne peut pas s'exécuter sur une instance cloud Linux sans modification.
Hypothèses d'infrastructure codées en durLes adresses IP, les chemins d'accès au système de fichiers, les noms de serveurs ou les numéros de port intégrés au code ne seront plus valides dans l'environnement 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 de l'application et non dans la configuration de l'infrastructure.
Utilisation de l'API obsolèteLes appels à des API, des bibliothèques ou des fonctionnalités de la plateforme non prises en charge par l'environnement cloud cible ou obsolètes peuvent poser problème. Les fournisseurs de plateformes cloud déprécient régulièrement les anciennes versions d'API ; par conséquent, les applications qui les utilisent ne fonctionneront plus sur la nouvelle plateforme, même si elles fonctionnent correctement actuellement.
Complexité des dépendancesLa 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.
Temps forts du casting Cet outil effectue 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 se spécialise dans l'évaluation détaillée de la préparation au cloud avec un système de notation de compatibilité et la génération d'une feuille de route de migration pour JavaScript, Python, Node.js et Go.
Modernisation de l'application GitHub Copilot 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ébitQuelle est la quantité de données existantes ? Quel est leur taux d’évolution ? Peut-on les migrer sans interruption de service, ou faut-il recourir à une réplication continue pour obtenir une transition quasi instantanée ?
Compatibilité des schémasLe 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éesOù les données doivent-elles légalement résider ? Le RGPD, la loi HIPAA, la norme PCI-DSS et les réglementations sectorielles peuvent limiter les régions cloud autorisées à héberger certaines catégories de données.
Couplage d'applicationDans quelle mesure le code de l'application est-il lié 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.
Service de migration de base de données AWS et Service de migration de base de données Azure prise en charge de 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).
STRIM et Attitude assurer 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 d'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 la gestion des identités et des accès (IAM) actuelle et celle requise représente un effort de migration indépendant de l'inventaire de l'infrastructure.
ChiffrementLes exigences en matière 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é InternetLes 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 du cadre de conformitéChaque secteur réglementé possède des exigences de conformité spécifiques qui correspondent à des configurations cloud particulières. Les charges de travail HIPAA nécessitent des choix de configuration spécifiques en matière de stockage, de journalisation des accès et de 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 pour le 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.
Nuage de prisme (Palo Alto Networks) et Centre de sécurité AWS fournir une évaluation de sécurité multicloud équivalente et un suivi de la conformité.
É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 cloudLes coûts de calcul, de stockage, de réseau et de services gérés dans la configuration cloud cible sont pris en compte. 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.
Les coûts des efforts de migrationLes 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 sont systématiquement sous-estimées par les évaluations portant uniquement sur l'infrastructure, car elles ne tiennent pas compte de la complexité de l'application.
Modifications des licencesPasser 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.
Changements du modèle opérationnelLes équipes d'exploitation sur site, chargées de la gestion du matériel physique, sont remplacées par des équipes d'exploitation cloud qui gèrent les services cloud. Les compétences, les outils et les effectifs évoluent.
coûts de formation et de transitionLes é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.
AWS Pricing Calculator, Calculateur de coût total de possession (TCO) Azure et Calculateur de prix Google Cloud aborder la question du coût de l'infrastructure cloud. Coût des infrastructures fournit une estimation des coûts intégrée aux pipelines IaC, produisant des estimations de coûts dans le cadre du processus CI/CD. Apptio Cloudabilité et des outils FinOps similaires permettent 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 avant toute planification responsable d'une 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 la planification des traitements par lots, évaluation de la qualité des données et cartographie d'intégration – sont décrites en détail dans le contexte de réduction des risques liés à la migration vers un mainframeChacune de ces activités est une évaluation au niveau du code, et non une évaluation de 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 du programme: 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 interlangues: Les cartographie des dépendances des applications Cette fonctionnalité permet de suivre la connexion d'un programme COBOL à 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 des migrations : les composants ayant de nombreuses dépendances doivent migrer une fois que leurs dépendances sont prêtes.
Identification des codes mortsLes programmes et procédures qui ne sont jamais exécutés en production peuvent être totalement exclus du périmètre de migration. Dans les grands environnements existants, cela représente généralement 10 à 25 % du parc informatique total, ce qui permet de réaliser des économies substantielles dès la phase d'évaluation.
Classification de la complexité: Les analyse de code statique L'outil de classification des programmes évalue leur complexité cyclomatique, le nombre de dépendances au copybook, le nombre d'appels et d'autres indicateurs déterminant la difficulté de migration. Les programmes complexes comportant de nombreux appelants sont candidats à une refactorisation ou une reconstruction. Les programmes peu complexes et peu dépendants sont candidats à un réhébergement.
Analyse d'impact avant toute modification: Les analyse d’impact Les capacités permettent de répondre à 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 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épendancesL'ordre de migration des applications est déterminé par le graphe de dépendances et non par des regroupements arbitraires. Les applications sans dépendances entrantes provenant d'autres applications concernées peuvent migrer en premier. 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 pas seulement les différences de coûts d'infrastructure.
Modèle de coût total de possession (TCO) post-migration: Prévisions des dépenses cloud 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 obstacles à la 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.
