6 stratégies de migration d’application vers le cloud

Rehosting , replatforming , refactoring... Le point sur les principaux axes stratégiques qui sous-tendent un chantier de migration vers le cloud.

De manière générale, les entreprises réfléchissent à la façon de migrer leurs applications au cours de la phase de découverte du portfolio et de planning du processus. C’est à ce moment qu’elles définissent leur environnement et les interdépendances, déterminent les migrations simples ou plus complexes à réaliser, et comment elles procéderont pour chaque application.

Après avoir pris connaissance de ces éléments, les entreprises élaborent un plan d’action (qui sera sujet à changements tout au long du processus) et décident du calendrier de migration.

La complexité de la migration d’applications déjà existantes varie selon l’architecture et les contrats de licence déjà existants. S’il fallait classer les applications à migrer sur un baromètre de complexité, une architecture virtualisée, axée sur le service serait de faible complexité, alors que les mainframes monolithiques se situeraient à l’opposé du baromètre, au niveau de projets de grande complexité.

Le plus simple est de commencer avec les applications les moins complexes à migrer car ce premier succès aura un effet positif sur la mise en place du processus global.

Les 6 stratégies de migration d’application : « Les 6 R »

1. Rehosting  – Le ré-hébergement, aussi connu sous le nom de “basculement”

De nombreux projets cloud se tournent vers le nouveau développement .NET, qui utilise les capacités dérivées du cloud. Mais dans un scénario de migration de volumes importants dans lequel une entreprise souhaite réaliser une opération rapide conforme à son analyse de rentabilité, la majorité des applications sont ré-hébergées. Ainsi, sans forcément mettre en place d’optimisations du cloud, il est possible d’économiser environ 30% des coûts grâce au ré-hébergement.

La plus grande partie du ré-hébergement peut être automatisée grâce à quelques outils. Cependant, certains clients préfèrent le faire manuellement pour comprendre comment installer leur ancien système sur la nouvelle plateforme cloud.

Il est également intéressant de noter que les applications sont également plus simples à optimiser une fois qu’elles sont exécutées dans le cloud. Cela s’explique en partie par le fait que le personnel d’une entreprise aura alors acquis les compétences nécessaires pour le faire, mais également parce que le plus dur – la migration des applications, des données, et du trafic – aura déjà été fait.

2. Replatforming  – Aussi appelé “basculement de base de données”

C’est ici que certaines optimisations du cloud peuvent être effectuées afin d’obtenir des bénéfices concrets, sans pour autant changer l'architecture de base de l'application. La réduction du temps passé à la gestion des instances de base de données peut se faire en effectuant une migration vers une plateforme DBaaS (base de données comme service), ou vers une plateforme complètement gérée par un opérateur cloud.

3. Repurchasing  – Le rachat, afin de passer à un produit différent

Le rachat est le plus souvent effectué pour passer à une plateforme SaaS. Par exemple, déplacer un CRM vers Salesforce.com, un système RH vers Workday, un CMS vers Drupal, etc.

4. Refactoring / Re-architecting – Le remaniement / la réorganisation, pour repenser la façon dont l’application est organisée et développée, le plus souvent grâce à des fonctionnalités dérivées du cloud.

Il est typiquement effectué lorsqu’une entreprise a besoin d’ajouter des fonctionnalités, de développer l’adaptabilité ou d’augmenter les performances, ce qu’il aurait été difficile de réaliser dans l’environnement déjà existant de l’application.

Aujourd’hui une organisation peut désirer passer d’une architecture monolithique à une autre axée sur le service (ou sans serveur) afin de gagner en souplesse et améliorer la continuité de ses activités. Alors que ce schéma a tendance à être plus cher, il peut cependant être plus avantageux s’il comprend une bonne adéquation entre le produit et le marché.

5. Retire – Le retrait, pour se débarrasser des choses inutiles.

Une fois que l’inventaire de tout l’environnement est fait, il est possible de lancer une recherche dans chaque secteur fonctionnel pour déterminer lequel gère chaque application. Environ 10% du portfolio informatique d’une entreprise n’est plus utile et peut être désactivé. Cette économie peut améliorer l’analyse de rentabilité, orienter l’attention et le travail des équipes vers les applications qui, elles, sont utilisées, et diminuer l’environnement à sécuriser.

6. Retain – La rétention, car en général soit l’application est réorganisée, soit elle n’est pas migrée (provisoirement).

Le client peut avoir des difficultés d’amortissement, ne pas être prêt à privilégier une application récemment mise à jour, ou simplement être peu enclin à migrer certaines d’entre-elles. La migration ne doit concerner que ce qui est vraiment utile pour l’entreprise et, puisque l’essentiel d’un portfolio est transféré de infrastructure traditionnelle au cloud, il n’y aura sûrement pas grand-chose à garder.