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.
I got a chuckle over this, but in my experience working on legacy systems, this is the case already. Using AI to translate/explain the code brings extra understanding.
More like it will hallucinate some explanation & cause even more confusion.
well, we just need to learn the rewrite then ???
I do wonder how an ambitious AI would handle the maths. COBOL is renowed for its fixed no rounding maths, utterly rigid and defined in the code, Java on the other hand is not (e.g., 0.1 + 0.2 becomes 0.30000000000000004), unless they are extensivly using BigDecimal, then its already a broken migration.
I've seen projects proclaim in the past to migrate COBOL systems to Java, and fail expicly when the solution was a dtaawarehouse system and a seperate Java system using the legacy backend to do all the fancy marketing reports or whatever other department was pushing for changes they wanted without a grasp of what it truly entailed and blinded by some sales pitch.
It's not just the code that needs migrating, its the data as well, then you want solid robust infrastrucure, which is why IBM still sell those mainframes to run all that well battle tested COBOL code.
Is it impossible to migrate to Java or any othger language - no, anything can be done, but the level of devil in the details and not just software, the data and a robust system to run it upon. It is very easy for even the best to overlook a gotcha.
We have all used an AI where it has gone down one path and you then point out something and it corrects itself, without the knowledge and a load of old grey beads(or a team) to act as devil advocate and try to pull the output apart, YOU can end up with something that works for everyones satisfaction, but is hiding a few gotchas down the line. AI coding needs a full debate team with one puishing it and one countering it almost I'd say.
If it works, why change it is always a good approach and why we mostly have in certain systems a COBOL backend with APIs or datawarehousing to expose for fancy java or other language added value/functionality.
I can only image generations of directors pushing cutting edge to replace legacy systems, and learning that cutting edge can cut you. My sympathy for the IT departments who have to deal with that as it has always been a bain of IT departments who are then forced to justify why it's fooling in a constructive way and explain it to non IT people in upper managment why the case.
As for migrating COBOL to anything, I'd not do it myself, id suggest a rewrite/redesign of a new system from scratch and then run both in parallel for a long time and make sure they actually do the same job and results. Even hand migrating back in the day, would produce a lot of messy code that refactoring would make sence and yet, not what the client would pay for as that would be a rewrite.
[0] https://community.ibm.com/community/user/blogs/gregory-cerne...
Yes, you can't tell at a glance if `+` really still does what it should, but I find that problem no different from a library mis-naming a function and/or said function having strange side-effects.
`+` should do addition, period. No, not even concatenation if possible (I do find the lack of a separate concatenation operator to be a language flaw --- that said, I understand the use of `+` for concat in libraries targeting languages that offer no alternative).
I think the abuse (especially in C++ ... seriously, allowing overloading of the comma operator? --- and <iostream> working via bit-shifting streams by ${some_string} bits) gave everyone a bad taste and they kind of threw out the baby with the bathwater.
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.
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.
And that's why it's usually a stupid idea to nilly-willy migrate large code bases to different languages (also I'm getting really tired of the "but humans aren't either" trope).
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.
My understanding is thats not possible (different from being practical), wonder if you have any literature, research to back up that claim?
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.
At least if tescoverage is good, but well... That's something llms can also be used for
There are hundreds of billions of lines of cobol in production.
The IRS alone has approx 160 cobol programs, averaging 230kloc each.
Maybe.
Still not something you want to risk your business on.
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://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...
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.
As specified, please find 99997 correct parts and the 3 defects (do not use)
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...
My wife and son then told me I "broke" the front door. I was confused, I thought I had fixed it
Turns out, with the door coming off the hinges, it wasn't closing properly, which meant it was ajar most of the time, so our dog could push it open with her body.
Now I'd fixed it, it closed properly all the time, so our dog started whining for someone to open the front screen door for her
So I loosened the screws, and hence "fixed" it by breaking it again
COBOL isn't hard, the tooling around it on old systems are a pain though.
See Hyrum's Law: https://www.hyrumslaw.com/