Migration cloud : pourquoi les vagues battent le grand soir

La migration en un seul basculement séduit parce qu'elle est simple à présenter : une date, une équipe mobilisée, un avant et un après. Elle échoue pour la même raison : elle suppose que tout ce qui n'a pas été anticipé sera découvert et corrigé pendant la fenêtre.

Ce que la vague apporte

Migrer par vagues signifie découper le patrimoine en lots cohérents et basculer un lot à la fois, chacun avec son double run et son point de retour arrière.

Le premier lot sert d'apprentissage. Il révèle les surprises — dépendances non documentées, latences inattendues, droits manquants — sur un périmètre où l'impact est limité. Ces surprises existent dans toutes les migrations ; la seule question est de savoir sur quel lot elles se manifestent.

Chaque vague est réversible. Un retour arrière sur un lot est une opération de quelques heures. Un retour arrière sur une migration complète est un projet en soi, qui n'est presque jamais réellement possible.

L'équipe monte en compétence progressivement. Les runbooks s'affinent, les automatismes se construisent, la vague cinq coûte moins cher que la vague une.

Comment découper

Le découpage par couche technique — d'abord toutes les bases, puis tous les serveurs applicatifs — est le plus tentant et le plus dangereux : il crée une période où l'application est répartie entre deux environnements, avec des latences réseau que personne n'avait modélisées.

Découpez par domaine fonctionnel : un domaine complet bascule avec sa base, ses serveurs et ses flux. Les dépendances inter-domaines sont traitées par des interfaces temporaires, dont le coût doit être budgété explicitement.

Ordre recommandé : commencer par un domaine peu critique mais réaliste — ni le bac à sable, ni le cœur métier. Le bac à sable ne révèle aucune surprise ; le cœur métier ne pardonne pas la première.

Ce qu'il faut écrire avant de commencer

Le point de non-retour de chaque vague. À quel moment précis le retour arrière devient impossible ou trop coûteux. Cette information doit être connue de tous ceux qui participent à la bascule.

Le critère de succès de chaque vague. Mesurable, vérifié avant de lancer la suivante. « Ça a l'air de marcher » n'est pas un critère.

Le plan de retour arrière, testé. Un plan de retour arrière écrit et jamais exécuté est une fiction rassurante. Testez-le sur la première vague, en conditions réelles.

Le coût de la double exploitation

Pendant la migration, vous payez les deux environnements. C'est le principal argument avancé contre l'approche par vagues, et il est réel : une migration de dix-huit mois signifie dix-huit mois de double facture partielle.

Deux réponses. D'abord, ce coût est prévisible et budgétable, contrairement au coût d'un basculement raté. Ensuite, il se réduit à chaque vague, puisque l'ancien environnement peut être décommissionné lot par lot — à condition d'inscrire ce décommissionnement au périmètre de chaque vague, avec un jalon de paiement associé.

Le seul cas qui justifie le grand soir

Une date butoir contractuelle sur un centre de données, sans possibilité de prolongation. Dans ce cas, la migration en bloc est subie, pas choisie, et elle doit être préparée avec une répétition complète en environnement isolé — ce qui coûte plus cher que les vagues qu'on voulait éviter.