Migrer vos applications dans le cloud : 7 stratégies à connaître

La migration des applications vers le cloud est une étape cruciale pour les entreprises qui cherchent à moderniser leurs infrastructures et à tirer parti des avantages du cloud, tels que la scalabilité, la flexibilité et l'agilité.

Migrer vos applications dans le cloud : 7 stratégies à connaître

Le déplacement d'une machine virtuelle de votre centre de données vers le cloud ne vous permettra pas de bénéficier de tous les avantages du cloud.

La transition vers le cloud demande plus de réflexion et de prendre en considération un grand nombre de paramètres.

Lors de toute migration applicative vers le cloud, il est donc important de mettre en place une approche structurée, dont font partie les "7 R", pour guider cette transition.

Ces stratégies sont adaptées en fonction des objectifs de l'entreprise et du niveau de transformation technologique souhaité sans oublier les compétences du personnel informatique, les investissements existants et l'architecture des applications.

Dans cet article, nous explorerons ces 7 stratégies et leur impact sur la migration des applications vers un cloud comme Amazon Web Services (AWS) par exemple.

Le modèle des 5R de Gartner

Le concept d'utilisation des modèles "R" dans les stratégies de migration vers le cloud est apparu chez Gartner en 2010, lorsqu'ils ont introduit la stratégie de migration des "5R".

Ces approches ont fourni un cadre aux organisations pour classer leurs applications en fonction de leur adéquation à la migration vers le cloud.

Gartner les a identifiées ainsi : Rehost (lift-and-shift), Refactor (re-architect), Revise (re-platform), Rebuild (re-develop), Replace (drop and shop)

Le modèle des 7R d'AWS

Reconnaissant la nécessité d'un cadre de migration plus complet, AWS a étendu le modèle des 5 R de Gartner en ajoutant le sixième R "Retire", puis plus tard le septième R avec "Retain".

Cette dernière itération reconnaît que toutes les applications et les données ne peuvent ou ne doivent pas être déplacées vers le cloud.

En incluant la possibilité de conserver les charges de travail sur site, le modèle des 7 R offre aux organisations une flexibilité encore plus grande dans leur planification de la migration.

Cela permet aux entreprises d'équilibrer les avantages du cloud computing avec la nécessité de garder le contrôle sur les systèmes critiques et de se conformer aux exigences réglementaires auxquelles elles sont soumises.

Les 7 stratégies "R" pour migrer les charges de travail vers AWS

"Retire" - Décommissionner

"Retire" consiste à simplement arrêter l’utilisation d’une application obsolète, soit en la supprimant, soit en la remplaçant par une solution plus moderne.

C'est l'option à envisager lorsque l’application n’est plus utilisée, plus prise en charge par le fournisseur, plus utile en production et/ou lorsque les tracas et les dépenses liés sa migration vers le cloud n’apportent aucune valeur ajoutée.

Il ne faut pas oublier que cette stratégie peut-être finalement la première étape vers l'adoption de déploiements cloud natifs modernes (Replatforming).

Avantages :

  • Réduction des coûts opérationnels : en retirant des applications ou des systèmes obsolètes, une entreprise peut réduire les coûts liés à la gestion, à l'entretien et à l'infrastructure vieillissante.
    Cela permet d'économiser sur les dépenses en matériel, en personnel, en licences logicielles et en maintenance.
  • Consolidation des ressources : en éliminant les applications ou systèmes redondants, les entreprises peuvent mieux concentrer leurs ressources sur les solutions cloud modernes et évolutives.
    Cela permet de rationaliser les opérations et de simplifier la gestion de l'infrastructure.
  • Amélioration de la sécurité : l'arrêt des systèmes obsolètes réduit les vulnérabilités et les risques de sécurité associés aux anciennes technologies.
    Ces systèmes peuvent ne pas être supportés ou ne plus recevoir de mises à jour de sécurité, augmentant ainsi le risque de cyberattaques.
  • Simplification de l'architecture IT : le retrait des systèmes ou applications obsolètes permet de simplifier l'architecture informatique en éliminant les composants inutiles.
    Cela peut conduire à une meilleure gestion et à une infrastructure plus cohérente et moins complexe.

