Before, only the senior cobol programmers at the company understood and knew the codebase.
Now, no one does.
I can see the allure of moving away from a legacy cobol system. But an AI rewrite doesn't actually solve any of the issues with having a legacy cobol codebase. You just have a new system no one knows or understands.
The biggest problem is not that bugs are migrated with COBOL, but that lots of new bugs are going to be introduced. AI is not deterministic, it will be making tons of mistakes. The only realistic low-error approach is incremental step-by-step migration using Cursor or similar tools. However, it requires much more time as each step must be prompted, tested and committed manually. Any hope that one-shot migraton of a large code base will not introduce enormous number of bugs is very naive. LLM is very bad on handling long context - it is their nature unfortunately. There is no answer to this problem yet.
> AI is not deterministic, it will be making tons of mistakes.
From the paper:
> The COBOL source is passed through an internal deterministic Migrator to produce a generated Java target.
Also, humans are not deterministic either. Give the same COBOL -> Java translation to multiple developers and each will come up with a different solution. Heck, even the same developer will produce a different output for the same task, depending on the day of the week.
But it says that the agentic authoring step patches the migrator when things get stuck. So while the execution of this stuff is deterministic, its actual content is not.
> AI is not deterministic, it will be making tons of mistakes.
Just set the sampling temperature to zero and remove any unintended non-determinism during the parallel computation of the token probability distribution. The problem is solved? Of course, not. Non-determinism has little to do with LLMs' mistakes.
You don’t need the entire codebase in context in every moment to migrate it.
Also AI being non deterministic does not prevent it from one-shotting perfect solutions 100% of the time for simple enough problems.
And every model generation brings this bar higher. So that’s really not a fundamental problem.
And we can also implement llm inference deterministically if we want, it’s just that it’s not worth the loss in performance to do it.
> The only realistic low-error approach is incremental step-by-step migration using Cursor or similar tools.
Correction: AI is not deterministic, the only realistic low-error solution is not a more complex use of non-deterministic AI, but deterministic transpilation.
The problem is that this results in COBOL-in-Java which runs correctly but it is a nightmare to maintain.
AI (LLMs) is typically not run deterministically for performance reasons, but can be turned deterministic if you want it to be. The output will still be probabilistic, however, so you will be no further ahead. Determinism isn't helpful.
While not everything can be easily converted (IMS, CICS, reports, batch processing etc.), there are many situations where automated tooling can be helpful in migrations.
Related to this, I created a tool for situations where you want to compare COBOL code with Java code. It includes a preprocessing step where IMS etc. calls are converted to mocks that return JSON (from file), and also use JSON for input/output, and GnuCOBOL to run the program. More a proof-of-concept than production, but here is a link if somebody finds it helpful.
How does ai implement all the not Cobol parts a Cobol program rely on? Job Contol, CICS, sort processors? Cobol and mainframe technologies are non existant in java on any modern machine
Batch job control is handled by alternative systems (already often triggering the work on mainframes anyway) like Control-M
CICS is the big issue but AFAIK there were attempts. Everything else, including sort and VSAM, has various options provided usually by COBOL compiler vendors.
I remember a similar story shared this year at JAX2026 from the Sparkasse Group, they said they were using AI to migrate from COBOL, but they still were in the middle of the migration. Maybe they faced the same issues / problems? It seemed pretty zealous to me, that everything was working smoothly, but this article highlights the limitations
some years ago I talked to a software engineer at a bank, he said it would be too risky for them to move away from the mainframe what with regulations and all, I'm not sure if AI could make the banks more risk friendly, so if Sparkasse does that already, I, for one, am eager to learn the result (and am happy to have no account there)
300 to 4000 lines of "production like" (whatever that is) cobol code which is easily ported to a non-mainframe env. Our's sometimes uses assembler in its innards, so good luck with real legacy code spanning a dozen files and 50k loc...
I recently threw in (want to check those intelligence metrics!) some real production code into a non-agentic system (just to get a feel how things perform without a custom harness) and results where ... interesting. The particular program uses some preprocessor no LLM we have access to (newest was GPT 5.5) has any clue about - so they confabulate what it could do (Gemini 2.5 didn't even notice there was a preprocessor...). This is expected of course but it somehow seems the problem of this technology that unless you feed it masses of data or mechanically break up the tasks in rote subunits, it just doesn't do anything sensible still...
Yeah that’s why they delegated code gen to deterministic tooling and saved the model for input fuzzing - let it fight the data instead of legacy syntax
Anything running on COBOL to day is a large enterprise system. You'll have reports running in other systems in subsidiary companies that rely on bugs in the upstream cobol code.
Yeah. Bug-for-bug migration is a real thing in large code-bases in the industry. You want to replicate all behavior of the code regardless whether the behavior is a feature or a bug.
COBOL is not about the language, it's about the whole environment in the mainframe. LLM fanboys won't understand this. You need something like a mainframe with a 99.99% uptime no matter what happens in hardware, with live CPU swapping and such.
Yes and that mainframe runs several other technologies besides COBOL, and more importantly, that don't depend on it (COBOL fanboys won't understand this ;) )
Before, only the senior cobol programmers at the company understood and knew the codebase.
Now, no one does.
I can see the allure of moving away from a legacy cobol system. But an AI rewrite doesn't actually solve any of the issues with having a legacy cobol codebase. You just have a new system no one knows or understands.
The biggest problem is not that bugs are migrated with COBOL, but that lots of new bugs are going to be introduced. AI is not deterministic, it will be making tons of mistakes. The only realistic low-error approach is incremental step-by-step migration using Cursor or similar tools. However, it requires much more time as each step must be prompted, tested and committed manually. Any hope that one-shot migraton of a large code base will not introduce enormous number of bugs is very naive. LLM is very bad on handling long context - it is their nature unfortunately. There is no answer to this problem yet.
> AI is not deterministic, it will be making tons of mistakes.
From the paper:
> The COBOL source is passed through an internal deterministic Migrator to produce a generated Java target.
Also, humans are not deterministic either. Give the same COBOL -> Java translation to multiple developers and each will come up with a different solution. Heck, even the same developer will produce a different output for the same task, depending on the day of the week.
> Also, humans are not deterministic either.
Indeed, and that's why so few dare to migrate them, and so many who do fail or blow the budget many times over.
I think that was the implicit point of the comment: don't expect that with AI, suddenly we can convert all those COBOL apps with a single prompt.
But it says that the agentic authoring step patches the migrator when things get stuck. So while the execution of this stuff is deterministic, its actual content is not.
> AI is not deterministic, it will be making tons of mistakes.
Just set the sampling temperature to zero and remove any unintended non-determinism during the parallel computation of the token probability distribution. The problem is solved? Of course, not. Non-determinism has little to do with LLMs' mistakes.
You don’t need the entire codebase in context in every moment to migrate it. Also AI being non deterministic does not prevent it from one-shotting perfect solutions 100% of the time for simple enough problems. And every model generation brings this bar higher. So that’s really not a fundamental problem. And we can also implement llm inference deterministically if we want, it’s just that it’s not worth the loss in performance to do it.
> The only realistic low-error approach is incremental step-by-step migration using Cursor or similar tools.
Correction: AI is not deterministic, the only realistic low-error solution is not a more complex use of non-deterministic AI, but deterministic transpilation.
The problem is that this results in COBOL-in-Java which runs correctly but it is a nightmare to maintain.
AI (LLMs) is typically not run deterministically for performance reasons, but can be turned deterministic if you want it to be. The output will still be probabilistic, however, so you will be no further ahead. Determinism isn't helpful.
Does it? I found llms to be great for straight conversions
At least if tescoverage is good, but well... That's something llms can also be used for
The largest test case was 4kloc.
There are hundreds of billions of lines of cobol in production.
The IRS alone has approx 160 cobol programs, averaging 230kloc each.
While not everything can be easily converted (IMS, CICS, reports, batch processing etc.), there are many situations where automated tooling can be helpful in migrations.
Related to this, I created a tool for situations where you want to compare COBOL code with Java code. It includes a preprocessing step where IMS etc. calls are converted to mocks that return JSON (from file), and also use JSON for input/output, and GnuCOBOL to run the program. More a proof-of-concept than production, but here is a link if somebody finds it helpful.
https://github.com/mikko-ahonen/coboltwin
Stuff like this are already a commercial product, it isn't only Zig to Rust rewrites going around.
https://www.pega.com/insights/resources/break-free-legacy-ma...
https://www.ibm.com/products/watsonx-code-assistant-z
https://global.fujitsu/en-global/pr/news/2026/03/30-01
https://www.rocketsoftware.com/en-us/insights/ai-powered-cob...
Why should I convert COBOL to Java? LLM can write COBOL just as fine.
How does ai implement all the not Cobol parts a Cobol program rely on? Job Contol, CICS, sort processors? Cobol and mainframe technologies are non existant in java on any modern machine
Batch job control is handled by alternative systems (already often triggering the work on mainframes anyway) like Control-M
CICS is the big issue but AFAIK there were attempts. Everything else, including sort and VSAM, has various options provided usually by COBOL compiler vendors.
I remember a similar story shared this year at JAX2026 from the Sparkasse Group, they said they were using AI to migrate from COBOL, but they still were in the middle of the migration. Maybe they faced the same issues / problems? It seemed pretty zealous to me, that everything was working smoothly, but this article highlights the limitations
some years ago I talked to a software engineer at a bank, he said it would be too risky for them to move away from the mainframe what with regulations and all, I'm not sure if AI could make the banks more risk friendly, so if Sparkasse does that already, I, for one, am eager to learn the result (and am happy to have no account there)
COBOL will never die. Whatever this is will only result in more COBOL being written.
As I understand it, the translation isn't done by an LLM but by a deterministic AST-based migrator. Also, carrying over the bugs is the stated goal.
To IBM
As specified, please find 99997 correct parts and the 3 defects (do not use)
300 to 4000 lines of "production like" (whatever that is) cobol code which is easily ported to a non-mainframe env. Our's sometimes uses assembler in its innards, so good luck with real legacy code spanning a dozen files and 50k loc...
I recently threw in (want to check those intelligence metrics!) some real production code into a non-agentic system (just to get a feel how things perform without a custom harness) and results where ... interesting. The particular program uses some preprocessor no LLM we have access to (newest was GPT 5.5) has any clue about - so they confabulate what it could do (Gemini 2.5 didn't even notice there was a preprocessor...). This is expected of course but it somehow seems the problem of this technology that unless you feed it masses of data or mechanically break up the tasks in rote subunits, it just doesn't do anything sensible still...
Yeah that’s why they delegated code gen to deterministic tooling and saved the model for input fuzzing - let it fight the data instead of legacy syntax
Yeah nah maybe fix the bugs before swapping the average COBOL dev for the average Java dev.
sometimes if the bug exists for enough time it is intended behavior
Absolutely, and you'll have all kinds of fixes for the symptoms throughout the project.
COBOL isn't hard, the tooling around it on old systems are a pain though.
Anything running on COBOL to day is a large enterprise system. You'll have reports running in other systems in subsidiary companies that rely on bugs in the upstream cobol code.
Indeed, there may even be a whole lot of code that depends on it.
Yeah. Bug-for-bug migration is a real thing in large code-bases in the industry. You want to replicate all behavior of the code regardless whether the behavior is a feature or a bug.
See Hyrum's Law: https://www.hyrumslaw.com/
Yep, and when it’s about money you don’t want any unexpected.
hyrum's law applies here
COBOL is not about the language, it's about the whole environment in the mainframe. LLM fanboys won't understand this. You need something like a mainframe with a 99.99% uptime no matter what happens in hardware, with live CPU swapping and such.
Erlang/Elixir/OTP has a resilient environment with hot swapping. Is that truly problematic?
Can you explain why you need one machine never falling over ever instead of a cluster of machines never falling over at once collectively?
Yes and that mainframe runs several other technologies besides COBOL, and more importantly, that don't depend on it (COBOL fanboys won't understand this ;) )