Sortir d'un mainframe IBM Z et cibler Azure en incrémental.

La modernisation se livre par vagues fonctionnelles successives plutôt que sur un plan monolithique : la cadence est définie au cadrage selon le volume et la criticité. Les transactions non critiques sont migrées en premier, les transactions critiques (paiements, comptabilité centrale) en dernier. La coexistence mainframe-Azure dure toute la durée du programme. L'objectif est la décommission totale du mainframe à la fin, pas uniquement son allégement.

Oui, c'est le rehosting sur émulateur (Micro Focus Enterprise Server, TmaxSoft OpenFrame). Le code COBOL tourne sur des VMs Azure. Avantages : migration rapide, faible effort initial, préservation du code existant. Inconvénients : pas de modernisation réelle (dette technique préservée), dépendance à un éditeur tiers, coûts de licence émulateur souvent élevés. Nous considérons cette approche comme un palier temporaire utile pour sortir rapidement du hardware IBM, mais pas comme une cible finale. La vraie modernisation vient dans un second temps avec réécriture en Java, .NET Core ou TypeScript.

C'est un accélérateur utile mais pas une solution clé en main. Azure Mainframe Migration propose outils d'analyse, partenariats (Micro Focus, Raincode, Astadia, TmaxSoft), et services managés adaptés aux workloads mainframe. Ces outils peuvent convertir du COBOL vers Java ou .NET automatiquement, mais la sortie nécessite un travail de caractérisation, d'audit de parité et de refactoring significatif. Notre méthodologie ATLAS intègre ces outils comme accélérateurs quand pertinent, sans les considérer comme une fin en soi.

Azure permet une élasticité native que le mainframe n'offre pas à ce prix. Les pics de fin de mois sont absorbés par l'auto-scaling AKS ou App Service, avec montée automatique et descente en creux. L'arrêté comptable annuel peut être traité par un cluster dédié temporaire. Cette élasticité génère des économies significatives par rapport au mainframe dimensionné pour le pic et sous-utilisé le reste du temps. Économie typique : 30 à 50 pour cent sur le TCO à horizon 3 ans après modernisation complète.

Le budget d'une sortie de mainframe se joue sur la taille du parc (souvent d'un à dix millions de lignes COBOL) et surtout sur la trajectoire retenue, qui change l'ordre de grandeur du tout au tout. Nous ne chiffrons pas un mainframe sur déclaratif : l'Intake ATLAS établit l'inventaire réel des programmes, des chaînes JCL et des frontières transactionnelles CICS avant tout engagement. Cadrage initial gratuit, de 30 minutes à 2 heures.

Trois risques majeurs : fatigue organisationnelle (les équipes fatiguent sur un programme long), changement de priorités direction (budget, stratégie), obsolescence technologique cible (les technologies cibles évoluent en cinq ans). Atténuations : jalons contractuels pour valider chaque palier, livraisons incrémentales avec valeur métier visible chaque année, architecture cible modulaire qui peut être révisée sans remettre en cause les fondations. Notre expérience : les programmes qui livrent de la valeur visible chaque année aboutissent, ceux qui promettent un big-bang à cinq ans dérapent.

Cela dépend de la stratégie de migration et du périmètre. Trois trajectoires aux profils de coût très différents : le lift-and-shift (rehost sur machines virtuelles Azure avec émulateur), le plus rapide mais qui conserve la dette ; le replatform (passage à Azure SQL, App Service, Container Apps en gardant l'essentiel du code) ; et le refactor (modernisation cloud-native en microservices), le plus long mais le seul qui supprime réellement la dépendance. Le choix de trajectoire, fait en fin d'Intake, pèse plus sur le budget que la taille du parc. Cadrage initial gratuit, de 30 minutes à 2 heures.