Why Most Mainframe Migration Plans Fall Apart Before They Start

A few years back, a large regional insurer came to us with a familiar story. They’d kicked off a mainframe migration to cloud eighteen months earlier, spent roughly $4M, and were no closer to decommissioning a single LPAR. Their assessment phase had identified 47 COBOL applications. Nobody had actually read the JCL. The so-called “migration plan” was a PowerPoint built on vendor promises, not on what the workloads actually did at 2 a.m. on a Tuesday when batch jobs ran.

That’s the pattern. Not a lack of ambition — a lack of specificity. This article is meant to give IT directors and CIOs a map that reflects real conditions: the technical debt, the organizational friction, the AWS tooling that actually works, and the decisions that separate migrations that ship from ones that stall indefinitely.

We’ll focus heavily on AWS because that’s where the most mature tooling for migration from mainframe to cloud currently lives, and because the AWS Mainframe Modernization service has matured enough to carry production workloads — though it still has real constraints worth naming honestly.

Understanding What You’re Actually Moving

Before any tooling conversation, you need a hard inventory. Not a CMDB export — an actual workload characterization. The distinction matters because migration complexity scales not with lines of code, but with the depth of platform dependency.

Here’s what we mean by that. A COBOL batch application that reads flat files and writes to a VSAM KSDS cluster is a fundamentally different problem from a CICS transaction that calls DB2 stored procedures, uses MQ Series for async messaging, and expects EBCDIC-encoded data from an upstream IMS system. Both might be labeled “legacy COBOL app” in your asset register. The migration effort is an order of magnitude different.

Run a proper dependency map first. Tools like Micro Focus Enterprise Analyzer (now part of OpenText) and IBM Application Discovery and Delivery Intelligence (ADDI) can parse COBOL, PL/I, and Assembler to build call graphs and data flow diagrams. These aren’t perfect — they’ll still miss runtime-injected program names in some CICS environments — but they get you 70–80% of the picture you need before scoping work.

For data, catalog your VSAM file types explicitly: KSDS, ESDS, RRDS. The migration paths differ. KSDS maps most cleanly to DynamoDB or RDS with keyed access. ESDS sequential files often convert well to S3 with Athena on top. RRDS is rare but nasty to migrate — relative record addressing doesn’t map naturally to any AWS storage primitive without middleware.

The AWS Mainframe Modernization Service: What It Actually Does

AWS Mainframe Modernization (M2) — launched at re:Invent 2021 and significantly expanded since — provides two distinct runtime environments: one powered by Micro Focus Enterprise Server (rebranded as Broadcom after the acquisition), and one powered by BluAge, which does automated code conversion from COBOL/PL/I to Java or .NET.

This is worth stating plainly, because a lot of vendors blur the distinction. These are not interchangeable paths.

The Replatforming Path (Micro Focus / Broadcom Runtime)

The Micro Focus runtime inside AWS M2 lets you run your existing COBOL and PL/I code on managed EC2 infrastructure, with AWS handling patching, scaling, and high availability. Your JCL runs. Your VSAM files convert to cached file structures on the managed filesystem. CICS transactions run in a compatible environment. The application doesn’t change.

This is a lift-and-shift in the truest sense — and that’s not an insult. For workloads where speed of migration matters more than code modernization, this path can move a batch system to AWS M2 in weeks rather than years. We’ve seen production deployments in 90 days for mid-complexity batch portfolios.

The cost trade-off: you’re still running COBOL. Developer scarcity doesn’t improve. You’ve removed hardware dependency but not skill dependency.

The Refactoring Path (BluAge)

BluAge does automated source code conversion. It parses your COBOL or PL/I, generates Java or .NET equivalents, and produces code that runs as a modern application on AWS. The output is genuinely readable Java — not machine-generated spaghetti — though it’s idiomatic BluAge Java, which means your Java engineers will need time to understand its patterns.

What nobody tells you upfront: automated conversion handles the structural translation, but it will not resolve business logic errors embedded in the original code. If your COBOL packed decimal arithmetic had a rounding bug in 1987, the generated Java will have it too. Plan for 25–40% of converted code to require manual review and correction — that estimate is consistent with what we observe in engagements, and aligns with findings published in AWS Partner network case studies.

BluAge also doesn’t handle every COBOL dialect equally. Code that depends heavily on vendor-specific extensions — Unisys MCP COBOL, for instance — will need more pre-processing before BluAge can ingest it cleanly.

A Phased Migration Approach That Reflects Real Constraints

The cleanest framework I’ve seen applied to mainframe migration to cloud at scale is a modified version of the AWS Migration Acceleration Program (MAP) methodology, adapted specifically for mainframe contexts. Here’s how the phases actually play out in practice:

Phase 1: Assess (6–12 weeks)

Characterize every workload. Not just what it does, but when it runs, what SLAs it carries, what happens if it fails, and who actually understands it. That last question is uncomfortable — but at most enterprises, the people who built these systems retired years ago, and the institutional knowledge lives in tribal memory and undocumented runbooks. Surface that now, not during cutover.

Produce a migration wave plan grouped by coupling, not by business unit. Applications that share VSAM files or call each other need to move together. Organizational ownership is secondary to technical dependency.

Phase 2: Mobilize (8–16 weeks)

Stand up your target environment on AWS. Configure AWS M2 runtime environments. Establish CI/CD pipelines for whatever code conversion or replatforming approach you’re using. Set up AWS Database Migration Service (DMS) for any relational data migration from DB2 or IMS. Get your monitoring stack — CloudWatch, plus something like Dynatrace or Datadog for application-layer observability — configured before you migrate the first workload.

