Ce qu’il faut évaluer avant de migrer une application

La migration vers le cloud commence par la décision de savoir si le passage crée de la valeur

Une application peut arriver dans le cloud dans les délais, réussir ses tests de bascule, et pourtant laisser l’entreprise avec des coûts plus élevés et les mêmes contraintes architecturales. Le rapport 2024 Accelerate State of DevOps de DORA a constaté qu’un passage au cloud sans adoption de sa flexibilité intrinsèque peut produire de moins bons résultats qu’un maintien on-prem. Ce constat place la première décision de migration avant l’infrastructure : les équipes doivent décider si une application doit être déplacée, dans quelle mesure elle doit évoluer, et quelle architecture cible peut produire le résultat métier attendu.

Le rehosting, ou lift-and-shift, concrétise cette décision parce que l’application est déplacée en restant largement inchangée. Il réduit l’effort et le risque de migration et permet de faire entrer rapidement une application dans le cloud, mais sa valeur d’optimisation à long terme est faible, car la dette architecturale est déplacée avec elle et les ressources de calcul peuvent mal correspondre à la tarification du cloud. Le right-sizing, les reserved instances, l’auto-scaling et les services managés peuvent corriger les régressions de coût et de performance ; ainsi, même un déplacement relativement simple exige une revue d’architecture plutôt que de traiter le cloud comme un simple nouvel emplacement pour le système existant.

Cette revue d’architecture doit relier le déplacement à des résultats tels qu’une meilleure scalabilité, une fiabilité accrue et un coût réduit à l’échelle. Une migration techniquement propre ne peut pas établir que ces résultats sont plausibles lorsque l’architecture existante ou les capacités de l’équipe jouent contre eux. La planification de la migration commence donc en amont du choix de l’infrastructure, avec des éléments factuels sur ce que fait réellement l’application et une décision sur le bien-fondé de son déplacement.

Découvrir le système dont vous disposez réellement avant de choisir sa destination

Les éléments factuels nécessaires à cette décision commencent en production, car les schémas et les wikis peuvent décrire un système qui n’existe plus. Techstack, un prestataire de conseil en migration qui bénéficie commercialement lorsque les organisations achètent des services de migration, utilise une évaluation axée d’abord sur la découverte, dans laquelle des outils automatisés inventorient les services en cours d’exécution, les API, les flux de données et les points d’intégration, tandis que son équipe consigne les dépendances entre services, les bases de données partagées et d’autres points de contact d’intégration. À partir de ce travail, Techstack produit une cartographie des dépendances et un inventaire des applications hiérarchisé par niveau de risque, donnant aux parties prenantes métiers et techniques un modèle de l’état actuel qu’elles peuvent examiner avant que les choix de migration ne deviennent des engagements.

Ce modèle de l’état actuel doit aussi inclure suffisamment de données de séries temporelles pour révéler des charges de travail qu’une courte fenêtre d’observation pourrait masquer. Les équipes devraient collecter au moins 30 jours de données d’utilisation avant de prendre la décision de migration, ce qui peut faire apparaître les traitements batch, les travaux de fin de mois et des schémas de trafic moins fréquents. La latence, les taux d’erreur et le débit doivent être établis comme références sur cette période afin que les conceptions cibles et les résultats de migration ultérieurs puissent être comparés au comportement observé en production.

Le risque de s’appuyer uniquement sur les documents est clair pour un vice-président de l’ingénierie dans une entreprise de 500 personnes responsable d’un système de gestion des commandes vieux de 12 ans. Les ingénieurs qui l’ont construit à l’origine sont partis, son wiki n’est plus à jour, et trois traitements batch nocturnes non documentés envoient des données à la finance. Une migration fondée sur ce wiki peut sembler complète jusqu’à ce qu’une bascule interrompe ces traitements, transformant une lacune documentaire en incident opérationnel avec des conséquences au-delà de l’équipe applicative.

Parce que les lacunes de documentation peuvent devenir des défaillances opérationnelles, elles doivent figurer dans la phase de découverte comme des facteurs de risque explicites. La découverte automatisée à l’exécution peut faire apparaître des dépendances que les documents statiques n’ont pas relevées, tandis qu’un registre vivant des dépendances consigne ce que l’équipe apprend et ce qui change à mesure que les vagues de migration révèlent davantage de relations. Les workflows non documentés et le shadow IT, c’est-à-dire les technologies utilisées en dehors de la responsabilité ou des registres formels de l’IT, doivent également figurer dans l’inventaire des risques, car le comportement en production établit ce qui doit être préservé, quel que soit son statut documentaire.