Inconvénients :

  • Risque de perte de données ou de fonctionnalités : si le processus de retrait n'est pas bien planifié, il y a un risque de perte de données importantes ou de fonctionnalités critiques pour l'entreprise.
    Certaines applications peuvent avoir des dépendances cachées, et leur retrait peut entraîner des dysfonctionnements dans d'autres systèmes.
  • Perturbations des opérations : le retrait d’un système ou d’une application peut entraîner des perturbations temporaires des opérations de l'entreprise, en particulier si les équipes ne sont pas prêtes à gérer le changement ou si des problèmes surviennent lors de la migration des données ou de la transition vers une nouvelle solution.
  • Défis liés à la gestion du changement : le retrait de technologies existantes nécessite souvent un changement dans les processus métiers et dans la manière dont les équipes travaillent.
    Il peut y avoir des résistances internes au changement, en particulier si des employés sont habitués à l'ancienne infrastructure ou si des processus critiques dépendent de systèmes qui seront retirés.

"Retain" - Laisser tel quel

"Retain" consiste à laisser certaines applications sur site, sans les migrer vers le cloud.

Cette option peut être choisie pour des raisons spécifiques, telles que des exigences réglementaires strictes ou des besoins particuliers en matière de sécurité, de latence, de restrictions juridiques ou de confidentialité, de coûts prohibitifs associés à son hébergement dans le cloud ou diverses autres raisons qui empêchent leur migration.

Avantages :

  • Réduction du risque de migration : en conservant certains systèmes ou applications sur site, une entreprise peut réduire le risque lié à la migration en évitant de transférer tous les éléments d'un coup.
    Cela permet de garder un certain contrôle sur les applications critiques ou sensibles pendant que le processus de migration vers le cloud se fait progressivement.
  • Conformité et réglementation : certaines industries, pays ou régions exigent que des données spécifiques soient stockées localement ou sur des infrastructures spécifiques pour des raisons de conformité.
    Le maintien de certains systèmes sur site permet de répondre aux exigences réglementaires tout en migrant d'autres parties vers le cloud.
  • Optimisation des coûts : retenir certaines applications, anciennes ou personnalisées qui ne sont pas facilement compatibles avec le cloud ou qui nécessitent une infrastructure spécialisé, peut être plus économique, surtout si elles fonctionnent de manière efficace sur des infrastructures existantes.
    Le cloud n’est pas toujours LA solution la plus rentable pour toutes les charges de travail, surtout si les coûts d’exploitation dans le cloud sont plus élevés que sur site.

Inconvénients :

  • Complexité accrue de l'architecture : maintenir une partie de l’infrastructure sur site tout en migrant d'autres parties vers le cloud peut rendre l'architecture informatique plus complexe.
    Cela peut entraîner des problèmes de gestion des interconnexions et d'intégration entre les systèmes locaux et cloud.
  • Coûts de gestion double : la gestion simultanée des systèmes sur site et des ressources cloud peut entraîner des coûts opérationnels accrus.
    Les entreprises devront maintenir et surveiller les deux environnements, ce qui peut augmenter les dépenses en termes de ressources humaines, de formation, et de gestion de l'infrastructure.
  • Limitations de la scalabilité : en conservant des systèmes locaux, une entreprise pourrait ne pas tirer pleinement parti de la scalabilité et de la flexibilité du cloud.
    Certaines applications, en particulier celles qui nécessitent des ressources variables ou des mises à jour fréquentes, ne bénéficieront pas des avantages du cloud.
  • Sécurité et risques de gestion multiples : maintenir des systèmes sur site et dans le cloud peut introduire des vulnérabilités, notamment en termes de gestion de la sécurité.
    Gérer des politiques de sécurité différentes pour chaque environnement peut être difficile, augmentant le risque de fuites de données ou de vulnérabilités non corrigées.

"Relocate" - Délocaliser dans le cloud

"Relocate" consiste à migrer des charges de travail vers le cloud sans affecter les opérations en cours, sans réécrire le code source des applications et sans acquérir de nouveau matériel.

Cela implique de déplacer des serveurs d'une plateforme locale (comme Kubernetes ou VMware) vers une version cloud de la même plateforme, par exemple des applications VMware migrées sur Amazon Elastic VMware Service (Amazon EVS).

