Migration : pourquoi le “lift & shift” finit souvent en facture x2

Le “lift & shift” a une promesse irrésistible : migrer vite, sans réécrire, en déplaçant les serveurs “tels quels” vers le cloud. Sur un slide, c’est propre. Dans un budget, c’est séduisant. Dans un planning, ça rassure : on transforme sans perturber. Et, parfois, ça marche. Mais souvent, quelques mois après la bascule, la même phrase revient dans les couloirs et en comité : “On paye deux fois plus… pour un service pas forcément meilleur.”

Ce n’est pas une fatalité. C’est une mécanique. Et elle se déclenche presque toujours quand on confond déplacer et moderniser, et qu’on sous-estime ce que le cloud facture vraiment : la complexité, l’inefficacité et l’absence de gouvernance.

Le malentendu de départ : “lift & shift” n’est pas une stratégie, c’est un mode de transport

Déplacer une application vers le cloud sans la changer revient à mettre un moteur ancien dans une voiture neuve. Ça roule, mais ça ne profite pas des capacités du véhicule. Le cloud est optimisé pour l’élasticité, l’automatisation, la standardisation, les services managés. Une application conçue pour un datacenter fixe, avec des serveurs dimensionnés “au pire”, des dépendances réseau internes, des batchs nocturnes lourds et des accès disque intensifs, sera rarement “efficiente” dans le cloud.

Le lift & shift est utile dans certains cas : urgence de sortie d’un datacenter, fin de contrat, risques matériels, besoin de gagner du temps avant une vraie refonte, ou migration d’un workload déjà bien industrialisé. Mais quand il devient la solution par défaut, il produit un effet presque certain : le coût monte avant que la valeur ne suive.

Facture x2 : les cinq mécanismes qui font exploser le coût

1) On conserve le surdimensionnement… et le cloud le facture au prix fort

Dans un datacenter, on a tendance à “surprovisionner” pour être tranquille : CPU, RAM, stockage. Ce surdimensionnement est déjà un coût, mais il est amorti et souvent moins visible. Dans le cloud, il devient une ligne de facture mensuelle, et il est multiplié par le fait que tout est à l’usage : compute, stockage, sauvegardes, IOPS, logs, monitoring.

Le lift & shift déplace le surdimensionnement tel quel. Résultat : vous payez des instances trop grosses 24/7, parfois pour absorber deux heures de pic par mois. Dans un cloud, l’efficience vient du dimensionnement fin et de l’élasticité. Sans ça, vous achetez du confort en continu.

2) Le réseau et l’egress : le piège invisible

C’est le grand oubli des slides : la donnée qui sort du cloud coûte. Les flux inter-zones, les transferts vers internet, les échanges entre environnements, les synchronisations hybrides, les sauvegardes externalisées, les appels vers des services externes… Tout cela peut devenir un poste majeur.

Le lift & shift garde souvent les habitudes réseau du datacenter : beaucoup de flux, peu optimisés, parfois entre couches applicatives trop bavardes. Dans le cloud, ces bavardages deviennent une taxe. Et quand le SI reste hybride (ce qui est fréquent), les allers-retours cloud/on-prem font grimper la facture, surtout si l’architecture n’a pas été pensée pour minimiser les traversées.

3) “On a déplacé les serveurs”… mais on a ajouté des couches

Très vite, on rajoute ce qui manquait : outils de sécurité, EDR, solutions de backup, monitoring, APM, bastions, scanners de vulnérabilités, gestion des secrets, outils de gouvernance. Souvent indispensables, mais rarement budgétés au départ. Dans le datacenter, une partie était déjà en place. Dans le cloud, on la recrée, parfois en doublon, parfois en version “cloud premium”.

Le résultat n’est pas seulement une facture plus élevée : c’est un empilement qui rend l’exploitation plus complexe. Et la complexité a un coût humain : plus d’heures, plus d’incidents, plus de dépendance à des spécialistes.

4) Les licences : le double effet pervers

Le lift & shift est souvent fait en “Bring Your Own License”, ou avec des modèles hybrides. Mais les surprises sont nombreuses : licences non transférables, compliance plus stricte, métriques différentes (vCPU), surcoûts d’édition, ou besoin d’acheter des options spécifiques dans le cloud.

