Mainframe Modernization: Five Paths, the Cost Math, and Why Programs Run Long

Mainframe modernization is the work of moving COBOL and PL/I business logic, its data, and its batch processing off IBM z/OS, or opening it to newer systems where it stays, so the business stops depending on scarce mainframe skills and on software priced by peak capacity. Large programs assign a path to each workload instead of one path for the estate: retain it and expose it through APIs, rehost the COBOL on a mainframe-compatible runtime, convert the code to Java, rewrite the domain, or replace it with a package. Expect a multi-year program whose savings arrive late, because IBM's traditional sub-capacity pricing charges on the peak four-hour rolling average, so the bill drops only when peak-driving workloads leave.

What does a mainframe estate include?

A mainframe application is rarely just COBOL. A typical z/OS estate combines COBOL, PL/I, and assembler programs; CICS or IMS managing online transactions; Db2, IMS databases, and VSAM files holding the data; JCL job streams and a scheduler running the nightly batch; and IBM MQ, file transfers, and 3270 screens connecting it all to the rest of the company. Every layer needs a destination in the plan. The two layers that programs most often underestimate are the batch schedule and the data formats, because both carry business rules that were never written down anywhere else.

These systems also outlive every plan made for them. In its July 2025 review of federal legacy IT, GAO reported that the 11 systems it judged most in need of modernization ranged from about 23 to 60 years old and cost about $754 million a year to operate and maintain, and that eight of the 11 used legacy languages such as COBOL and assembly. Of the 10 critical systems GAO had flagged in 2019, agencies had finished modernizing three by February 2025. Commercial programs rarely face a public audit like that one, and their sponsors should still plan against the same multi-year slippage.

What are the main mainframe modernization options?

Five paths cover almost every workload, and large programs usually run several of them at once. A sixth outcome, retirement, applies to the reports, extracts, and transactions that nobody uses anymore, and a usage review usually finds more of them than their owners expect.

The large cloud providers now package several of these paths. AWS, for example, describes two mainframe routes: refactoring applications to languages such as Java with AWS Transform for mainframe, and replatforming with minimal code changes through AWS Mainframe Modernization with Rocket Software. Tooling shortens the code conversion step. Extracting business rules, converting data, and proving that the new system behaves like the old one still take most of the schedule, so those three activities deserve most of the planning attention.

How do you choose a path for each workload?

Choose workload by workload, and answer four questions for each one before anyone debates tools.

1. How often does the business change this code? A pricing or eligibility module that changes every month argues for a rewrite, while a settlement batch that has not changed in five years argues for retaining or rehosting it.
2. How tangled is the data? Programs that share the same VSAM files or Db2 tables have to move together, so the real unit of planning is a move group defined by its data dependencies.
3. Is the function a commodity? General ledger, payroll, and HR rarely justify custom code in any language, which points toward replacement and a build vs buy decision with a five-year cost on both sides.
4. Who will maintain the result? Converted Java that keeps COBOL's paragraph structure and fixed-length record layouts is cheap to produce and expensive to own if your developers cannot work in it.

For rewrites, the default method is the strangler fig approach. Teams route one capability at a time to new code, leave everything else on the mainframe, and retire mainframe code as each capability moves. Martin Fowler, who first described the pattern in 2004, writes in his current description of it that the all-at-once replacement plan goes "down in flames most of the time." He also names the price of the gradual route: transitional architecture, meaning code that lets the old and new systems coexist and that the team discards once the modernization is complete. Budget for that code from the start.

What does mainframe modernization cost, and when do the savings arrive?

Program cost depends on the volume and condition of the code, the number of batch jobs and interfaces, the data formats, and above all the depth of testing the business requires before it accepts the new system. BD Emerson planning range: 12 to 24 months to take one large application domain from assessment through parallel run, and three to five years or more to exit a large estate completely. Programs that skip the assessment usually discover their real scope during testing, which is the most expensive place to find it.

The run-cost side is where business cases go wrong. Most assume the mainframe bill falls in proportion to the work moved off the platform. Under IBM's traditional sub-capacity pricing it does not, because IBM's planning guide for sub-capacity pricing bases charges on the highest observed four-hour rolling average of processor consumption, calculated every hour for each logical partition (LPAR) across the month. Consumption is measured in MSUs (millions of service units), IBM's unit of processor capacity. Moving a workload that runs outside the peak window saves little on those products. Moving the workloads that create the peak, often the overnight batch or the month-end cycle, lowers the bill, and shutting down an LPAR removes its share entirely.

Other costs fall later still. Hardware leases, independent software vendor contracts priced on machine capacity, data center space, and the operations team stay fixed until the platform is gone or a contract renews. Sequence the waves so that peak-driving workloads move early and the final exit lands on a hardware or contract renewal date, and carry the cost of running both systems during parallel runs in the business case. Contracts under other IBM pricing models, such as Tailored Fit Pricing, follow different rules, so model the bill from your own contract and your own usage data.

Where do mainframe modernization programs stall?

Data conversion is the first place. Mainframe character data is encoded in EBCDIC, numeric fields are often stored as packed decimal (COMP-3), and COBOL copybooks use REDEFINES clauses so that one layout can hold several record types. A conversion that treats every byte as text corrupts the numbers. Google Cloud's mainframe modernization documentation assigns a dedicated tool, Mainframe Connector, to migrating and converting data from mainframe-specific formats such as EBCDIC, and every plan should give that conversion a workstream of its own.

Batch is the second. A nightly cycle can run thousands of jobs whose order, restart points, and file handoffs live in JCL and scheduler definitions, and downstream teams expect their files at set times. Hidden integrations are the third: MQ queues, partner file transfers, and screen-scraping tools built against 3270 screens rarely appear in any architecture diagram.

Proving equivalence is the fourth and the longest. The new system has to produce the same balances, notices, and files as the old one across daily, month-end, and year-end cycles. Parallel running is the standard proof, and vendors now build tooling for it: Google Cloud describes its Dual Run product as running workloads on the mainframe and Google Cloud simultaneously to check consistency and functional validation. Whatever the tooling, the business has to own the acceptance criteria and sign off on every difference the comparison finds.

People are the fifth constraint. GAO's 2025 report found that a shortage of expert personnel available to maintain a critical system creates significant risk to an agency's mission, and the same shortage limits how fast any company can extract rules from code whose authors left years ago. Pair the remaining COBOL experts with the engineers who will own the new system, and record each business rule they explain as an automated test.

How should a mainframe modernization program be structured?

Start with an assessment built on evidence from the code and the usage logs. Inventory every program, copybook, JCL member, dataset, and transaction; build the call and data dependency graphs from the code itself; and attribute MSU consumption to workloads from System Management Facilities (SMF) records, the usage logs z/OS writes. Add the contract map: renewal dates, notice periods, and capacity terms for IBM and every independent software vendor. BD Emerson planning range for this phase: 8 to 12 weeks for a large estate.

Then prove the method on one domain of moderate complexity, carried all the way through data conversion, parallel run, and the shutdown of the mainframe code it replaced. The pilot calibrates the estimate for every later wave. After it, sequence waves by data dependencies and by the economics above, so that peak-driving workloads and whole LPARs leave early and the final exit lands on a contract date. Keep one rule throughout: a wave counts as finished only when the old code is switched off.

Distributed applications that feed the mainframe usually modernize on their own track, and the sequence in our legacy application modernization guide applies to them.

BD Emerson's engineers run the mainframe assessment, build the workload-by-workload plan and the cost model behind it, and deliver the conversion, data migration, and parallel-run testing for the paths you choose. To see how an engagement starts, visit our application modernization services page.