Avantages

  • Migration rapide et simplifiée : l'un des plus grands avantages de la stratégie Relocate est sa rapidité.
    Étant donné qu’il ne nécessite pas de réécriture du code ou de modification de l'architecture de l’application, les entreprises peuvent déplacer leurs applications et charges de travail vers le cloud relativement rapidement.
    Cela permet une transition fluide sans perturber les opérations en cours.
    Enfin, les risques liés à la perte de données, aux erreurs de configuration ou aux échecs de migration sont réduits par rapport à d'autres stratégies plus compliquées, comme le Re-architecting.
  • Réduction du temps d'arrêt et des interruptions : en utilisant cette approche, les entreprises peuvent minimiser les interruptions de service.
    Les applications restent opérationnelles pendant la migration, ce qui permet aux utilisateurs de continuer à utiliser les services sans subir de coupures importantes.
  • Réduction des coûts de développement et de formation : comme aucune modification majeure des applications n’est nécessaire, il n'y a pas de coûts liés à la réécriture du code ou à la formation des équipes pour utiliser de nouvelles technologies ou architectures.
    Cela permet de réaliser des économies sur les coûts de développement et de formation du personnel.
  • Pas de changements matériels : comme l'approche Relocate ne nécessite pas l'acquisition de nouveaux équipements ou de matériel, elle permet d'éviter les coûts d'achat et de gestion de nouveaux serveurs physiques.

Inconvénients

  • Optimisation limitée des ressources cloud : en transférant les applications sans les adapter à l'architecture du cloud, les entreprises ne tirent pas pleinement parti des fonctionnalités offertes par le cloud, comme la scalabilité automatique, les services managés ou l'optimisation des coûts basée sur l'utilisation.
    Les applications ne sont pas "cloud-friendly" et pourraient être moins performantes ou plus coûteuses à long terme.
  • Coûts opérationnels à long terme plus élevés : bien que ce soit une option rapide et simple, les entreprises pourraient continuer à utiliser des ressources cloud de manière inefficace.
    Par exemple, elles pourraient sous-utiliser les capacités de calcul et de stockage, ce qui entraînerait des coûts inutiles pour des services non optimisés ainsi qu'une gestion plus complexe des ressources, car les applications ne sont pas adaptées aux meilleures pratiques du cloud.
  • Dépendance à l’infrastructure existante : comme les applications sont migrées telles quelles, les limitations et inefficacités de l'infrastructure d'origine peuvent être transférées au cloud.
    Cela signifie que des problèmes de performance ou des contraintes d'architecture sur l'infrastructure locale peuvent persister dans l'environnement cloud.
  • Peu d’innovation cloud : la stratégie Relocate est principalement utilisée pour des migrations rapides, mais elle ne permet pas de profiter des innovations que le cloud peut offrir.
    Les entreprises pourraient manquer des opportunités d'améliorer la performance, l'agilité, et la sécurité de leurs applications en utilisant des services cloud plus avancés.
"Lift and Shift"

Rehosting - Déplacer

"Rehosting", aussi appelé "Lift and Shift", consiste à déplacer une application vers le cloud sans effectuer de modifications majeures.

Cette stratégie de migration, très similaire à Relocate, est aussi une manière rapide et simple de migrer sur le cloud et elle implique de tirer parti des offres d'infrastructure en tant que service (IaaS) proposées par le fournisseur cloud pour redéployer les charges de travail sur une machine virtuelle comme le service Amazon EC2.

C'est une approche idéale pour les entreprises qui ne disposent pas d'une expertise cloud native en interne.

Avantages :

  • Migration rapide et simple : le Rehosting est l'une des stratégies les plus rapides et les plus simples.
    Puisque les applications et les systèmes sont déplacés tels quels, il y a moins de risques d’introduire des erreurs ou des problèmes complexes liés à des modifications dans le code ou l'architecture de l’application.
    Cela permet de migrer rapidement et de réduire la durée de la transition, avec moins de perturbation pour les utilisateurs, les applications continuant de fonctionner de manière similaire après la migration.
  • Réduction des coûts à court terme : cette stratégie permet d'économiser du temps et de l'argent à court terme, car il n’est pas nécessaire de réadapter les applications ou de les reconstruire pour le cloud.
  • Préservation de l'intégrité des applications : comme les applications restent en l’état pendant la migration ("iso-bug"), leur comportement est prévisible et reste cohérent ce qui permet d'identifier les éventuelles erreurs introduites lors de la migration.

Inconvénients :

  • Optimisation limitée des ressources cloud : l'un des principaux inconvénients du Rehosting est que les applications ne sont pas optimisées pour le cloud.
    Elles ne tirent pas parti des fonctionnalités natives du fournisseur cloud, telles que les services managés ou la scalabilité automatique.
    Les applications ne s'adaptent donc pas automatiquement aux pics de demande, ce qui peut rendre leur gestion moins flexible et plus coûteuse.
    De plus, ces applications peuvent finir par entraîner des coûts d’exploitation plus élevés à long terme.
  • Gestion manuelle et maintenance accrue : puisque l’application n’est pas refondue pour tirer parti des services managés, l'entreprise devra souvent gérer l'infrastructure elle-même (par exemple, la gestion des machines virtuelles et des mises à jour logicielles).
    Cela peut entraîner une charge de travail supplémentaire pour les équipes informatiques .
  • Peu d’innovation : cette stratégie ne permet pas d'innover en réarchitecturant l'application pour l'adapter à une infrastructure cloud moderne.
    Les entreprises peuvent passer à côté des avantages de services plus avancés s'appuyant sur les microservices, le serverless, ou l'intelligence artificielle.

