Mainframe ↔ Azure architect
Bridge between z/OS, CICS, DB2 and the Azure ecosystem, strangler fig coexistence design, per-subsystem trajectory arbitration
Loading...
Loading...
Modernization of IBM z/OS mainframe applications to Microsoft Azure, using the strangler fig strategy and the ATLAS methodology.
Each phase aggregates one or more of the ten ATLAS steps. No phase starts until the previous one has delivered its validated artefact. The ATLAS methodology makes AS/400 migration predictable and auditable.
Estate extraction via Azure Mainframe Migration, IBM ADDI, or dedicated tools. Classify each program by frequency, criticality, and dependencies. Full mapping: COBOL, CICS, JCL, copybooks, DB2/VSAM.
Per-subsystem trajectory arbitration (emulator rehost, replatform, cloud-native refactor). Azure architecture: AKS, App Service, Azure SQL, Service Bus, Functions. Regulatory scoping (DORA, Solvency II, accreditations) and sovereign zones. FinOps strategy.
Characterization tests written upstream on the mainframe. Pattern-by-pattern migration: COPY → classes, PERFORM → methods, PIC S9(n)V9(n) → BigDecimal, CICS → REST microservices. Azure infrastructure build via Bicep/Terraform.
Parallel runs mainframe / Azure with automatic output comparison. Per-subsystem parity audit, internal classified discrepancy registry. Coexistence behind an API facade, dual writes DB2 → Azure SQL via Database Migration Service.
Per-subsystem transactional cutover, mainframe decommissioning planned after parity validation. Coexistence bounded by a dated exit plan. Continuous FinOps monitoring, ops handover to client team with runbooks.
Automatic legacy-code conversion tools produce code that compiles but stays unreadable and unmaintainable: original patterns are copied as-is, without idiomatization, with dependencies on a proprietary runtime. Pushed to production without full re-characterization, this code is neither reliable nor scalable. End-to-end automatic translation isn't a modernization method — it's a debt transfer.
Our approach is the opposite. ATLAS relies on multiple readings of the legacy code, from several angles: data flows, business rules, dependencies, edge cases. AI comes in as a comprehension accelerator — to decipher decades of accumulated business logic, reverse-document uncommented branches, surface the intent behind the code. It doesn't decide and it doesn't translate: it informs the architect's work, who then designs the target architecture (cloud, database, services) and drives the migration pattern by pattern, under parity audit.
This understanding still requires humans who know legacy languages. That's our edge: where Europe and North America face a retirement wave among mainframe and legacy developers, Tunisia retains a pool of experienced developers (COBOL, Delphi, PowerBuilder, RPG…). Paired with modern architects and developers trained in the ATLAS method, they ensure continuity between the original business intent and the target system.
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.
Microsoft ecosystem at all levels, pooling of C# skills. See COBOL to .NET Core.
AWS ecosystem dominant. See 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 as a sequence of functional waves, with the cadence set at scoping based on volume and criticality. The typical cell starts with a senior mainframe-cloud architect, an Azure tech lead, COBOL-Java/.NET developers, a DB2-SQL Server DBA, a cloud network engineer, a QA specialized in parity tests, and a delivery director. Composition and headcount are not fixed upfront: they are determined after the POC and scoping, once the real work has been measured; a large-enterprise mainframe estate is modernized in several waves spread over time.
Launching a mainframe modernization program as a big-bang. Failures of this kind of program — service interruption, budget overrun, abandonment — are frequent: Gartner forecasts that more than 70% of mainframe exit projects launched in 2026 will fail to deliver the intended benefits, notably from overestimating generative-AI tooling.
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.
Several distinct profiles, mobilized over the full program duration. Reproducing this cell internally is rarely realistic — the legacy skills shortage and ATLAS expertise depth make outsourcing structurally faster and less risky.
Bridge between z/OS, CICS, DB2 and the Azure ecosystem, strangler fig coexistence design, per-subsystem trajectory arbitration
Azure Mainframe Migration, AKS, App Service, Azure SQL, Service Bus, Functions, Azure Monitor observability
Translation patterns PIC/COMP-3 → BigDecimal, CICS → REST, JCL → orchestration, ideally with a COBOL background
Infrastructure as Code (Bicep, Terraform), CI/CD Azure DevOps, Entra ID security, VNet networking
Migration via Azure Database Migration Service, DB2 schema mapping, dual writes, data parity audit
Characterization test bench, automated parallel runs, classified discrepancy registry
Monthly per-subsystem estimate, regulatory scoping (DORA, Solvency II, accreditations), Azure sovereign zones
Functional waves leadership, program governance, dated mainframe decommissioning plan
Internal POCs validating the transformation patterns from mainframe (COBOL, JCL, CICS, VSAM, DB2) to cloud target stacks (.NET Core or Java on Azure AKS, Azure SQL, Azure Service Bus). Strangler fig approach applied on representative scopes.
Modernization is delivered in successive functional waves rather than on a monolithic plan: the cadence is set at scoping based on volume and criticality. Non-critical transactions are migrated first, critical transactions (payments, central accounting) last. 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: three to forty million euros depending on estate size (one to ten million lines of COBOL), in line with 2026 market benchmarks ($3M-$45M typical range for mainframe → cloud migration). Quality nearshore co-delivery can reduce cost by 30 to 50 percent compared to a fully onshore program. TCO reduction observed is 30 to 50 percent over three years (established market figure, public cases: Infosys insurance NA 60%, Deloitte insurer EU 80%). Payback typically happens in two to three 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.
It depends on the migration strategy and the scope. Three trajectories with very different cost profiles: lift-and-shift (rehost on Azure VMs running emulators) is cheapest in the short term — 3-6 months and a few hundred thousand euros — but preserves all the legacy debt. Replatform (move to Azure SQL, App Service, Container Apps, keep most of the code) runs 6-18 months and €1-5M. Refactor (modernize to cloud-native microservices in Java or .NET on AKS, with the ATLAS methodology) is the most expensive upfront — 12-36 months and €3-15M for typical mainframe estates — but pays back the fastest because it eliminates licensing and unlocks evolution. Most clients combine the three: lift-and-shift for non-critical systems, refactor for the strategic core. See the IBM mainframe to Azure journey.
Three concrete ways to start — from an Azure Mainframe Migration POC to a full multi-year program. Our approach is incremental, strangler-fig based, with a internal classified discrepancy registry and a dated decommissioning plan.