AI for COBOL Modernization

Every part of this series so far has pointed at the same bottleneck: understanding what the COBOL actually does. The footprint is enormous (Part 2), the experts who hold the knowledge are leaving (Part 3), and the central task is recovering undocumented business rules (Part 7). Discovery — reading the code and writing down its behavior — has always been the slow, expensive, expert-dependent phase that makes COBOL migrations long. This part is about the one place AI changes the economics decisively, and the places where claiming more than that would be dishonest and dangerous.

The bottleneck AI actually removes

The slowest step in any serious COBOL migration is not writing the new code. It is figuring out what the old code does. Reverse-engineering an estate — the call graph, the batch dependencies, the data flows, the buried rules — has historically meant scarce specialists reading hundreds of thousands of lines by hand, one program at a time, racing the retirement clock from Part 3.

This is precisely the work AI-accelerated discovery transforms. It can deep-read the COBOL, the copybooks, the JCL, and the data schema together — as one connected system rather than file by file — and draft the artifacts that discovery used to produce by hand:

• the call graph and program interdependencies;
• the batch job dependencies and sequencing;
• the data flows across programs, copybooks, and stores;
• the candidate business rules and edge cases embedded in the logic.

The claim worth stating precisely, because precision is the whole point of a credible AI story: this is an analysis-time gain, on the order of 10× faster than manual review — taking a discovery pass that ran twelve weeks down toward about two. It compresses the slowest, most knowledge-dependent phase, and it captures what the retiring experts know before they leave. That is a real, large, specific benefit. It is also a narrower claim than “AI does the migration,” and the narrowness is deliberate.

What AI does not do — and why honesty here matters

It would be easy, and dishonest, to extend the story into “AI migrates COBOL automatically.” It does not, and treating it as if it does is how AI-assisted migrations go wrong. Three things stay firmly outside what the tooling delivers:

AI does not certify correctness. A drafted business rule is a candidate, not a fact. AI can read a program and propose that it rounds a certain way; whether that rounding is a deliberate rule, a bug the business has come to depend on, or dead code is a judgment that requires a human who understands the domain. The discovery output is a fast, comprehensive first draft for senior engineers and remaining experts to verify — not a finished specification to build on blindly.

AI does not make a cutover safe. This is the most important boundary in the whole series. No amount of analysis, however fast or thorough, proves that the migrated system behaves like the original. Only running the modern slice against the live system and comparing outputs does that — parity validation. AI changes how quickly you understand the COBOL; it changes nothing about the obligation to prove the new system matches it. A migration accelerated by AI and not validated by parity is faster and just as unsafe as one done by hand and not validated.

AI does not own the architecture. The decisions that determine whether a migration succeeds — how to slice the estate, what the target architecture should be, which programs to convert versus rewrite versus replace (Part 4) — are senior-engineering judgment calls. AI informs them with better, faster analysis; it does not make them.

The reason to be this careful is not modesty for its own sake. It is that on a system running money, an overclaimed AI tool is a liability — it invites teams to trust output that has not been verified and to skip gates that exist for good reason. An honest account of what AI does is also the safe one.

How the pieces fit together

The right mental model is a division of labor, not a handoff to a machine:

• AI accelerates the reading and the drafting — the discovery phase, compressed roughly tenfold.
• Senior engineers own the judgment — verifying rules, designing the architecture, choosing the slicing and the per-program strategy.
• Parity validation owns the proof — the modern slice runs in the shadow of the COBOL, on mirrored production data, and is proven to behave identically before any traffic moves (Part 8).

A useful way to hold it: knowledge without rollout is a report; rollout without parity is a gamble. AI makes the knowledge cheap and fast. It does not let you skip the rollout discipline or the parity gate — and a vendor implying otherwise is selling the dangerous version of this story.

Where this leaves the talent problem

There is a satisfying alignment between what AI does well and what the COBOL world most needs. The scarce resource is expert understanding of undocumented systems, and that scarcity is getting worse on a schedule. AI-accelerated discovery is, at its core, a way to extract and preserve that understanding faster than the experts are leaving — to turn the contents of a few retiring heads into reviewable specifications while there is still time to validate them. It does not replace the experts; it amplifies the ones who remain and captures the knowledge of the ones about to go. Against the workforce clock from Part 3, that is the most valuable thing it could do.

Where this leads

AI changes what discovery costs and how fast it runs — which changes the overall economics of a COBOL migration without changing its safety requirements. That naturally raises the question every economic buyer asks: with discovery accelerated and the work done incrementally, what does a COBOL modernization actually cost, how long does it take, and what tools are involved? Part 10, COBOL Modernization Cost, Timeline & Tools, closes the series with the honest economics — the cost drivers, the timeline shape of incremental delivery, and how to read the COBOL modernization tool landscape.