Replatforming - Lever, "bricoler" et déplacer

Bien que cette stratégie de migration puisse impliquer un investissement important en temps et en ressources, elle est souvent justifiée par les avantages qu'elle offre.

Le "Replatforming" va donc un peu plus loin que le "Rehosting" car il s'agit de déplacer l'application vers le cloud tout en apportant quelques modifications, offrant aux entreprises la possibilité de sélectionner les composants à moderniser en fonction des dernières tendances technologiques, sans modifier l'architecture ou réécrire complètement l'application.

Par exemple, migrer une base de données locale vers Amazon RDS ou Amazon Aurora.

Le Replatforming est utile lorsqu’une application nécessite quelques ajustements pour mieux fonctionner sur le cloud, mais où une refonte complète n'est pas encore nécessaire.

Cette stratégie augmente donc l'agilité des applications et optimise le retour sur investissement (ROI) dans le cloud.

Avantages :

  • Amélioration de la performance : le passage à des services managés comme Amazon RDS, Amazon S3, Amazon EFS ou Amazon FSx peut améliorer les performances et la scalabilité des applications, permettant de mieux gérer la charge sans modifications profondes du code.
  • Scalabilité accrue : en utilisant des services managés du fournisseur cloud comme le "Load Balancing" ou l'"Auto Scaling", les applications peuvent bénéficier d'une mise à l'échelle automatique pour mieux s'adapter aux variations de la demande sans intervention manuelle.
  • Réduction de la gestion opérationnelle : le fournisseur cloud gère une partie de l'infrastructure, ce qui réduit les tâches administratives.

Inconvénients :

  • Modifications limitées : le Replatforming n'implique que des ajustements mineurs (par exemple, le passage à un service managé) plutôt qu'une refonte complète des applications.
    Ainsi, certaines limitations des applications existantes peuvent demeurer, ce qui peut empêcher de tirer pleinement parti des avantages du cloud (par exemple, des architectures sans serveur ou des microservices).
  • Limitations de l'architecture existante : si les applications sont conçues pour une infrastructure sur site avec des configurations spécifiques, les adapter à un environnement cloud (même partiellement) pourrait ne pas suffire à libérer tout le potentiel du cloud.
    Les applications pourraient ne pas être aussi optimisées pour les nouveaux services managés que si elles avaient été entièrement réécrites pour le cloud.
  • Dépendance aux services cloud : le Replatforming implique une dépendance accrue aux services du fournisseur cloud, ce qui peut rendre l'entreprise vulnérable à des changements dans les politiques tarifaires de ce dernier, à la hausse des coûts d'utilisation des services, ou à la réduction de la flexibilité dans le choix des outils et services.
Rendre une application "cloud native" : Refactoring

"Refactoring" - Réécrire pour le cloud

Largement reconnue comme le choix de migration le plus complexe, le "Refactoring" implique une réécriture partielle ou totale des charges de travail pour en tirer pleinement parti des fonctionnalités natives du cloud.

Bien que cela exige un investissement substantiel en efforts, en temps et en ressources, cette stratégie se distingue comme l'approche de migration la plus avant-gardiste.

Cette stratégie est recommandée pour les applications dont la complexité et les besoins de performance justifient une transformation en profondeur pour s’adapter pleinement aux services cloud et ainsi leur donner un avantage pour prospérer dans des environnements technologiques en constante évolution.

Il peut s'agir de décomposer une application monolithique en microservices ou d’adopter des architectures sans serveur (serverless) en s'appuyant sur des services comme Amazon DynamoDB, AWS Step Functions, AWS Fargate ou AWS Lambda.

