La pire stratégie de migration est celle qui traite toutes les applications de la même manière : soit on déplace tout tel quel (et on emporte tous les défauts dans le cloud), soit on veut tout refaire (et on explose les délais et le budget). Le cadre des 6 R, popularisé par AWS, sert justement à arbitrer charge par charge.
1. Rehost — « lift and shift »
On déplace l'application telle quelle vers le cloud, sans la modifier. Rapide et peu risqué, idéal quand l'échéance presse (sortie de datacenter) ou pour une application stable. Exemple : un back-office interne qu'on rapatrie sur EC2 à l'identique.
2. Replatform — « lift, tinker and shift »
On déplace en faisant quelques optimisations sans réécrire le cœur : passer une base de données vers un service managé (RDS), conteneuriser. Le meilleur rapport gain/risque dans bien des cas.
3. Repurchase — on remplace
On abandonne l'application au profit d'une solution SaaS. Exemple : remplacer un CRM maison vieillissant par une offre du marché plutôt que de le migrer.
4. Refactor — on refond
On réécrit ou on ré-architecture pour exploiter pleinement le cloud (scalabilité, services managés). Le plus coûteux, à réserver aux applications stratégiques où le gain le justifie vraiment.
5. Retire — on supprime
La migration est l'occasion d'un inventaire. Souvent, 10 à 20% des charges ne servent plus : on les éteint, et c'est autant de moins à migrer et à payer.
6. Retain — on conserve
Certaines applications ne doivent pas (encore) bouger : contraintes réglementaires, dépendance forte, ROI insuffisant. On les garde en l'état, en connaissance de cause.
À retenir
- Migrer, c'est d'abord trier : chaque charge mérite sa propre stratégie.
- Rehost et Replatform couvrent l'essentiel ; Refactor se réserve au stratégique.
- Retire (supprimer l'inutile) est souvent le gain le plus rentable et le plus oublié.