Legacy modernization with AI-assisted engineering: where the cost actually falls
AI coding tools make it cheaper to understand old systems, but proving a migration preserves behavior is still the hard part. What the evidence shows.
Aging systems are expensive in two ways: they are costly to run, and they are costly to understand. In February, two large vendors argued publicly about which problem AI actually solves. Six months on, the useful reading of that debate, plus one recent research paper on validation, is a practical guide to scoping a modernization project.
The argument: understanding is the expensive part
Anthropic's February 23 post on COBOL modernization argues that historically "understanding legacy code cost more than rewriting it," and that AI changes the economics by automating exploration and analysis [1]. It describes a sequence: discovery (mapping entry points, execution paths, data flows and dependencies, including implicit ones shared through files, databases or global state), analysis and risk mapping (finding highly coupled modules versus isolated components that make good early candidates), planning with expert oversight (which includes defining test and validation approaches before code changes), and incremental implementation with continuous validation, with scaffolding to run old and new code side by side [1]. It advises starting with "a single component or workflow that has clear boundaries and moderate complexity" [1].
The post claims teams can modernize "in quarters instead of years," but it offers no measured savings, timelines or customer metrics to support that, and it is published by the vendor of the tool it promotes [1]. Read it as a method description, not evidence of outcomes.
The counterargument: code is the starting point
IBM's response, published the same day by Rob Thomas, makes a different point: "Translating code is one thing. Modernizing a platform is something else entirely" [2]. IBM argues the value of a mainframe lies in its integrated hardware and software stack, not the language, and that translation "captures almost none of the actual complexity" [2]. IBM has its own commercial interest in that position, and its customer figures (for example, one client observing "up to a 94% reduction" in time to analyze and locate superfluous COBOL code) are vendor-reported best cases from a single client [2].
Both can be right. AI can lower the cost of reading and documenting a system, while decisions about architecture, data, security and operations remain engineering judgment.
The missing piece: proving equivalence
The bottleneck in any migration is trust. A July 30 preprint on COBOL-to-Java migration addresses it directly [3]. The authors run the original COBOL and the generated Java off the mainframe with mocked inputs, use an agentic loop to search for inputs that reach more program branches, and check that outputs match [3]. On three case studies (two open-source programs and one internal production-like program) of 430 to 4,114 source lines, they report near-complete coverage on the open-source programs and 91.90% branch coverage on the internal program, with the Java matching the COBOL reference "in all accepted test cases" [3].
The scale is small and the results are from the authors' own test set, so this shows a promising technique rather than a production guarantee. The principle is what matters: use a deterministic comparison of behavior, not a reviewer's impression of the code, as the acceptance test [3].
Stage | What AI can speed up | What stays human-led |
|---|---|---|
Discovery | Mapping flows, drafting documentation [1] | Confirming what the system is really for |
Planning | Suggesting priorities and coupling risk [1] | Target architecture, sequencing, standards [1] |
Implementation | Translating components [1] | Review, security, operational fit [2] |
Validation | Generating tests and inputs [3] | Business-scenario sign-off by domain experts [1] |
What the three sources actually quantify
Source | Type | Quantified result |
|---|---|---|
Anthropic [1] | Vendor method post | None: no savings, timelines or customer metrics; "quarters instead of years" is unsupported by data |
IBM [2] | Vendor opinion piece | One client: "up to a 94% reduction" in time to locate superfluous COBOL code |
arXiv preprint [3] | Research paper | Three case studies, 430 to 4,114 source lines; 91.90% branch coverage on the internal program |
The stage table above is our synthesis of these sources, not a finding from any one of them.
How this maps to a modernization engagement
Sinthetix's Custom Software service includes legacy modernization: migrating aging systems to modern stacks without disrupting the business logic that still works. Our process runs through discovery, architecture, iterative builds and handoff, which lines up with the stages above. The market debate adds three questions worth asking of any such project, ours included:
What is the behavioral baseline? Capture how the current system responds to real inputs before changing anything.
How will equivalence be shown? Agree on the comparison tests, and who signs off on business scenarios, up front.
What is the smallest first slice? A bounded component lets the team learn the codebase and validate the method before committing the full scope.
Implication for businesses: budget the first phase for understanding and test design, not code conversion. If a proposal cannot explain how it will prove the new system behaves like the old one, the schedule is a guess.
Talk to us: sales@sinthetix.com
Sources
- How AI helps break the cost barrier to COBOL modernization Anthropic, 2026-02-23. claude.com/blog/how-ai-helps-break-cost-barrier-cobol-modern
- Lost in translation: what the AI code debate keeps getting wrong IBM Newsroom (Rob Thomas), 2026-02-23. newsroom.ibm.com/blog-lost-in-translation-what-the-ai-code-d
- Agentic Method for Deterministic Validation of Legacy Code Migration arXiv:2607.28271, 2026-07-30. arxiv.org/abs/2607.28271