This phase is where most programs underinvest. They treat it as an IT setup task rather than a foundation decision. The observability choices you make here will define how quickly you can diagnose production incidents post-migration.

Phase 3: Migrate and Modernize (ongoing waves)

Run pilot waves with low-risk, low-coupling workloads. Not because they’re easy — they’re not, necessarily — but because failures here are recoverable. Use pilots to calibrate your conversion tooling, validate your VSAM migration approach, and test your runbook quality before you touch anything that touches revenue.

Each wave should have a defined rollback plan. For replatformed workloads on AWS M2, rollback is straightforward — the mainframe is still running. For refactored workloads where BluAge has generated new code, rollback requires keeping the mainframe in sync during parallel run periods. That parallel run period costs money. Budget it explicitly.

Data on Migration Timelines and Costs

Organizations often underestimate the time and budget required. The table below draws from published industry benchmarks, including data from Gartner’s 2023 infrastructure and operations research and AWS published case studies.

Gartner has consistently found that mainframe TCO comparisons favor cloud migration only when the full software licensing cost — particularly IBM MLC (Monthly License Charge) — is factored in. Organizations that migrate compute but retain mainframe licensing for data access often fail to realize projected savings. Gartner’s mainframe research recommends a full workload exit, not a hybrid that keeps MLC costs running.

The Blockers Nobody Puts in the Project Plan

Technical debt is visible. Organizational debt is invisible until it stops a program dead. Here are the blockers we see most consistently — and none of them appear on a Gantt chart until it’s too late.

• COBOL skill shortage on the migration team itself. You need people who can read the original code to validate what the automated tools produce. There are roughly 800,000 COBOL developers globally per a 2022 Micro Focus survey — but most work in maintenance roles, not migration projects. Budget time to recruit or train before you start.
• Mainframe operations teams resisting decommission. This sounds political but it’s also rational: the people who run the mainframe have built careers around it. The migration plan needs a people strategy, not just a technical one. Reskilling programs tied to specific AWS certifications help — AWS has published a dedicated mainframe modernization learning path through AWS Skill Builder.
• Undocumented file formats. EBCDIC encoding, packed decimal fields, and bit-level data structures in VSAM files often aren’t documented anywhere. They’re embedded in the COBOL copybooks, which may themselves reference copybooks that no longer exist. The AWS Schema Conversion Tool handles some of this, but not all of it. Plan for manual reverse engineering of at least some file layouts.
• Integration sprawl downstream. The mainframe likely feeds dozens of downstream systems via flat file drops, MQ messages, or direct DB2 access. Many of those downstream teams don’t know they’re dependent on the mainframe until you tell them you’re migrating it. Map these dependencies early — and treat downstream teams as stakeholders, not afterthoughts.

Honest Advice on Choosing Between Replatform and Refactor

Most AWS partner materials will tell you to evaluate both options and choose based on your goals. That’s true but incomplete. Here’s a sharper take based on what we’ve observed in actual engagements.

If your primary goal is hardware decommission and cost reduction from IBM licensing, replatforming via the Micro Focus runtime on AWS M2 gets you there faster with less risk. You’re not modernizing the codebase — but you’re off the mainframe iron, which is often the budget driver.

If your goal is long-term developer productivity, codebase maintainability, and removing the COBOL skill dependency entirely, refactoring via BluAge or a manual rewrite is the right call — even though it takes longer and costs more upfront. The ten-year TCO difference is substantial. A Java application running on ECS or Lambda can be maintained by any competent Java developer. A replatformed COBOL application still requires COBOL expertise forever.

The worst outcome is choosing based on what the vendor’s demo looked like. Both paths have production-proven deployments. Pick based on your actual constraint — timeline, budget, or long-term maintainability — and commit to it. Programs that try to hedge by doing both in parallel without clear criteria end up doing neither well.

FAQ

What is the AWS Mainframe Modernization service and who should use it?

The AWS Mainframe Modernization service is a managed platform that lets enterprises run, convert, or refactor mainframe workloads on AWS infrastructure. It supports two paths: replatforming (running existing COBOL/PL/I code via the Broadcom/Micro Focus runtime) and refactoring (automated code conversion to Java or .NET via BluAge). It’s best suited to organizations running IBM Z-series or compatible mainframes with COBOL, PL/I, CICS, or JCL-based batch workloads. Organizations running Unisys or Bull mainframes will need additional pre-processing before the service applies cleanly.

How long does a typical migration from mainframe to cloud actually take?

Honestly? Longer than most initial estimates. A focused replatforming project for a small portfolio of batch applications can complete in 6–12 months. A full enterprise-scale mainframe migration to cloud covering complex CICS transaction systems, IMS databases, and large VSAM footprints typically runs 3–5 years across multiple delivery waves. The biggest schedule risks are undocumented file formats, downstream integration complexity, and organizational change management — not the technical migration itself.

Can you run mainframe workloads on AWS without converting the COBOL code?

Yes — this is exactly what the replatforming path in AWS Mainframe Modernization enables. Your COBOL and PL/I code runs as-is within a managed COBOL runtime environment on AWS EC2. JCL batch execution, VSAM file access, and CICS transaction processing are all supported. The mainframe hardware dependency is removed, but the source code stays unchanged. This is a valid long-term architecture for organizations where the COBOL codebase is stable and the primary goal is infrastructure cost reduction rather than code modernization.