Et quand on garde une partie on-prem en parallèle (le temps de stabiliser, de migrer la donnée, de gérer les environnements de test), on finit avec deux mondes : deux infrastructures, deux sauvegardes, deux réseaux, parfois deux licences. C’est là que la facture x2 devient littérale : double run.

5) La dérive d’environnements : “juste pour tester” devient permanent

Dans le cloud, créer un environnement est facile. Le détruire, beaucoup moins, parce qu’il “sert encore”. En lift & shift, on crée souvent des clones : dev, test, préprod, DR, sandbox. Si la gouvernance et le tagging ne sont pas stricts, ces environnements deviennent une fuite lente : instances allumées en permanence, disques oubliés, snapshots qui s’accumulent, logs en rétention infinie.

Ce n’est pas une question de discipline individuelle. C’est une question de cadre : sans règles, l’entropie gagne.

Le coût n’est pas le seul problème : le lift & shift peut aussi dégrader la qualité

On parle beaucoup de facture, mais un autre effet est plus dur : la perception utilisateur. Une application “liftée” peut devenir plus lente si elle dépend de latences réseau nouvelles, si la base est loin, si le stockage n’est pas adapté, ou si l’architecture n’a pas été optimisée pour un environnement distribué.

Et côté exploitation, la situation peut empirer : plus de composants, plus de métriques, plus de paramètres, et souvent une équipe qui doit apprendre le cloud “en marchant”, sous pression. Le résultat : un service qui coûte plus cher, sans gain visible. C’est le scénario le plus toxique, parce qu’il décrédibilise la transformation.

Pourquoi on persiste malgré tout : parce que le lift & shift est une bonne solution… à un mauvais problème

Le lift & shift répond à la peur : peur de la durée d’un programme de modernisation, peur de casser, peur du “big bang”, peur de ne pas livrer. Il donne une impression de vitesse. Et parfois, la vitesse est nécessaire, notamment quand le datacenter doit fermer ou qu’un contrat arrive à échéance.

Mais si l’objectif est “réduire les coûts” ou “gagner en agilité”, le lift & shift est rarement suffisant. Il ne transforme pas. Il déplace.

Comment éviter la facture x2 : trois règles simples avant de migrer

Règle 1 : migrer, oui, mais avec un plan d’optimisation dès le départ

Le lift & shift doit être présenté comme une étape, pas comme une fin. Dès la conception, il faut prévoir un second mouvement : right-sizing, autoscaling quand c’est pertinent, stockage adapté, optimisation des flux, usage de services managés là où ça fait sens. Sans ce plan, vous restez dans le “cloud datacenter”, qui est le cloud le plus cher.

Règle 2 : mettre FinOps et gouvernance avant la bascule, pas après

Tagging obligatoire, budgets, alertes, règles de rétention des logs, politiques d’extinction des environnements non utilisés, revues mensuelles des coûts. Le cloud est un système économique autant que technique. Si vous attendez la première facture pour gouverner, vous avez déjà perdu deux mois.

Règle 3 : choisir le bon niveau de transformation par application

Toutes les applications ne méritent pas la même stratégie. Certaines doivent être remplacées (SaaS), d’autres replatformées (services managés), d’autres refactorées, et quelques-unes liftées en urgence. L’erreur est de mettre tout dans le même camion.

Une migration mature ressemble à un portefeuille : chaque application a sa trajectoire, son coût, son risque, sa date de sortie, et sa cible.

La conclusion que les slides évitent : le cloud n’est pas cher, l’inefficacité est chère

Le lift & shift finit souvent en facture x2 parce qu’il fige dans le cloud les inefficacités du datacenter, et qu’il ajoute des coûts nouveaux sans changer le modèle. Le cloud devient alors un miroir : il rend visible ce qui était caché. Surdimensionnement, environnements orphelins, flux inutiles, absence de gouvernance, dette technique, et dépendances non maîtrisées.

Le bon message n’est donc pas “ne faites pas de lift & shift”. C’est : ne faites pas de lift & shift sans plan de transformation et sans gouvernance. Sinon, vous achèterez de la vitesse à court terme… au prix d’une complexité et d’une facture que vous paierez longtemps. Et vous finirez par faire la modernisation quand même — mais sous contrainte, avec moins de confiance, et plus d’urgence.

C’est exactement ce qui coûte le plus cher.