Avantages :

  • Optimisation pour le cloud : le principal avantage du Re-architecting est que les applications sont complètement repensées pour exploiter pleinement les capacités du cloud.
    Cela permet d’utiliser des services natifs du fournisseur cloud pour améliorer l'efficacité, la flexibilité et la performance des applications.
  • Scalabilité et flexibilité accrues : l'adoption de pratiques cloud natives (comme les microservices et le serverless) permet aux applications de se mettre à l'échelle automatiquement en fonction de la demande.
    Cela réduit les coûts associés à l'infrastructure sous-utilisée et permet de répondre rapidement aux besoins changeants des utilisateurs.
  • Réduction des coûts à long terme : bien que le coût initial de la migration soit élevé (en raison de la refonte complète), la migration vers une architecture cloud native permet de réduire les coûts d'infrastructure, de maintenance et de gestion à long terme.
    Par exemple, le recours aux services managés ou serverless du fournisseur cloud pour les bases de données ou le calcul réduit la nécessité d'une gestion constante de l'infrastructure.
  • Innovation et agilité : en adoptant des architectures modernes reposant sur les microservices ou le serverless, les entreprises peuvent devenir plus agiles et réactives face aux évolutions du marché.
    Les mises à jour et les améliorations des applications deviennent plus faciles et rapides, ce qui permet d’introduire plus rapidement de nouvelles fonctionnalités.

Inconvénients :

  • Coût initial élevé : la refonte complète des applications peut être coûteuse en termes de temps, de ressources humaines et d'infrastructure.
    Le processus implique généralement de réécrire une grande partie du code, ce qui peut représenter un investissement substantiel en développement et en tests.
  • Complexité de la migration : re-architecturer une application est un processus complexe qui peut perturber les opérations en cours.
    L’adaptation des équipes au nouveau modèle d’architecture cloud peut également entraîner des défis en termes de compétences, de gestion de projet et de planification.
  • Risque de perturbation des services : le processus de refonte des applications peut provoquer des interruptions de service, en particulier si la migration n'est pas soigneusement planifiée.
    Cela pourrait affecter l’expérience utilisateur et perturber les activités de l’entreprise pendant la phase de transition.
  • Nécessité de nouvelles compétences : l’adoption d'architectures modernes nécessite souvent de nouvelles compétences techniques.
    Les équipes de développement doivent être formées à ces nouvelles technologies et pratiques, comme le déploiement continu, la gestion des conteneurs ou le développement d'applications serverless.
    Cette courbe d’apprentissage peut retarder le projet.
  • Possibilité de dépendance au fournisseur (vendor lock-in) : la migration vers une architecture cloud native implique une forte dépendance aux services et outils spécifiques du fournisseur cloud, ce qui peut rendre la migration vers d'autres fournisseurs plus difficile à l'avenir.

"Repurchasing" - Passer à un nouveau modèle d'achat

Au lieu de migrer ou de refactorer, le "Repurchasing" consiste à abandonner une application existante administrée en interne au profit d'un service géré par des tiers comme une solution SaaS (Software as a Service) ou un logiciel fourni par un tiers dans le cloud.

Par exemple, migrer un logiciel interne de gestion des ressources humaines vers une solution SaaS telle que Workday ou Salesforce.

Les services étant créés et gérés par des fournisseurs tiers, le modèle de rachat réduit les efforts opérationnels de gestion de l'infrastructure pour les équipes internes.

Avantages :

  • Simplification de l'infrastructure : en adoptant des solutions SaaS, les entreprises éliminent la nécessité de gérer des applications internes, ce qui simplifie l'infrastructure.
    Les mises à jour, les patchs et la gestion de l'infrastructure sont pris en charge par le fournisseur de la solution SaaS, réduisant ainsi la charge de travail de l'équipe informatique.
  • Réduction des coûts d'exploitation : le modèle SaaS permet de passer à un paiement à l'usage, ce qui élimine les coûts d'infrastructure internes tels que les serveurs physiques, la gestion des licences logicielles et les coûts associés à la maintenance des applications.
    Les entreprises ne paient que pour ce qu'elles utilisent, ce qui peut réduire considérablement les coûts à long terme.
  • Mise à jour et maintenance automatiques : les fournisseurs SaaS gèrent les mises à jour et les correctifs de sécurité en continu, ce qui permet de bénéficier des dernières fonctionnalités et améliorations sans avoir à se soucier de la gestion des versions logicielles.
  • Accès à des fonctionnalités avancées : les solutions SaaS offrent souvent des fonctionnalités avancées (par exemple, l’intelligence artificielle, l’analyse des données, etc.) qui ne seraient pas disponibles ou difficiles à mettre en œuvre dans des applications internes.
    Cela permet aux entreprises de tirer parti de technologies de pointe sans investissement initial élevé.
  • Réduction des risques de gestion de la sécurité : les fournisseurs SaaS investissent massivement dans la sécurité et la conformité.
    En migrant vers des solutions SaaS, les entreprises bénéficient de la sécurité d'un service professionnel, souvent plus robuste que ce qu'elles pourraient mettre en place en interne.

