Migration cloud : stratégies, causes d'échec et réversibilité

Une migration cloud consiste à déplacer tout ou partie d’un système d’information depuis une infrastructure exploitée en interne vers une infrastructure exploitée par un tiers. Le déplacement technique est la partie simple. Ce qui fait échouer ces projets relève de l’inventaire incomplet, des interdépendances applicatives non documentées, et de l’absence de décision sur les applications qui ne devraient pas partir. Cette page pose les six stratégies possibles, les causes d’échec récurrentes et le sujet que l’on traite systématiquement trop tard, dans le prolongement de notre couverture cloud et infrastructure.

Les six stratégies, et ce qu’elles impliquent

Définition. Une stratégie de migration décrit le niveau de transformation appliqué à une application lors de son déplacement vers le cloud, du simple transfert à l’identique jusqu’à la réécriture complète ou l’abandon.

Les deux dernières lignes sont les plus rentables et les moins appliquées. Un inventaire sérieux révèle systématiquement des applications sans usage réel, maintenues par habitude, et des charges dont le maintien en interne coûte moins cher que la bascule. Décider de ne pas migrer est une décision de migration.

Ce qui fait réellement échouer un projet

L’inventaire incomplet

On ne migre pas ce qu’on n’a pas recensé. Les serveurs oubliés, les tâches planifiées dont personne ne connaît la finalité, les flux vers des systèmes tiers non documentés : ce sont eux qui provoquent les incidents le jour de la bascule, pas les applications identifiées.

Les interdépendances applicatives

Une application ne se déplace jamais seule. Elle appelle un annuaire, une base partagée, un service de fichiers, un ordonnanceur. Cartographier ces liens avant la bascule est le travail le plus ingrat du projet et celui dont l’absence coûte le plus cher.

Le dimensionnement à l’identique

Reproduire en cloud les caractéristiques du serveur physique existant garantit une facture décevante. Les serveurs internes sont dimensionnés pour un pic et amortis sur cinq ans. Le cloud se facture en continu. Le dimensionnement se refait à partir de la charge mesurée, pas de la configuration héritée. Ce point est développé dans notre section pilotage de la dépense cloud.

La trajectoire de compétences

Les équipes d’exploitation changent de métier. Sans plan de montée en compétences engagé avant la bascule, le projet livre une infrastructure que personne ne sait exploiter sereinement.

L’absence de critère de retour arrière

Chaque vague de bascule doit disposer d’un critère de succès mesurable et d’une procédure de retour arrière testée. Sans cela, l’équipe se retrouve à devoir réussir coûte que coûte, ce qui produit les décisions les plus coûteuses.

La réversibilité, sujet traité trop tard

C’est le point que ce type de projet reporte systématiquement, et qui détermine le rapport de force au premier renouvellement contractuel.

Trois questions à instruire avant de signer, pas après :

• Quel est le format d’export des données, et sous quel délai le fournisseur les met-il à disposition après résiliation ?
• Quel effort représente la sortie, service managé par service managé ? L’estimation se fait au moment du choix d’architecture, quand elle peut encore influencer ce choix.
• Quelles conditions contractuelles encadrent l’assistance à la reprise ?

Un plan de réversibilité n’a pas vocation à être exécuté. Il a vocation à exister, parce que son existence change la nature de la négociation. Le sujet croise directement les arbitrages traités dans notre section hyperscalers et dépendance fournisseur.

Séquencer la migration

1. Inventorier et cartographier. Applications, flux, dépendances, usages réels mesurés et non déclarés.

2. Classer par stratégie, application par application, jamais en bloc. Décider explicitement de ce qui reste et de ce qui disparaît.

3. Traiter le socle transverse avant les applications : annuaire, réseau, sauvegarde, supervision, sécurité.

4. Basculer par vagues, en commençant par des applications non critiques mais réelles. Un pilote sur une application sans utilisateur n’apprend rien.

5. Mesurer après chaque vague : coût constaté contre coût projeté, incidents, écarts de performance. Réajuster avant la vague suivante.

6. Décommissionner effectivement l’ancien environnement. Tant que l’ancien tourne, le projet paie deux fois et ne mesure aucun gain.

Le cas particulier de la sortie d’un parc virtualisé, avec ses échéances contractuelles propres, est traité dans notre section virtualisation et alternatives.

Explorer le cluster

Cette page fait partie de notre couverture des architectures cloud et infrastructures d’entreprise : hyperscalers, souveraineté, coûts, virtualisation et datacenters.

iTPro+ : recevez chaque semaine les analyses d’architecture et les retours de projet qui concernent les directions informatiques.