Ces dépendances à l’exécution comptent particulièrement autour des bases de données partagées. Deux applications peuvent sembler indépendantes au niveau des services tout en lisant et écrivant dans la même base de données, ce qui couple leur comportement lorsque l’une d’elles est déplacée indépendamment. Techstack classe comme très complexe toute application partageant une base de données avec un autre candidat à la migration, et le prestataire de conseil affirme que son expérience de migration identifie les bases de données partagées comme une raison fréquente d’échec des calendriers.

La cartographie technique doit aussi inclure des éléments sur la responsabilité, car les dépendances seules ne permettent pas d’établir l’importance métier ni le niveau de risque acceptable. Un service dont la responsabilité n’est pas claire ou un workflow dont le sponsor métier ne peut pas être identifié crée un problème de décision, car personne ne peut établir de manière fiable son importance, son indisponibilité acceptable ou les conditions de son retrait. À la fin de la phase de découverte, l’équipe devrait disposer d’une cartographie des dépendances revue par les parties prenantes, de 30 jours ou plus de données d’utilisation, des résultats de l’inventaire automatisé, des références de performance actuelles et d’incertitudes explicitement identifiées, transformant un comportement de production inconnu en risques pouvant être classés et gérés.

La première décision de migration est de savoir s’il faut migrer tout court

Une fois le système actuel rendu visible, chaque application peut être évaluée selon quatre dimensions : criticité métier, dette technique, complexité de migration et adéquation au cloud-native. Les parties prenantes métiers et techniques valident ensuite ensemble l’évaluation, tandis qu’une responsabilité floue ou un sponsoring manquant sont remontés au lieu d’être discrètement reportés dans l’exécution. Les bases de données partagées restent des facteurs de complexité explicites, car une classification fondée uniquement sur le code applicatif peut sous-estimer fortement le travail à fournir.

Ces dimensions deviennent actionnables grâce au framework des 6 R, qui attribue à chaque application un traitement de migration au lieu de supposer que toutes les applications ont besoin du même parcours vers le cloud. Les niveaux d’effort, de risque et d’optimisation à long terme ci-dessous expriment les arbitrages pratiques utilisés dans cette classification.

La classification compte lorsqu’elle modifie le travail réalisé par l’ingénierie. Une application stable, de faible valeur métier, dont le retrait est prévu dans les 18 mois, est candidate à Retain ou Retire, tandis qu’une application cœur confrontée à une demande croissante peut justifier le risque et l’effort de Refactor ou Re-architect. Lorsque le temps compte et que la dette architecturale reste gérable, Replatform peut capter des bénéfices cloud significatifs sans engager l’équipe dans une reconstruction complète.

Repurchase répond aux charges de travail dont la fonctionnalité standard ne justifie pas de continuer à posséder une implémentation sur mesure. Déplacer une telle charge de travail vers du SaaS peut supprimer la nécessité de migrer et d’exploiter sa stack applicative existante, même si le remplacement exige toujours une planification délibérée de la migration des données. Retire pousse cette réduction plus loin en supprimant entièrement une charge de travail inutile, de sorte que l’inventaire devient une opportunité de réduire le parc au lieu de tout le reproduire dans le cloud.

Ces classifications techniques ont besoin d’un test financier, car l’économie peut invalider une stratégie techniquement simple. Le coût total de possession, ou TCO, doit entrer dans la décision d’architecture avant le provisioning. Si le TCO d’un lift-and-shift dépasse le coût on-prem actuel et qu’un refactoring ne peut pas créer suffisamment de valeur, préserver l’environnement actuel peut être la décision la plus judicieuse.

La même évaluation doit tenir compte des capacités de l’organisation et des exigences de conformité. La migration peut être inappropriée lorsque les compétences requises ne sont pas disponibles et qu’il n’existe pas de budget pour un support externe, ou lorsque les exigences de conformité du cloud ajoutent de la complexité sans bénéfice métier proportionné. Une application appelée à disparaître dans les 18 mois est un autre cas clair où le travail de migration peut consommer des ressources qui seront bientôt abandonnées.

Ensemble, ces tests font de la conservation, du retrait, du remplacement par du SaaS et de la modernisation incrémentale des résultats délibérés lorsque les éléments factuels les justifient. Cet éventail est particulièrement important pour les systèmes legacy qui absorberaient autrement un effort de migration disproportionné. Les applications qui réussissent l’évaluation technique, métier, de capacité et de TCO peuvent alors passer à la conception de l’architecture cible.

Ne modernisez que dans la mesure que l’application et l’équipe peuvent réellement supporter

