Mainframe Modernization: What AI Can Map and What You Must Decide

Key takeaways

• The expensive part of a mainframe program was never the code. It was reading an estate nobody has fully understood in twenty years, and that is the part AI genuinely compresses.
• AI can map the job graph, the copybook usage, the transaction bindings and every reader and writer of every dataset. It cannot choose a path for a workload, and it cannot tell you which differences matter.
• Choose a path per workload, not per estate. Rehost, refactor, coexist and retire can all be correct inside one program.
• Batch windows and shared data decide the order of work more often than business value does.
• The risk AI adds is not bad output. It is a plan that looks finished because the reading went quickly.

Mainframe modernization is the work of moving the applications, data and batch processing that run on a mainframe to a platform the business can change faster, in stages, without stopping the workloads that earn revenue. AI has changed what this costs. It has not changed who is accountable for it.

What are the real options for a mainframe workload?

There are four, and each answers a different question: rehost, refactor, coexist and retire.

Rehost runs the existing programs on emulation or a compatible runtime on another platform. It changes where the code runs and leaves what the code does alone. It is the lowest change to behavior and the smallest gain in flexibility.

Refactor or rewrite moves the logic into a modern language and architecture. It buys the most flexibility and carries the most behavioral risk, because every rule has to be rediscovered and proven. The COBOL side of this choice, including what AI can and cannot do safely with the code itself, is covered in AI-assisted COBOL modernization.

Coexist leaves a workload on the mainframe and builds around it with APIs, events or replicated data. It is often the right answer for stable, high-volume transaction cores.

Retire removes a workload nobody needs. Estates usually contain more of these than the business expects, and finding them is the cheapest saving available. It is also the one disposition AI is genuinely good at proposing, because the evidence is mechanical: no reader, no writer, no scheduled invocation.

What can AI actually map on a mainframe estate?

Everything that is written down, at a speed and consistency people cannot match. Nothing that depends on knowing why.

This distinction decides how a modernization program is staffed and budgeted, so it is worth being concrete rather than directional.

What AI reads well. A model will summarize a 4,000-line program, name its inputs and outputs and describe its branching in minutes. It will build the call graph across thousands of artifacts, classify programs by function, normalize field names that changed three times under three teams, and draft documentation for programs that have none. On a mainframe specifically it will parse JCL into a job dependency graph, resolve copybook usage across the estate, and list every job and transaction that touches a given dataset. This is high-volume, mechanical reading that people do slowly and inconsistently, and the saving is real and large.

What AI drafts, for a human to own. Candidate business rules extracted from the code. Test cases generated from observed behavior. A proposed target design. The first pass of replacement code. All useful, none of it evidence.

What stays with named people. The disposition of each workload. Whether a difference is material. Whether coexistence has run long enough to switch the legacy path off. The cutover decision. These are judgments about risk, cost and what the business will tolerate, and no amount of reading produces them.

There is a specific failure mode here that is worth naming, because it is new and it is quiet. A complete, accurate map of an estate feels like a finished plan. It is not. It tells you what you have, not what to do with it. The US Government Accountability Office reviewed 69 federal legacy systems and found that eight of the eleven most urgent lacked complete modernization plans, and that seven of those eight already had modernization work underway (GAO-25-107795, July 17, 2025). That finding predates AI. What AI changes is how quickly a program can reach that position while appearing to be ahead of schedule.

Which layers does AI have to read, and what can it not tell you?

Four, and a program-level inventory finds none of them.

A distributed application usually keeps its logic in code. A mainframe workload spreads it across layers that only work together, and each one needs its own reading before a path can be chosen.

Read the diagram by column rather than by row. The third column is the one that sets your staffing: every entry in it is a decision that needs a named person with the authority to make it, and the quality of the first two columns does not reduce that list by one.

How do you sequence the work?

Start with the workloads that have the fewest dependencies and the clearest owner, and leave the shared data core for last.

Business value is a poor first sorting key on its own, because the most valuable workload is usually the most entangled. A workable order looks like this:

1. Inventory programs, jobs, transactions, data stores and external interfaces, with an owner for each.
2. Map dependencies, especially shared files and tables and the batch chain.
3. Retire what has no owner or no consumer, after confirming with downstream teams.
4. Move edge workloads with few dependencies first, to prove the pipeline, the tooling and the cutover process.
5. Wrap the core with APIs or replicated data so new products can use it without waiting for it to move.
6. Move the core only when the seam has been stable in production for a period you set in advance.

AI compresses steps 1 and 2 and does almost nothing for steps 3 to 6. That is the single most useful thing to know when planning a mainframe program, because it tells you where the schedule can actually move. Discovery that used to take a quarter can take weeks. The build, the coexistence period and the evidence still take what they took, because they are constrained by calendar time and by how fast a business will accept change, not by how fast anyone can read.

A business case that applies a discovery saving across the whole program will be wrong in the direction that matters. The same sequencing logic applies to packaged platforms as well as custom estates, and GrowExx sets out the ERP version of it in the Oracle EBS to Fusion Cloud migration guide.

Sequencing of this kind usually stalls on access rather than on analysis: the dependency map needs someone inside your environment, with credentials, reading the batch chain as it actually runs. That staffing question is a separate decision, and the guide to forward deployed engineers sets out one way to answer it.

How do you run old and new side by side?

Run both against the same real inputs for a defined period and compare results at the field level before any traffic switches.

Coexistence needs three things in place. A single authoritative source for each data element, so two systems do not each believe they own it. A synchronization method with a stated delay and a stated behavior when it fails. And a switch that can be reversed on a named day.

The proof that the new side is equivalent is a body of evidence: replay of historical inputs including peak periods, output comparison per field, matching error paths, rounding and date behavior at the limits, data reconciliation signed by a business owner, performance inside the batch window, and a parallel run.

AI is useful here in exactly one way, and it is worth having the expectation right. It builds the comparison harness and sorts the diff, classifying thousands of field-level differences into likely harmless and likely real so a person reviews the second group. That saves analysis time. It does not save evidence time. Both systems still have to run, across the periods that stress them, to produce the differences in the first place. The roadmap for legacy application modernization covers how this fits into the wider program.

What goes wrong most often?

Teams underestimate the platform layers and treat the migration as a code conversion.

• Converting code before the batch chain is understood, so the new job misses the window.
• Moving a program but not the data it shares, creating two sources of truth.
• Treating data conversion as a copy, and losing meaning in packed fields or encodings.
• Setting no exit date for coexistence, so two systems run permanently.
• Accepting a vendor’s test results instead of running replay on your own historical data.
• Treating the AI-generated map as the plan. Discovery finishing early is not the program finishing early, and a program that starts building on that basis is the GAO finding happening again with better tooling.

The decision

Let AI read the estate. Take the inventory first, including batch, transactions and data, and let a model do the volume work of mapping the job graph, the copybook usage and the dataset readers and writers. Then assign each workload one of four paths with a named person accountable for each call, sequence from the edges inward, treat coexistence as a designed state with an exit date, and require equivalence evidence on your own historical data before any cutover.

Budget the discovery saving and the evidence cost separately. They move in opposite directions and a single blended estimate hides both.

If you need an outside view of the estate, GrowExx offers application modernization services built on exactly this split, with an independent AI code audit of code you plan to move.

FAQs