Loading...
Modernization of IBM z/OS mainframe applications to Microsoft Azure, using the strangler fig strategy and the ATLAS methodology.
IBM Z remains the transactional backbone of large banks, insurers, central administrations, and social security funds. Volumes are impressive: a Z mainframe in production routinely absorbs several thousand transactions per second with availability above 99.999 percent. The question is therefore not whether the mainframe works — it works very well — but at what cost it still works.
The signals that trigger modernization to Azure: annual mainframe license and infrastructure cost weighing on the IT budget (often between two and twenty million euros per year for a large enterprise), scarcity of COBOL and z/OS engineers forcing continuous training, predictable end of support for certain versions of DB2 z/OS or CICS, and standardization of the global IT toward the Microsoft Azure ecosystem. Our ATLAS methodology is designed to make this transition predictable, over several years, with no service interruption.
Azure is the natural choice for IT departments already committed to the Microsoft ecosystem (Active Directory, Office 365, Dynamics 365, Power Platform, SQL Server). Microsoft also offers Azure Mainframe Migration as a dedicated service, and a technical partnership with Micro Focus and Raincode for COBOL conversion. If your primary ecosystem is AWS, look at the Mainframe to AWS path. The key principle: choose the cloud that matches your global IT, not the cloud of the moment.
Microsoft ecosystem dominant, intent to use Azure managed services, progressive strangler fig migration. The default choice recommended by Microsoft.
Strong in-house Java skills, desire for cloud portability. Java code deployable on Azure but potentially on other clouds. See [COBOL to Java](/parcours/cobol-to-java).
Microsoft ecosystem at all levels, pooling of C# skills. See [COBOL to .NET Core](/parcours/cobol-to-dotnet-core).
AWS ecosystem dominant. See [Mainframe to AWS](/parcours/mainframe-to-aws).
Budget urgency, need to exit the IBM mainframe without immediate redesign. Lift-and-shift approach that preserves the COBOL code on cloud but does not truly modernize.
An IBM Z mainframe to Azure modernization program is structured over a **multi-year period — typically three to seven years** depending on volume and criticality. The typical cell starts with a senior **mainframe-cloud architect**, an **Azure tech lead**, three to six **COBOL-Java/.NET developers**, a **DB2-SQL Server DBA**, a **cloud network engineer**, a QA specialized in parity tests, and a delivery director. For a mainframe estate of **one to five million lines of COBOL** (typical large enterprise), plan a cell of **fifteen to thirty people** at cruising speed.
Launching a mainframe modernization program as a big-bang. The historical failures of this type of program (service interruption, budget overrun, abandonment) are so frequent that 67 percent of mainframe migration projects fail or significantly drift.
Strangler fig strategy is mandatory. We migrate subsystem by subsystem, the least critical transactions first, the critical transactions last. The mainframe-Azure coexistence lasts several years during the transition. Our ATLAS methodology explicitly frames this incremental progression.
Underestimating the VSAM and DB2 data migration to Azure SQL. Volumes are typically massive (terabytes), EBCDIC binary formats complicate conversions, and integrity rules are not always portable.
Dedicated data migration phase with specialized tools (Azure Database Migration Service, IBM Data Replication, Oracle GoldenGate depending on context). Dual writes mainframe-Azure during the coexistence period to guarantee consistency. Daily parity tests on production volumes with automated reconciliation.
Failing to plan for the reproduction of CICS mechanisms (pseudo-conversational, commarea, temp storage, transient data). The naive microservices pattern does not reproduce CICS semantics.
Cloud architecture with Azure App Service or AKS plus Redis or Azure SQL for distributed state. Commareas become typed DTOs, pseudo-conversational transactions become stateless workflows, temp storages become Redis cache. Migration to Azure Service Bus for asynchronous messaging that replaces mainframe MQ.
Ignoring sectoral regulatory constraints (banking: DORA, ACPR; insurance: Solvency II; administration: security accreditations). A mainframe is often accredited, a cloud environment must be too.
Regulatory scoping phase integrated into the target architecture. Azure is already certified for most European regulations (GDPR, DORA, ISO 27001, SOC 2). Azure sovereign zones (France Central, Germany West Central) meet localization requirements. Progressive transaction-by-transaction accreditation documented in the registry.
Letting mainframe-Azure coexistence drag on indefinitely. Each additional month of coexistence accumulates the costs of both platforms and complicates governance.
Mainframe decommissioning plan dated from the program kickoff. Each migrated transaction triggers the scheduled decommissioning of its mainframe equivalent after a dual run period of three to six months. Target three to five years maximum for total mainframe decommissioning; beyond that, dual maintenance becomes an anti-pattern.
Multi-year program to modernize a COBOL estate on IBM z/OS mainframe, several mission-critical transactional systems running 24/7 in production. Co-delivery with a North American prime contractor. ATLAS strangler fig methodology, signed discrepancy registry for each migrated subsystem.
Three to seven years for a typical large-enterprise estate (one to five million lines of COBOL). The first non-critical transactions can be migrated within the first six to twelve months. Critical transactions (payments, central accounting) come last, generally in years three to five. The mainframe-Azure coexistence lasts the entire duration of the program. The objective is total mainframe decommissioning at the end, not just lightening it.
Yes, this is rehosting on emulator (Micro Focus Enterprise Server, TmaxSoft OpenFrame). The COBOL code runs on Azure VMs. Pros: fast migration, low initial effort, preservation of existing code. Cons: no real modernization (technical debt preserved), dependency on a third-party vendor, often high emulator license costs. We see this approach as a temporary stepping stone useful to quickly exit IBM hardware, but not as a final target. True modernization comes in a second phase with rewriting to Java, .NET Core, or TypeScript.
It is a useful accelerator but not a turnkey solution. Azure Mainframe Migration offers analysis tools, partnerships (Micro Focus, Raincode, Astadia, TmaxSoft), and managed services suited to mainframe workloads. These tools can convert COBOL to Java or .NET automatically, but exiting the mainframe still requires significant characterization, parity audit, and refactoring work. Our ATLAS methodology integrates these tools as accelerators where relevant, without treating them as an end in themselves.
Azure offers native elasticity that the mainframe cannot match at this price point. Month-end peaks are absorbed by AKS or App Service auto-scaling, scaling up automatically and down in lulls. The annual accounting close can be handled by a temporary dedicated cluster. This elasticity generates significant savings compared to a mainframe sized for the peak and underutilized the rest of the time. Typical saving: 30 to 50 percent on TCO over a 3-year horizon after complete modernization.
Typical multi-year budget: ten to sixty million euros depending on estate size (one to ten million lines of COBOL). Nearshore co-delivery via Vivantro can reduce cost by 40 to 60 percent compared to a fully onshore program. Payback typically happens in three to five years after complete mainframe decommissioning. See the delivery models for contractual formats suited to large multi-year programs.
Three major risks: organizational fatigue (teams tire on a long program), change of executive priorities (budget, strategy), target technology obsolescence (target technologies evolve over five years). Mitigations: contractual milestones to validate each step, incremental deliveries with visible business value each year, modular target architecture that can be revised without questioning the foundations. Our experience: programs that deliver visible value each year succeed, those that promise a five-year big-bang drift.
We frame the trajectory, the budget, and the deliverables in a first thirty-minute conversation. A short POC can be proposed before committing to the full program.
Start this path →