Pour les applications qui avancent, la conception de l’architecture précède le provisioning de l’infrastructure, car la stratégie de migration détermine ce qui doit être construit. Un rehost exige une cartographie délibérée des ressources de calcul, de stockage et de réseau existantes vers leurs équivalents cloud, y compris la documentation des différences. Le replatforming et le refactoring exigent un état cible explicite, car le degré de modernisation détermine le travail de réseau, de déplacement des données, de déploiement et d’exploitation qui suit.

AWS, qui bénéficie commercialement lorsque les clients adoptent ses services cloud, fournit plusieurs exemples conditionnels de ces choix cibles. ECS sur Fargate peut constituer un point de départ pour les charges de travail de type requête/réponse, tandis qu’AWS Lambda convient aux gestionnaires d’événements et qu’EKS convient aux cas où Kubernetes est réellement nécessaire. Ces choix découlent des exigences de la charge de travail, car adopter EKS simplement parce qu’il est disponible ajoute des opérations Kubernetes même lorsque l’application n’a aucune exigence qui le justifie.

La même discipline fondée sur les exigences s’applique aux monolithes legacy, où le modèle de décomposition doit être choisi avant l’écriture du code d’infrastructure. Une approche strangler fig place une façade ou un proxy devant le monolithe existant et envoie les fonctions nouvellement construites ou refactorées vers des services séparés, tandis que les fonctions plus anciennes continuent de s’exécuter en place. À mesure que davantage de fonctions sont déplacées, le monolithe devient progressivement plus petit, ce qui permet à la modernisation d’avancer sans une réécriture complète en une seule fois.

Lorsqu’un proxy réseau n’est pas pratique, branch by abstraction déplace la transition à l’intérieur de la base de code existante. Les ingénieurs introduisent une abstraction dans cette base de code, construisent le nouveau comportement derrière elle, basculent l’usage vers la nouvelle implémentation au niveau du code, puis suppriment finalement l’implémentation obsolète. AWS Migration Hub Refactor Spaces peut prendre en charge ce modèle, un lien cité par le blog AWS .NET Modernization en 2023 ; AWS a un intérêt commercial dans l’adoption de ce service.

Quel que soit le modèle de décomposition utilisé, modifier les frontières du code ne sépare pas à lui seul la responsabilité des données. Un monolithe scindé en plusieurs services reste fortement couplé si ces services lisent et écrivent toujours dans les mêmes tables, et la séparation d’une base de données partagée peut prendre des mois. Scinder les schémas avant de décider des bonnes frontières de domaine peut rendre l’intégration plus difficile ; la décomposition des données a donc besoin de son propre plan incrémental.

Ce plan incrémental peut commencer par du domain-driven design ou de l’event storming avec des experts métier afin d’identifier des bounded contexts, c’est-à-dire des zones du modèle métier avec des frontières conceptuelles et de responsabilité claires. Les read replicas peuvent réduire la charge sur la base de données primaire, tandis que le change data capture, ou CDC, enregistre les changements incrémentaux de la base de données et diffuse les journaux de changements vers Kafka. Une anti-corruption layer traduit ensuite ces changements de base de données en événements de domaine afin que l’ancienne représentation de la base de données ne détermine pas les interfaces des domaines émergents.

Une fois ces frontières établies, la responsabilité des schémas peut évoluer progressivement. Chaque service peut obtenir son propre schéma, un bounded context à la fois, tandis que le CDC maintient synchronisés les anciens et les nouveaux chemins de données pendant la transition ; AWS DMS est un exemple d’outil de réplication continue et constitue un autre service AWS dont l’entreprise bénéficie lorsque les clients l’adoptent. Comme une séparation complète peut nécessiter des mois, le travail peut se poursuivre en parallèle des premières vagues de migration au lieu de retarder tout déplacement jusqu’à ce que la base de données ait été entièrement réorganisée.

L’architecture cible doit aussi correspondre à l’équipe qui l’exploitera. Un monolithe modulaire préserve des frontières de domaine explicites au sein d’une seule application déployable et évite une grande partie de la complexité opérationnelle introduite par les services distribués. Lorsque les ingénieurs manquent d’expérience des systèmes distribués, ou que l’échelle de la charge de travail ne justifie pas des microservices, cette structure peut constituer une cible durable.

