Le navire ne s'arrête pas pour changer de terminal

Le port ouvre un nouveau terminal. Quais plus profonds, portiques plus rapides, raccordement ferroviaire direct. Le trafic de l'ancien terminal doit y aller, et pendant ce temps les navires continuent d'arriver.

Personne ne ferme l'ancien quai un vendredi soir pour tout rouvrir de l'autre côté le lundi matin. On transborde ligne par ligne. On commence par la cargaison la moins sensible, on regarde ce qui se passe, on ajuste les procédures, puis on prend la suivante.

Une migration vers Azure fonctionne exactement comme ça. Le mot, lui, induit en erreur : il évoque un événement unique avec une date dans un comité de pilotage. En pratique, il s'agit d'une file d'attente de charges de travail, chacune avec son évaluation, sa stratégie, sa fenêtre et son plan de repli.

Ce billet clôt la série. Il déroule la méthode complète, puis s'attarde sur les deux moments où les projets se plantent : le choix de la stratégie, et la bascule.

Une migration se joue en une suite de petites bascules, chacune décidée sur ses propres critères, chacune réversible jusqu'à un moment précis qu'il faut nommer à l'avance.

Le cycle complet

Avant le premier transbordement, l'exploitant du nouveau terminal veut trois choses : savoir ce qui arrive, savoir dans quel ordre, et disposer d'un quai prêt à recevoir.

La méthode d'adoption du cloud publiée par Microsoft découpe le travail en phases qui se chaînent, et surtout qui se rejouent. Stratégie et plan d'abord : pourquoi on migre, ce qu'on attend, et l'inventaire découpé en vagues. Préparation ensuite : la zone d'atterrissage, c'est-à-dire le quai viabilisé. Adoption enfin, en trois temps répétés à chaque vague : évaluer, déployer, mettre en service.

