AI-assisted COBOL modernization is the use of large language models to read, summarize, and help rewrite a COBOL estate: understanding what the code does, pulling out the rules buried in it, and drafting replacements. AI lowers the cost of comprehension. It does not lower the burden of proving the replacement behaves identically.
Key takeaways
- The expensive part of a COBOL program was never typing the new code. It was working out what the old code does, including the behavior nobody documented and the behavior nobody intended.
- AI is good at comprehension work: summarizing, mapping and spotting patterns across thousands of artifacts. That saving is real and large. It is not the same as safe translation.
- A direct COBOL-to-Java conversion carries the original architecture across. You get the same design in a language your team can hire for, and the constraints that made the system hard to change are still there.
- The gate is equivalence evidence, not code review. If you cannot show that the replacement produces identical output on real historical inputs, you do not have a modernized system. You have a second system.
- The failure AI adds is not bad code. It is a plan that looks finished because the comprehension phase went quickly.
The scale of the problem is documented. The US Government Accountability Office reviewed 69 federal legacy systems and picked eleven as most in need of modernization (GAO-25-107795, July 17, 2025). Those eleven range from about 23 to 60 years old and cost about $754 million a year to operate and maintain. Eight use outdated languages, and both Treasury systems in the set run on COBOL and Assembly.
One finding deserves more attention than it gets, because it describes the risk AI makes worse: eight of the eleven lack complete modernization plans, and seven of those eight already have modernizations underway. Work had started without a documented plan for the legacy system. Anything that makes starting cheaper makes starting without a plan more likely.
What is AI-assisted COBOL modernization?
It is the use of language models in the comprehension and drafting stages of a modernization program. It is not an end-to-end conversion service.
A COBOL program has roughly five stages: inventory the estate, understand what each program does, decide what happens to each one, build the replacement, and prove the replacement is equivalent before cutover. AI is strong in stages two and four and helps in stage one. It is weakest where the risk concentrates, in stages three and five, which are judgment and evidence rather than text processing.
The public argument is worth knowing because your stakeholders have read it. Anthropic publishes The Code Modernization Playbook, an eBook whose landing page names analyzing complex codebases, generating test suites and preserving business logic during migrations as things agentic coding tools can help with. Thoughtworks’ Alessio Ferri and Shodhan Sheth replied on March 2, 2026 in Claude Code and COBOL modernization: What’s the reality? They argue the framing oversimplifies the work. In their view the value is in reducing the mental load of reading large volumes of legacy artifacts, not in making unreadable code readable, since COBOL “was deliberately designed to be readable.”
Both are worth reading in full, and they are closer than the framing suggests. They disagree about where the saving comes from, not about whether a human has to own the result.
What does AI do well on a COBOL estate?
It handles the comprehension work, and that is a larger share of program cost than most business cases assume.
Three things in the top band are worth stating concretely, because that is where the measurable saving sits.
Reading programs nobody has read in twenty years. A model will summarize a 4,000-line program, name its inputs and outputs and describe its branching in minutes. The summary does not have to be perfect. A senior engineer can correct a draft far faster than they can write one from nothing.
Building the dependency map. Which programs call which, which copybooks are shared, which files are written by more than one job. This is mechanical, high-volume work that people do slowly and inconsistently. Thoughtworks is specific about the limit: models cannot reliably take in “tens of millions of lines” at once, so the mapping depends on outside analysis tools, repeated summarization and human prompting rather than one pass over the estate.
Normalizing decades of convention. Field names, record layouts and job names that changed three times under three teams. Pattern detection across mixed artifacts is a real strength.
None of this produces a decision. A complete, accurate map of an estate tells you what you have. It does not tell you what to do with it, and the GAO finding above is what happens when a program treats the first as the second.
What can AI not do safely?
Anything where being confidently wrong looks the same as being right until a customer or an auditor finds out.
Four limits, stated as design constraints rather than model complaints.
Rule completeness. A model can extract the rules it can see. It cannot tell you about a rule that exists only because a 1997 patch suppressed a condition, or which extracted rules the business has quietly stopped wanting. Thoughtworks makes the same point from the other side: much of the relevant knowledge sits in stakeholders’ heads, so every mainframe program needs strong involvement from subject matter experts. A rule missing from AI output is not evidence that the rule does not exist.
Correctness and drift. The Thoughtworks authors name correctness and drift as the weaker dimensions in their assessment. Correctness covers hallucination and missed context. Drift covers variation when the same task is repeated. Teams underestimate drift. If running the same extraction twice gives two different rule sets, neither run is evidence, and you will not notice unless you run it twice.
Materiality. Which differences matter. A one-cent rounding difference on an interest calculation is either a defect or a rounding change that finance signed off on, and nothing in the code says which.
Disposition. Whether a program should be rewritten, wrapped, retired or left alone is a business decision about risk, cost and strategy. It is also the highest-impact decision in the program and the one most likely to be skipped when comprehension came in under budget.
Why is a direct COBOL-to-Java translation the wrong default?
It moves the architecture along with the code, and the architecture is usually the real problem.
A line-by-line conversion gives you the same data model, the same batch-shaped control flow, the same assumptions about file access and the same coupling between modules, now in a language you can hire for. That benefit is real and often undersold. Leaving a language with a shrinking talent pool has value on its own. But choose it on purpose. Do not arrive at it because conversion is what the tooling does well.
Thoughtworks puts it directly: direct translation reproduces existing architectural constraints and technical debt. A converted system is often harder to change than the COBOL was, because the original design intent is now hidden behind a translation layer and the people who understood it have retired.
Settle what the modernization is for before any conversion starts. “We cannot hire COBOL programmers” and “we cannot ship a change in under nine months” are different problems with different answers, and only the first is solved by translation. The framework for choosing between retain, rehost, re-platform, refactor, rearchitect and replace is in the legacy application modernization roadmap. Choosing between them is out of scope here.
How do you prove the new system does what the old one did?
With equivalence evidence produced from real historical inputs, agreed before the work starts and gathered as it proceeds.
AI does not shorten this part, and treating it as a formality is how modernizations fail in public instead of in private. There are seven checks, and each one names the condition that stops a cutover. A check that cannot fail is not a check.
Three of the seven get cut when the schedule tightens, for the same reason: they cost calendar time rather than effort.
Replay on real historical inputs. Not synthetic data and not a clean recent period. The value is in the months with the oddities: the year-end run, the leap day, the correction batch, the entity acquired mid-period. A replay set drawn from a quiet quarter proves only the easy cases.
Field-level output comparison. Two files that balance to the same total can differ on every line. Compare per field, and have someone who can say which differences are acceptable set the tolerances in advance.
Data reconciliation. Reconcile totals a business owner already trusts, such as period-end balances, and have that owner sign the result. This is the one check that finance or operations performs rather than engineering, and it catches the class of difference that is arithmetically consistent and still wrong. It is also the check most often assumed rather than scheduled, because it needs a person outside the delivery team to make time for it.
A dual run. Both systems process live volume in parallel, and you investigate differences instead of counting them. Thoughtworks names a dual run before cutover as part of the forward-engineering path. It is also the only check that tests the new system against inputs nobody expected.
AI helps here by building the comparison harness and sorting the diff, classifying thousands of field-level differences into likely harmless and likely real so a person reviews the second group. That is a large saving. It saves analysis time, not evidence time. Both systems still have to run to produce the differences.
What has to be true before AI touches the code?
Five preconditions. A program that cannot meet them is not ready, whatever the tooling.
| Precondition | Why | What stops you without it |
|---|---|---|
| A complete estate inventory | You cannot scope what you have not listed, and COBOL estates reliably hold programs nobody lists | Scope grows mid-program, usually after the budget is fixed |
| Historical input data you are allowed to use | Equivalence testing needs real records, which means a data-handling decision before the work, not during it | The replay set becomes synthetic and proves nothing |
| A named business owner per program domain | Rule completeness, materiality and the reconciliation signature are their calls, not the model’s | Extracted rules get accepted because nobody is accountable for rejecting them |
| A documented plan for each program | GAO found seven systems being modernized without one | You find out mid-build that the legacy system is never switched off |
| A pinned model and recorded prompts | Drift makes an unrepeatable extraction useless as evidence | You cannot reproduce the analysis your decision rested on |
The fifth is the new one and the one most often missed. If the rule extraction behind a design decision cannot be rerun and reproduced six months later, the audit trail for that decision is a conversation.
Who signs off, and on what?
Three named people, on three different things. None of them is the engineering lead alone.
- The business owner for the domain signs off that the extracted rules are complete and current, including which rules to drop instead of carry forward, and signs the data reconciliation. This signature closes the gap in unwritten knowledge. It cannot go to whoever wrote the extraction prompt.
- The engineering owner signs off on equivalence evidence: replay coverage, field-level comparison results, dual-run differences and how each was resolved.
- The accountable executive signs off on cutover and on what happens to the legacy system, specifically the date it is switched off and who owns it until then.
A modernization where all three signatures belong to one function has no independent check. With AI-assisted work the separation matters more, because the volume of output makes informal review impossible. Nobody reads 4,000 generated test cases, so someone has to answer for the sample that was read and the basis for accepting the rest. The same reasoning applies to AI-generated code in general. GrowExx sets out its position on reviewing it in AI code review versus a human expert and the true cost of shipping unreviewed AI-generated code.
Rehearse the cutover and the rollback
Run the full sequence in a production-like environment, time it, and run the rollback as well. A rollback that has never run is an assumption. Measure how long it takes, confirm what data would be lost or need reprocessing, agree the point of no return in advance, and keep the legacy system available for a stated period after cutover.
Then write the decision rule before testing starts: which checks must pass, what level of unexplained difference is acceptable if any, and what triggers a rollback. A decision taken under schedule pressure without a rule is a guess, and the pressure is highest on the day the rule would have been useful.
The decision
Let AI own comprehension and let it draft. Keep disposition, rule completeness, materiality and cutover with named people, and write that split down before the first program is analyzed. It is much harder to impose once the summaries are flowing and the program feels ahead of schedule.
Then budget the evidence separately from the build. Decide the replay period, the field-level tolerances, the reconciliation signatory and the dual-run length at the start, when they are a design choice, not at the end, when they are an obstacle to a date. The GAO finding that seven federal systems were being modernized without a documented plan for the legacy system is the failure this protects against. It predates AI. What AI changes is how fast a program can reach that position while looking healthy.
GrowExx delivers this work through legacy application modernization services, with code-level review through AI code audit.
FAQs
Combine AI Capabilities With Enterprise Software Engineering
Book a Strategic Assessment