Une application stable peut aussi gagner de nouveaux comportements à ses frontières plutôt que par une décomposition interne. Dans le modèle de menu 9-dots de Techstack, plusieurs monolithes legacy ont été connectés via une couche d’intégration afin de pouvoir fonctionner comme un produit unifié sans réécrire chaque système. Techstack affirme que les monolithes individuels sont restés stables tandis que l’expérience utilisateur est devenue cohérente, un exemple que le cabinet de conseil en migration utilise pour montrer comment la modernisation peut se produire aux frontières du système lorsque la réécriture d’applications matures ajouterait un risque inutile.

Des caractéristiques de charge de travail différentes peuvent justifier une architecture cible très différente. L’exemple de plateforme de levée de fonds de Techstack impliquait des pics de trafic imprévisibles et un débit élevé ; l’entreprise a donc construit une architecture serverless sur AWS Lambda capable de monter en charge avec la demande. Techstack présente également cette conception comme favorable à une montée en charge fiable et à des déploiements à faible indisponibilité, des affirmations qui soutiennent le type de travaux de migration et de modernisation qu’elle vend ; pour les équipes d’ingénierie, la question est de savoir si le trafic, l’architecture et la capacité opérationnelle présentent la même adéquation.

Cette adéquation inclut aussi la sécurité, la conformité et les opérations, car chacune peut modifier l’architecture cible. Les exigences de sécurité et de conformité doivent être documentées avant la migration, car les ajouter plus tard crée du retravail et un risque d’audit, tandis que la journalisation, le tracing et l’alerting doivent être définis comme des parties de l’architecture cible. Concevoir ces exigences avant le provisioning permet de maintenir les choix d’infrastructure subordonnés au modèle opérationnel dont l’application a réellement besoin.

Exécuter la migration comme une série d’expériences réversibles

Une fois la cible justifiée et conçue, l’exécution peut tester ces choix de conception avec deux ou trois applications non critiques et à faibles dépendances. Un projet pilote expose la manière dont l’environnement cible se comporte avec les propres pratiques de l’organisation en matière de réseau, de sécurité, de déploiement et d’exploitation, et l’équipe devrait examiner le projet pilote de manière rétrospective avant le début de vagues plus larges. La méthodologie par vagues de Techstack utilise cette progression pour transformer l’inventaire en feuille de route par phases avec séquence, responsables et critères go/no-go explicites, reflétant l’approche de migration que vend le cabinet de conseil.

À mesure que le projet pilote s’étend en vagues, les décisions transverses aux vagues ont besoin d’un responsable désigné afin que des équipes distinctes ne créent pas de modèles incompatibles. Un architecte de migration est responsable de la cohérence des décisions d’architecture, des conventions de nommage, des modèles réseau et des contrôles de sécurité à mesure que les applications sont déplacées. Les écarts de capacité doivent également être identifiés pendant la planification, avec un support externe à la migration envisagé pour les une ou deux premières vagues lorsque les équipes internes ont besoin d’expérience pratique aux côtés de praticiens expérimentés.

Cette responsabilité doit s’étendre à des accords opérationnels mesurables avant que quiconque ne planifie la bascule. Les références de latence, de taux d’erreur et de débit fournissent des points de comparaison et peuvent devenir des déclencheurs de rollback, tandis que l’indisponibilité acceptable, les chemins d’escalade et les seuils de rollback doivent être consignés par écrit. Un incident à 2 heures du matin est le mauvais moment pour que les parties prenantes découvrent que « Nous verrons quoi faire si quelque chose tourne mal » constituait l’accord réel.

Une fois les conditions de rollback convenues, le déplacement des données peut commencer avant la fenêtre de bascule. L’équipe doit confirmer que l’environnement source correspond toujours à la cartographie des dépendances, démarrer une réplication continue via AWS DMS ou un mécanisme équivalent, et valider la réplication chaque jour ; AWS bénéficie commercialement lorsque son service DMS est sélectionné. Après le déploiement vers la cible, les tests fonctionnels, de performance, de sécurité et les smoke tests, qui sont des vérifications rapides du bon fonctionnement des fonctions essentielles, doivent être réussis avant que le trafic de production ne commence à être déplacé.

La réussite de ces vérifications permet d’augmenter progressivement l’exposition du trafic pendant une période de faible trafic, de 10 % à 50 % puis à 100 %. DNS, les règles d’Application Load Balancer et API Gateway peuvent contrôler le routage ; le routage pondéré d’ALB et les déploiements canary d’API Gateway, qui exposent d’abord une nouvelle version à une part limitée du trafic, prennent en charge ces bascules progressives. Il s’agit de services AWS, donc AWS bénéficie de leur adoption. La bascule DNS ou load balancer doit d’abord être testée en staging afin que la production utilise un mécanisme de routage que l’équipe a déjà vérifié.