Inconvénients :

  • Dépendance à un fournisseur externe (vendor lock-in) : en adoptant une solution SaaS, une entreprise devient dépendante de son fournisseur.
    Cela crée un verrouillage avec le fournisseur, et il peut être difficile de changer de solution ou de migrer vers un autre fournisseur si les besoins de l'entreprise changent à l'avenir.
  • Personnalisation limitée : les solutions SaaS offrent souvent peu de possibilités de personnalisation.
    Si une entreprise a des besoins très spécifiques, elle pourrait découvrir que l’outil SaaS ne répond pas entièrement à ses attentes, ou que des fonctionnalités personnalisées nécessitent des coûts ou des efforts supplémentaires.
  • Coûts récurrents : bien que le modèle SaaS puisse réduire les coûts d'infrastructure, les frais récurrents de souscription peuvent s'accumuler à long terme.
    Selon la taille de l'entreprise et le nombre d’utilisateurs, les coûts d'abonnement mensuels peuvent devenir importants, surtout si plusieurs applications SaaS sont nécessaires.
  • Problèmes de compatibilité et d'intégration : passer à une solution SaaS peut entraîner des problèmes d'intégration avec des systèmes internes existants.
    Les entreprises doivent s'assurer que les solutions SaaS choisies peuvent bien s'intégrer avec les autres systèmes d'entreprise, ce qui peut parfois nécessiter des travaux d'intégration complexes ou l'utilisation de services supplémentaires.
  • Contrôle limité sur les données et la sécurité : lorsque vous migrez vers une solution SaaS, vous confiez la gestion des données et de la sécurité au fournisseur.
    Bien que les fournisseurs SaaS investissent généralement beaucoup dans la sécurité, cela peut être un inconvénient si l’entreprise doit répondre à des exigences strictes en matière de confidentialité des données, de réglementation ou de conformité.
  • Moins de contrôle sur les fonctionnalités et les mises à jour : l'entreprise n'a pas toujours le contrôle sur les mises à jour ou les modifications apportées à la solution SaaS.
    Si une nouvelle fonctionnalité est ajoutée ou si un changement est effectué dans l'outil, l'entreprise doit s'adapter à ces changements, ce qui peut parfois perturber les processus internes.

Conclusion

Difficile de faire le bon choix entre toutes ces stratégies de migration !

Il n'y a bien évidemment pas de bonne réponse car tout dépend :

  • des priorités de l'entreprise, de ses contraintes budgétaires, des exigences métier et des objectifs à long terme.
  • de l'application à migrer : sa taille, sa complexité, ses exigences matérielles, ses exigences d’évolutivité et de disponibilité, sa compatibilité technique avec l’infrastructure cloud et bien d'autres facteurs techniques.

Chacune de ces stratégies présente des avantages spécifiques :

  • Relocating et Rehosting sont idéales pour les entreprises qui cherchent à migrer rapidement sans modification majeure, permettant une transition fluide, bien que ces stratégies puissent manquer d'optimisation des ressources cloud.
  • Replatforming propose une amélioration de la performance sans refactorisation complète, tandis que Refactoring offre une refonte profonde pour exploiter pleinement les avantages du cloud, mais au prix de coûts et de temps plus importants.
  • Repurchasing, en choisissant de remplacer des applications existantes par des solutions SaaS, peut être une option rapide pour réduire les coûts et simplifier les opérations, bien qu'il puisse entraîner des changements significatifs dans les processus métiers.
  • Retaining permet de conserver certaines applications sur site pour des raisons de conformité ou de coûts, tout en migrant d'autres vers le cloud, tandis que Retiring consiste à éliminer les applications obsolètes ou inutiles, ce qui réduit les coûts et simplifie l'infrastructure.

Pour vous aider dans votre projet de migration, AWS propose un arbre de décision qui vous aidera certainement à identifier le ou les bonnes stratégies à utiliser, au cas par cas.

N'oubliez pas, la migration vers le cloud est un projet de grande envergure qui nécessite une planification et une réflexion minutieuses afin de réduire le risque de problèmes, mais de nombreuses entreprises ont déjà ouvert la voie par leurs essais et leurs erreurs et ceci a permis de tracer des voies codifiées dans les « modèles R ».