Mainframe Migration to Cloud (AWS/Azure/GCP)
Mainframe migration to cloud lands mainframe workloads — COBOL logic, DB2 and VSAM data, CICS transactions, and JCL batch — on AWS, Azure, or Google Cloud, either by emulating the mainframe runtime or by re-architecting into cloud-native services. The durable decisions are about target architecture, data, and batch, not which cloud runs the VMs.
Part 2 laid out seven strategies; six of them end with a workload running somewhere other than z/OS. For most enterprises, that somewhere is a public cloud — AWS, Azure, or Google Cloud. “Move it to the cloud” is an easy sentence and a hard program, because it bundles a dozen real decisions about runtime, data, batch, and integration. This part takes them one at a time, names what the three major clouds actually offer, and is honest about what does and doesn’t differ between them.
Two destinations, not one
The single most important distinction, and the one cloud marketing tends to blur: there are two fundamentally different things people mean by “mainframe migration to cloud.”
Emulated on cloud compute. The first is rehosting (Part 2, strategy 3): an emulation layer runs on cloud virtual machines and reproduces enough of z/OS, CICS, and the data access for the existing COBOL, JCL, and VSAM to run nearly unchanged. You are now off the mainframe hardware and on cloud infrastructure — but the system is architecturally the same. This is fast and it stops the hardware and licensing bleed, but it is relocation, not modernization.
Re-architected into cloud-native services. The second is the re-architect or re-platform path (Part 2, strategies 4 and 6): the COBOL becomes services running in containers or a managed runtime, DB2 and VSAM become managed databases and event stores, and JCL batch becomes orchestrated cloud jobs or streaming pipelines. This is the target architecture modernization exists to reach — and it is genuinely cloud-native, not a mainframe wearing a cloud costume.
Most real programs use both: emulate first to get off the hardware, then re-architect the workloads under pressure slice by slice from there. The honest framing is that the first destination buys time and the second buys a future; deciding how much of each you need is the strategy work, not a cloud-vendor choice.
What the three clouds actually offer
All three major clouds have invested in mainframe migration, and at the level that matters to a buyer they are more alike than different. Rather than fabricate a feature-by-feature comparison, here is the honest shape of it:
- AWS offers a dedicated mainframe migration service and runtime alongside its database, container, and orchestration services, with a large partner ecosystem doing COBOL conversion and rehosting.
- Azure leans on its enterprise and partner relationships, with mainframe migration delivered largely through specialist partners running emulation and conversion on Azure compute and data services.
- Google Cloud provides mainframe modernization tooling and partner-led offerings landing on its compute, database, and data-pipeline services.
The pattern across all three is the same: a cloud runtime for the emulated or recompiled COBOL, managed relational databases as the DB2/VSAM target, container or serverless platforms for re-architected services, and a managed scheduler plus streaming services for batch. The differences are at the margins — specific managed-service shapes, pricing structures, regional and compliance coverage — and they rarely change the architecture.
So which cloud? For most workloads, not the decisive variable. The durable cost and risk drivers — target architecture, data migration, batch redesign, parity validation — are largely cloud-independent. Pick the cloud your organization already has skills, enterprise contracts, and compliance posture for, and spend your decision energy on the architecture. A team that already runs Azure should not relearn AWS to migrate a mainframe; the integration with what you already operate matters more than any migration-tool feature sheet.
Mapping the mainframe onto cloud services
Whatever cloud you choose, the workload decomposes the same way:
| Mainframe element | Cloud-native target |
|---|---|
| COBOL business logic | Domain services in a modern language, in containers or a managed runtime |
| CICS online transactions | API-fronted services behind a gateway, fronted by the strangler facade |
| DB2 relational data | Managed relational database (and event-driven stores where it fits) |
| VSAM indexed files | Relational tables or key-value stores, depending on access pattern |
| JCL batch jobs | Orchestrated jobs on a cloud scheduler, or streaming pipelines |
| 3270 / BMS screens | Modern web or mobile front ends calling the new APIs |
| Batch window | Re-examined entirely — often dissolved by moving to incremental or streaming processing |
That last row is the one teams underestimate. The nightly batch window is not a feature to reproduce in the cloud; it is a constraint born of the mainframe’s economics. Moving to the cloud is the chance to re-question it — much of what runs in the overnight window exists because the mainframe processed in scheduled bulk, and a cloud-native re-architecture can often turn that overnight bulk into continuous, event-driven processing. That is covered in depth in Part 7.
How the migration runs without downtime
The cloud does not change the safety model — the strangler facade and parity validation do that, exactly as they would for any platform. Concretely, on a mainframe-to-cloud move:
- The mainframe stays authoritative. Throughout the migration, z/OS keeps serving production. Nothing about the cutover requires it to stop.
- The modern store is populated and kept in sync. DB2/VSAM data is migrated into the cloud target and continuously reconciled against the mainframe, so the two agree at all times. (Part 6 and Part 8 cover the data side.)
- The modern slice runs in shadow. The facade mirrors live traffic to the cloud-native slice without affecting users; outputs are compared against the mainframe’s. Divergence becomes a ticket, not an outage.
- Traffic shifts gradually. Once parity is proven, the facade moves live traffic to the cloud slice incrementally, with telemetry watched and rollback one flag away.
- The mainframe workload is decommissioned last. Only after the cloud slice has carried live traffic and held parity does the corresponding COBOL retire.
The mechanics are the same ones the parity-validation series details in the zero-downtime cutover playbook; the only mainframe-specific wrinkle is that the data volumes and the batch dependencies make the “keep in sync” step heavier than on a typical application migration.
The integration trap
The part of a cloud migration that surprises teams is rarely the COBOL — it is everything attached to it. A mainframe in a large enterprise is wired into dozens of upstream and downstream systems: file transfers on fixed schedules, message queues, fixed-width data feeds to partners, reports other systems parse. Move the workload to the cloud and every one of those integration points has to be preserved or migrated, often on the original formats, often with the original timing. The migration plan that accounts only for the application and not for its integration surface is the one that slips. Discovery has to map the full perimeter, not just the programs.
When cloud isn’t the right target
Not every mainframe workload belongs in a public cloud, and saying so is part of doing this honestly. Hard regulatory, data-residency, or latency constraints can make a private or hybrid target the right call; a workload with extreme, predictable throughput can be more economical staying on the platform than re-platforming it. ModernLift is stack-agnostic by design — any cloud, public, private, or hybrid — precisely so the target is chosen to fit the workload and the constraints, not to fit a preferred logo. If the honest assessment is that a workload should stay on z/OS or move to a private target, that is the recommendation. The cloud is a means here, not the goal.
Where this leads
Whichever cloud and whichever destination you choose, the same set of hard problems shows up — the undocumented rules, the data integrity bar, the batch window, the scarce skills, the integration perimeter. Naming them squarely is what separates a plan from a wish. Part 4, Mainframe Modernization Challenges, catalogs the challenges that make this work genuinely hard — and, for each one, how an incremental, parity-first approach contains it rather than pretending it away.
Frequently asked questions
- Can you really run COBOL in the cloud?
- Yes, in two distinct ways. You can emulate the mainframe runtime on cloud compute so the existing COBOL, JCL, and VSAM run nearly as-is, or you can recompile or rewrite the COBOL into cloud-native services. The first gets you off the hardware fast and keeps the logic intact; the second is real modernization. Both are routinely done; the choice is the strategy decision from Part 2, not a question of feasibility.
- Which cloud is best for mainframe migration — AWS, Azure, or GCP?
- For most workloads the cloud is not the decisive variable. All three have mature mainframe migration offerings, COBOL runtimes, and partner ecosystems, and the durable cost and risk drivers — target architecture, data migration, batch redesign, parity validation — are largely cloud-independent. Pick the cloud your organization already has skills, contracts, and compliance posture for, and spend the decision energy on the architecture instead.
- How do you migrate mainframe data and batch to the cloud without downtime?
- The data moves under a strangler facade — the modern store is populated and kept in sync while the mainframe stays authoritative, the modern slice runs in shadow against mirrored traffic, and reconciliation proves the two agree before any cutover. Batch is re-expressed on a cloud scheduler or as streaming pipelines and validated against the mainframe's overnight results. Nothing cuts over until parity is proven and rollback is ready.