Le déplacement progressif du trafic est utile parce que le rollback reste exécutable pendant la validation du nouvel environnement. L’environnement on-prem doit rester actif pendant une à deux semaines comme cible de rollback, avec des déclencheurs explicites tels que des seuils de taux d’erreur, des pourcentages de dégradation de latence ou des signaux d’incohérence des données. Maintenir l’ancien environnement disponible consomme des ressources pendant une période limitée, mais cela donne à l’équipe une réponse préparée lorsque le comportement mesuré franchit ces seuils.

Ces contrôles donnent à chaque vague des conditions d’achèvement concrètes sans transformer la bascule en un événement unique et irréversible. La réplication est vérifiée quotidiennement avant le déplacement du trafic, les tests requis établissent la préparation de la cible, et l’ancien environnement reste disponible ensuite pendant la période de rollback convenue. La vague suivante peut alors hériter de ce que les migrations précédentes ont établi, tandis que l’architecte de migration maintient la cohérence des modèles qui en résultent dans l’ensemble du programme.

Une bascule n’est pas la ligne d’arrivée

Une fois le trafic de production déplacé, le comportement réel teste si l’architecture cible a produit ce que sa conception prévoyait. Les équipes doivent comparer la latence, les erreurs et le débit à leurs références pré-migration et examiner immédiatement les régressions. Les éléments factuels recueillis avant la migration fournissent désormais la référence permettant de déterminer si la scalabilité et la fiabilité se sont réellement améliorées sous une demande réelle.

La validation opérationnelle alimente ensuite un contrôle financier plus long. Les dépenses cloud doivent être comparées aux projections de TCO à 30 et 90 jours, et les ressources de calcul doivent être ajustées à partir de l’usage observé plutôt que d’hypothèses formulées avant la migration. Les ressources on-prem restent disponibles pendant toute la période de validation prolongée et ne sont décommissionnées qu’une fois cette période écoulée sans déclenchement des conditions de rollback.

Chaque vague achevée modifie également ce que l’organisation sait du parc restant, de sorte que la rétrospective devient une entrée pour la migration suivante plutôt qu’un compte rendu de la précédente. L’équipe doit documenter ce qui a cassé, ce qui a ralenti l’exécution et quels manques d’outillage sont apparus, puis traiter ces constats avant le début de la vague suivante et ajuster sa séquence à partir des enseignements tirés. Le registre des dépendances peut continuer d’évoluer à mesure que la production révèle des relations que la phase de découverte précédente n’avait pas détectées.

Principaux enseignements pour les dirigeants

• Commencez par la valeur métier : Les responsables applicatifs doivent tester les choix de migration au regard de la scalabilité, de la fiabilité, du coût et des contraintes architecturales avant d’engager des ressources. Une bascule réussie crée une valeur limitée lorsque la cible préserve les mêmes contraintes à un coût plus élevé.
• Cartographiez le système de production : Les équipes d’ingénierie doivent construire une cartographie des dépendances revue par les parties prenantes à partir de la découverte à l’exécution et d’au moins 30 jours de données d’utilisation et de performance. Les bases de données partagées, les workflows non documentés, le shadow IT et les responsabilités floues doivent figurer dans l’évaluation des risques.
• Décidez si chaque application doit migrer : Les responsables technologiques et métiers doivent évaluer la criticité métier, la dette technique, la complexité de migration, l’adéquation au cloud, le TCO, la conformité et les compétences disponibles. Rehost, replatform, refactor, repurchase, retire et retain doivent rester des résultats valides.
• Adaptez la modernisation à la capacité d’exploitation : Les équipes d’architecture doivent sélectionner les modèles cibles en fonction des exigences de la charge de travail et de la capacité de l’organisation à les exploiter. Une décomposition incrémentale, une responsabilité explicite des données ou un monolithe modulaire peuvent offrir de meilleurs profils de risque et de valeur qu’une modernisation globale.
• Rendez la migration réversible : Les responsables de migration doivent commencer par des projets pilotes à faible risque, déplacer les applications par vagues, répliquer les données en continu et définir des déclencheurs de rollback mesurables avant la bascule. Des bascules progressives du trafic et un environnement source temporairement maintenu en production limitent l’impact des régressions en production.
• Mesurez la valeur après la bascule : Les équipes d’ingénierie et de finance doivent comparer les performances de production aux références pré-migration et les dépenses cloud aux projections de TCO à 30 et 90 jours. Les constats opérationnels de chaque vague doivent mettre à jour les enregistrements de dépendances, les modèles d’architecture et les plans des migrations suivantes.