flowchart LR S["Stratégie
motivations et résultats attendus"] --> P["Plan
inventaire et vagues"] P --> R["Préparation
zone d'atterrissage"] R --> A1["Évaluer
dimensionner et estimer"] A1 --> A2["Déployer
répliquer et tester"] A2 --> A3["Mettre en service
bascule et vérification"] A3 --> O["Optimiser
coût, sécurité, exploitation"] O -.->|"vague suivante"| A1 classDef amont fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef vague fill:#d89253,stroke:#8a4d16,color:#2c3338; classDef fin fill:#2c3338,stroke:#1f2428,color:#f5f2ec; class S,P,R amont; class A1,A2,A3 vague; class O fin;

La flèche de retour est la partie qui compte. Les trois phases du bas ne se font pas une fois pour tout le parc, elles se font une fois par vague. La première vague sert à découvrir ce que le plan avait oublié, la deuxième à corriger la procédure, les suivantes à accélérer.

L'erreur classique consiste à traiter la découverte et l'évaluation comme une étude préalable qu'on solde en janvier pour migrer toute l'année. Six mois plus tard, les mesures ne valent plus rien.

Le rythme de vagues est le mécanisme qui permet à une migration d'apprendre de ses propres erreurs tant qu'elles coûtent encore peu.

Découvrir

Avant de transborder, la capitainerie compte ce qu'il y a sur le quai. Pas seulement les conteneurs : leur contenu, leur propriétaire, et surtout ce qui doit partir ensemble parce qu'une cargaison sans ses papiers ne franchit pas la douane.

La découverte commence par un inventaire automatisé. Une appliance déployée sur site interroge l'environnement de virtualisation ou les serveurs eux-mêmes, remonte la configuration de chaque machine, et collecte des données de performance en continu pendant plusieurs semaines. C'est cette collecte dans la durée qui donne sa valeur à l'évaluation suivante.

L'inventaire remonte presque toujours les mêmes surprises : des serveurs que plus personne ne revendique, des versions de systèmes d'exploitation qui ne sont plus supportées, des tâches planifiées dont le résultat arrive quelque part sans que personne sache où.

Vient ensuite l'analyse des dépendances, qui décide de l'ordre des vagues. Deux méthodes, avec un vrai arbitrage entre elles.

Critère Analyse sans agent Analyse avec agent
À installer sur les machines Rien, mais des identifiants d'accès à l'invité sont fournis à l'appliance Un agent par machine, avec remontée vers un espace de travail
Ce qu'on voit Les connexions entre machines découvertes, relevées à intervalles réguliers Les connexions avec le détail des processus et des ports
Périmètre Limité à ce que l'appliance découvre Couvre aussi les machines hors du périmètre de l'appliance
Délai avant premier résultat Immédiat après la découverte Le temps de déployer et de faire valider les agents
Quand le choisir Cartographie initiale, parc virtualisé homogène Application critique dont on doit prouver l'isolement avant la vague

Le résultat change concrètement le plan. Un serveur applicatif migré sans la base qu'il interroge cinquante fois par page ajoute un aller-retour vers le site d'origine sur chacun de ces cinquante appels. L'application fonctionne, elle est simplement inutilisable.

D'où la règle qui structure le découpage : une vague contient un groupe de dépendance complet, ou elle ne contient rien.

La cartographie des dépendances a une finalité opérationnelle : décider ce qui doit partir dans le même train, et ce qui peut attendre trois mois.

Évaluer

Un armateur ne réserve pas un poste d'amarrage sur la taille de cale négociée il y a dix ans. Il le réserve sur le tirant d'eau réel du navire qui arrive demain.

L'évaluation transforme l'inventaire en cibles dimensionnées et en estimation de coût. Deux critères de dimensionnement sont possibles, et l'écart entre les deux est le premier enseignement du projet.

Le dimensionnement selon les performances mesurées s'appuie sur l'historique collecté pendant la découverte. Il révèle en général un parc massivement surdimensionné, parce que les machines ont été taillées pour un pic redouté qui n'est jamais venu.

Le dimensionnement selon la configuration existante recopie les processeurs, la mémoire et les disques tels qu'ils sont. C'est le bon choix quand l'historique est trop court, quand la période observée n'est pas représentative, ou quand un éditeur tiers impose une configuration contractuelle.

Plusieurs paramètres de l'évaluation modifient le résultat sans qu'on y pense, à commencer par le percentile d'utilisation retenu et le facteur de confort appliqué par-dessus.

Observation sur 30 jours, 95e percentile d'utilisation : 3,2 vCPU

Facteur de confort 1,0  ->  3,2 vCPU  ->  taille à 4 vCPU
Facteur de confort 1,3  ->  4,2 vCPU  ->  taille à 8 vCPU

Même machine, même mesure, un seul paramètre déplacé, et la ligne de facture double. Ce paramètre est un choix d'entreprise, pas un réglage technique, et il mérite d'être assumé par quelqu'un.

Le rapport d'évaluation se lit avec méthode, parce qu'il annonce des verdicts qui n'en sont pas.

Ce que dit le rapport Ce qu'il faut vérifier derrière Décision qui en découle
Prête pour Azure Que l'historique couvre une période réellement représentative La charge entre dans le plan de vagues
Prête sous conditions La nature exacte de la condition : version de système, taille de disque, mode de démarrage Corriger avant, ou basculer sur un réhébergement avec ajustements
Non prête Si le blocage est technique ou contractuel Remplacer, réarchitecturer, ou conserver sur place
État indéterminé Les identifiants et la complétude de la collecte Retour à la découverte, aucune décision n'est possible
Taille cible recommandée Le percentile et le facteur de confort utilisés Arbitrage explicite entre marge et coût
Estimation mensuelle Ce qui n'est pas dedans : sortie de données, sauvegarde, licences tierces, environnements hors production Budget réaliste, incluant la double exploitation

Cette dernière ligne mérite un paragraphe. Pendant une migration, l'ancien site tourne encore et le nouveau tourne déjà. Cette période de recouvrement se paie deux fois, et elle dure aussi longtemps que la dernière vague.

Dernier réflexe : refaire l'évaluation juste avant la vague, pas au début du projet. Entre les deux, la charge a bougé et les tailles disponibles aussi.

Une évaluation reste un calcul dont tu as choisi les paramètres. Change le percentile, le facteur de confort ou la région cible, et le rapport dit autre chose.

Les six stratégies

Toutes les cargaisons ne se transbordent pas de la même façon. Un conteneur normalisé passe d'un portique à l'autre sans être ouvert. Une cargaison en vrac doit être reconditionnée. Et certaines marchandises n'ont plus de destinataire depuis deux ans, auquel cas la bonne opération consiste à ne pas les déplacer du tout.

Six issues possibles par charge de travail, quel que soit le nom qu'on leur donne.

Héberger tel quel

La machine part telle quelle vers une machine virtuelle équivalente. Le système, les binaires, les configurations, tout suit. C'est rapide, c'est prévisible, et ça ne règle aucun problème de fond.

Le signe qui la désigne : une échéance de sortie de centre de données, du matériel en fin de vie, ou un logiciel tiers dont l'éditeur ne propose rien de managé.

Réhéberger avec ajustements

On change le socle sans toucher au code. Une base sur machine virtuelle devient une base managée, un serveur web devient un service applicatif managé, un partage de fichiers devient un partage managé.

Le signe : l'application est packagée proprement, ne dépend d'aucun composant installé à la main sur le système, et son éditeur ou son équipe confirme la compatibilité.

Refactorer

On modifie le code à la marge pour qu'il vive correctement sur la plateforme. Conteneuriser, sortir les secrets vers un coffre, remplacer un état de session stocké localement, remplacer un chemin de fichier en dur par un stockage objet.

Le signe : l'application est encore développée par une équipe qui la connaît et qui peut livrer une version dans le trimestre.

Réarchitecturer

On change le découpage, le modèle d'exécution ou le modèle de données. C'est le chantier le plus lourd et il ne se justifie que par une exigence non-fonctionnelle qu'on ne peut pas satisfaire autrement.

Le signe : la structure actuelle empêche une capacité qui a une valeur mesurable, mise à l'échelle élastique ou cadence de livraison.

Remplacer

On abandonne le logiciel et on prend un service en ligne du marché. Ce qui migre, ce sont les données et les habitudes, pas le code.

Le signe : une fonction générique qu'on maintenait sans en tirer d'avantage, messagerie, gestion des tickets, paie, portail documentaire.

Conserver

On ne migre pas. Contrainte réglementaire, latence vers un équipement industriel sur site, ou application dont l'arrêt est déjà planifié dans dix-huit mois.

Le signe : le coût de la migration dépasse ce que l'application va encore rendre.

Stratégie Effort Bénéfice Risque principal Signe qu'elle s'impose
Héberger tel quel Faible Sortie du centre de données, rapidité Reproduire le surdimensionnement et le payer au mois Échéance de sortie, matériel en fin de vie
Réhéberger avec ajustements Moyen Moins d'exploitation, correctifs pris en charge Incompatibilité découverte tard dans la recette Application packagée, socle standard
Refactorer Moyen à élevé Élasticité, secrets sortis du code Chantier qui s'étale et bloque la vague Équipe active sur le produit
Réarchitecturer Élevé Mise à l'échelle et cadence de livraison Périmètre qui gonfle, migration jamais terminée Exigence non tenable en l'état
Remplacer Variable Plus rien à exploiter Reprise de données et conduite du changement sous-estimées Fonction générique sans valeur propre
Conserver Nul Aucun argent dépensé pour rien Dette repoussée sans date Fin de vie proche ou contrainte physique

Une septième option existe et personne ne l'inscrit au plan : éteindre. La découverte remonte régulièrement des serveurs que plus aucun flux n'atteint. Les arrêter est la migration la moins chère du projet.

Reste à nommer le piège du « tout héberger tel quel ». Migrer l'ensemble du parc en l'état en promettant d'optimiser ensuite fonctionne sur le papier. Dans les faits, l'équipe passe à la vague suivante, l'optimisation glisse, et le parc surdimensionné d'hier devient une facture mensuelle. Le choix du service de calcul se pose au moment de la migration, pas six mois après.

La stratégie se décide charge par charge, jamais pour tout le parc. Un même système peut être hébergé tel quel pour sa partie serveur, réhébergé avec ajustements pour sa base, et remplacé pour sa brique de messagerie.

Les outils

Un port ne loue pas qu'un quai. Il fournit les portiques, les cavaliers, les bordereaux, et un guichet unique qui garde la trace de ce qui est entré et sorti.

Azure Migrate joue ce rôle de guichet. On y crée un projet par périmètre, rattaché à un abonnement et à une région de métadonnées, et ce projet conserve l'inventaire, les évaluations successives et l'état des réplications. Les outils qui s'y rattachent couvrent les grandes familles de charges.

Migration de serveurs. La réplication sans agent convient aux environnements virtualisés pris en charge : rien à installer dans l'invité, la copie se fait depuis la couche de virtualisation. La réplication avec agent couvre les serveurs physiques et les machines hébergées ailleurs, au prix d'un composant installé sur chacune.

Migration de bases de données. Le registre des manifestes est ce qui se déplace le moins facilement. On commence par une évaluation de compatibilité qui liste les fonctionnalités utilisées et non prises en charge par la cible envisagée. Puis on choisit entre une migration hors ligne, où la base est arrêtée le temps de la copie, et une migration en ligne, où une synchronisation continue réduit la fenêtre d'arrêt à la seule bascule finale.

Migration d'applications web. Une évaluation dédiée détermine si une application peut être portée vers un service applicatif managé, et signale ce qui l'en empêche.

Transfert physique. Quand le lien réseau ne suffit pas, des appareils de transfert hors ligne prennent le relais : des disques pour quelques téraoctets, un boîtier pour quelques dizaines, un appareil sur roulettes pour l'ordre du pétaoctet. Le calcul qui tranche tient en trois lignes.

Volume à transférer   : 100 To  =  800 000 Gb
Lien dédié            : 1 Gb/s, 70 % de débit utile
Durée théorique       : 800 000 / 0,7 = 1 142 857 s = 13,2 jours en continu

Treize jours, à condition que le lien soit entièrement réservé à la migration. S'il porte aussi la production, la durée double ou triple, et la fenêtre de vague devient ingérable.

Ordre de grandeur Contrainte dominante Méthode raisonnable
Quelques centaines de gigaoctets Aucune Réplication réseau, en continu
Quelques téraoctets Bande passante partagée avec la production Réplication réseau avec limitation de débit et fenêtres nocturnes
Dizaines de téraoctets sur lien saturé Durée de transfert supérieure à la fenêtre Transfert hors ligne, puis rattrapage du delta par le réseau
Centaines de téraoctets et au-delà Site isolé ou lien faible Appareil de transfert haute capacité
Données qui changent pendant le transfert Cohérence à la bascule Copie initiale hors ligne plus synchronisation avant bascule

Aucun de ces outils ne prend de décision. Ils exécutent un choix fait à l'évaluation, et ils l'exécutent aussi fidèlement s'il est mauvais.

Le choix de l'outil découle du volume, du délai acceptable et de la fenêtre d'arrêt. Ces trois nombres se posent avant d'ouvrir la console, pas pendant.

La bascule

C'est le moment où l'on largue les amarres. Le pilote est à bord, la marée n'attend pas, et à partir d'un certain point le navire ne peut plus revenir à son ancien poste.

Le mécanisme est toujours le même. Une réplication initiale copie l'intégralité de la source vers la cible, sans interruption de service, sur des heures ou des jours. Puis une réplication delta maintient l'écart à quelques minutes, aussi longtemps qu'il faut.

Entre les deux, le test de migration. On démarre une copie de la cible dans un réseau isolé, sans toucher à la production, et on vérifie ce qui casse réellement : le démarrage du système, le service applicatif, les licences liées au matériel, les noms de serveurs en dur, les certificats, l'accès aux dépendances restées sur site. Ce test se rejoue autant de fois que nécessaire, et son coût est ridicule comparé à celui d'une fenêtre ratée.

sequenceDiagram participant U as Utilisateurs participant S as Source participant R as Réplication participant C as Cible participant D as Aiguillage R->>C: copie initiale R->>C: synchronisations delta Note over U,S: gel des changements sur la source U->>S: dernières écritures S->>S: arrêt propre du service R->>C: delta final C->>C: démarrage et vérifications techniques U->>C: vérifications fonctionnelles métier D->>C: bascule du trafic Note over S,C: source conservée intacte, retour arrière encore possible

La fenêtre elle-même se répète comme une chorégraphie, avec des horaires écrits et un nom en face de chaque geste.

J-5   revue des critères de sortie, gel des changements sur la source
J-2   dernier test de migration dans le réseau isolé
J-0   19h00  arrêt propre du service, dernière synchronisation delta
      20h30  démarrage de la cible, vérifications techniques
      21h30  vérifications fonctionnelles par les équipes métier
      22h00  décision de poursuivre ou de renoncer
      22h15  bascule du trafic, ou retour à la source
J+1   surveillance renforcée, source éteinte mais intacte
J+15  point de non-retour, démantèlement de la source

Trois éléments de ce plan sont non négociables.

Le gel des changements couvre la source et la cible. Une mise en production côté source pendant la réplication finale, et le delta ne contient pas ce que tout le monde croit.

Les critères de sortie s'écrivent avant la fenêtre, jamais pendant. À 22h00, personne n'est en état d'inventer une définition du succès, et l'énergie déjà dépensée pousse toujours à continuer.

Le retour arrière a une date de péremption, et c'est le concept le plus mal compris de la migration. Tant que la cible n'a accepté aucune écriture métier, revenir consiste à rallumer la source. Dès que des utilisateurs ont saisi des données dans la cible, le retour arrière devient une migration inverse, avec sa propre réplication et sa propre fenêtre. Le moment exact où l'on franchit cette ligne se décide à l'avance, avec la personne qui a l'autorité de dire non.

Une sauvegarde valide de la source, prise avant la fenêtre et vérifiée, reste le filet de dernier recours. Le sujet est traité en entier dans le billet sur la sauvegarde et la reprise.

La question qui structure une fenêtre de bascule n'est pas « comment on y va ». C'est : à quelle heure exactement décide-t-on de renoncer, sur quels critères, et qui a le pouvoir de le dire.

Ce qui doit exister avant la première charge

On ne transborde pas vers un quai qui n'a ni raccordement électrique, ni poste de douane, ni registre d'entrée.

La zone d'atterrissage précède la première machine migrée. Hiérarchie de groupes d'administration et découpage en abonnements, plan d'adressage qui ne chevauche pas le réseau interne, raccordement hybride opérationnel, rôles et accès, stratégies de gouvernance et convention d'étiquetage, journalisation centralisée, sauvegarde, budgets et alertes.

Sans ce socle, la première charge migrée définit par accident les conventions que les deux cents suivantes vont hériter. Et défaire un plan d'adressage après cinquante machines coûte une seconde migration.

Tout ce socle, et la façon de le produire par du code plutôt qu'à la main, fait l'objet du billet sur la zone d'atterrissage et le déploiement automatisé.

La migration ne crée pas la gouvernance, elle l'expose. Ce qui n'a pas été décidé avant la première vague sera décidé dans l'urgence par la personne qui exécute la troisième.

Scénario B : TSB, la bascule qu'on ne pouvait plus annuler

En avril 2018, la banque britannique TSB migre ses systèmes vers une nouvelle plateforme. L'opération se déroule sur le week-end du 20 au 22 avril, et la mise en service est prononcée le dimanche.

Dès l'ouverture, les services numériques ne fonctionnent pas correctement. Des clients n'accèdent pas à leurs comptes, d'autres constatent des affichages incohérents. Les perturbations durent des semaines, pas des heures, et mobilisent la banque, ses centres d'appel et son régulateur.

Le conseil d'administration commande une revue indépendante au cabinet Slaughter and May, publiée en 2019. Le rapport décrit une bascule engagée alors que la plateforme n'était pas prête à supporter la production réelle, avec des tests insuffisants sur la configuration cible et sur le comportement à l'échelle, et sans possibilité réaliste de revenir en arrière une fois l'opération lancée.

En décembre 2022, la Financial Conduct Authority et la Prudential Regulation Authority sanctionnent TSB pour des défaillances de gestion du risque opérationnel et de gouvernance liées à cette migration, pour un montant cumulé d'environ 48,65 millions de livres. Les deux autorités ont publié leurs décisions.

Quatre enseignements se transposent directement.

Le test qui manque est toujours le même : celui qui reproduit la charge réelle sur la configuration réelle. Les tests fonctionnels passent, parce qu'ils testent des fonctions une par une, sur un environnement calme.

Le retour arrière se périme. Une fois que la clientèle a commencé à utiliser la nouvelle plateforme, revenir à l'ancienne n'est plus une option technique, c'est un second projet. Cette limite doit être connue et datée avant la fenêtre.

La bascule d'un seul bloc supprime la vague. Quand tout part ensemble, il n'y a plus de première migration modeste pour révéler le défaut de préparation à un coût supportable.

Enfin, le coût ne se mesure pas pendant la fenêtre. Il se mesure sur les semaines qui suivent, en indisponibilité, en traitement manuel, en clients partis et en sanctions.

Une bascule sans répétition à l'échelle réelle et sans retour arrière encore valable n'est pas une bascule. C'est un pari, pris à une heure où plus personne n'a envie de l'annuler.

Points clés

  • La migration se traite par vagues, et chaque vague rejoue le cycle évaluer, déployer, mettre en service. Une étude préalable menée une seule fois pour toute l'année ne vaut plus rien six mois plus tard.
  • La cartographie des dépendances décide de l'ordre des vagues. Un groupe de dépendance part entier, sinon il ne part pas.
  • L'évaluation est un calcul paramétré, pas un verdict. Le percentile retenu et le facteur de confort font varier la taille cible d'un facteur deux, et la facture avec.
  • La stratégie se choisit charge par charge parmi six issues, et la septième, éteindre ce qui ne sert plus, est la moins chère de toutes.
  • La bascule se juge sur trois choses : un test de migration rejoué en environnement isolé, des critères de sortie écrits avant la fenêtre, et une date explicite au-delà de laquelle le retour arrière n'existe plus.

Dans la série

Palier 3 : Faire tourner le port. Domaine : Continuité.

Pour aller plus loin