The semantics don't map onto modern languages: it's verbose assembly, with business logic consisting of GOTOs between segments of million line codebases with debug-evolved behavior encompassing a spec (e.g. translate between ancient ad hoc database formats) and then some. Porting COBOL means replicating all that existing customers expect and depend on, including what's unspecified.
I couldn't tell you how hard it is in practice to work past global state heisenbugs - never written it myself, only studied it out of fascination - but it's an entertaining trainwreck whenever a bank announces a COBOL->Java migration, spends millions, fails, and goes back to COBOL, so it's not even clearly possible in general.
It doesn't feel like a realistic bottleneck. Those programs are typically small relative to what we write these days. There are also in-between languages like DIBOL if someone doesn't want to go all the way.
And for any serious system, this will need so many manually reviewed tests, that the code translation part shouldn't even be the biggest chunk of work.
(Also, from my experiments in translating old software with weird language/hardware, Claude is not even that good at it)
I suspect the expensive part of owning a COBOL code base is not transpiling to new architectures or languages; it’s paying the few remaining COBOL programmers to make modifications your business needs.
Haven't people done this before? Back in the 80's one of our "team" members (I use the term loosely) would reverse engineer the day's code every evening, rendering it unreadable to everyone else who created it.
Of course, nobody these days asks "why?"
If it ain't broke ...
Banks have tons of money (OPM!) and IMO, could rewrite legacy code, but
This is IBMs moat. The entire reason corporations don't move off the mainframe is due to the cost and complexity of migrating the old code, oh, and the reliability of the mainframe. There are many architectures which can be made more reliable than the mainframe. 13% is just the beginning.
Isn’t a better question: why would they migrate off COBOL? Their business is working. What’s the impetus to change? It’s not like they need to use COBOL for every new project.
Was transpiling COBOL ever a bottleneck or is this just pure market manipulation?
The semantics don't map onto modern languages: it's verbose assembly, with business logic consisting of GOTOs between segments of million line codebases with debug-evolved behavior encompassing a spec (e.g. translate between ancient ad hoc database formats) and then some. Porting COBOL means replicating all that existing customers expect and depend on, including what's unspecified. I couldn't tell you how hard it is in practice to work past global state heisenbugs - never written it myself, only studied it out of fascination - but it's an entertaining trainwreck whenever a bank announces a COBOL->Java migration, spends millions, fails, and goes back to COBOL, so it's not even clearly possible in general.
Part of the problem was that COBOL was written for much slower machines, so it is a whole lot faster on current machines than modern languages.
so, all ported programs suffered from heavy performance degradation and were cancelled
It doesn't feel like a realistic bottleneck. Those programs are typically small relative to what we write these days. There are also in-between languages like DIBOL if someone doesn't want to go all the way.
And for any serious system, this will need so many manually reviewed tests, that the code translation part shouldn't even be the biggest chunk of work.
(Also, from my experiments in translating old software with weird language/hardware, Claude is not even that good at it)
I suspect the expensive part of owning a COBOL code base is not transpiling to new architectures or languages; it’s paying the few remaining COBOL programmers to make modifications your business needs.
repost:
Haven't people done this before? Back in the 80's one of our "team" members (I use the term loosely) would reverse engineer the day's code every evening, rendering it unreadable to everyone else who created it.
Of course, nobody these days asks "why?"
If it ain't broke ...
Banks have tons of money (OPM!) and IMO, could rewrite legacy code, but
why?
This is IBMs moat. The entire reason corporations don't move off the mainframe is due to the cost and complexity of migrating the old code, oh, and the reliability of the mainframe. There are many architectures which can be made more reliable than the mainframe. 13% is just the beginning.
Software automatically translating COBOL to (say) Java has been around for a long time.
So there is zero value add using AI for this. Quite the opposite given how error prone AI is.
If that's the case then why haven't more places moved off of COBOL?
The language itself is the least of the problems. There is a whole mash of IBM mainframe technologies that is much harder to replace.
Isn’t a better question: why would they migrate off COBOL? Their business is working. What’s the impetus to change? It’s not like they need to use COBOL for every new project.
Also running probably nearly 100% bug free.
https://www.cnbc.com/2026/02/23/ibm-is-the-latest-ai-casualt...
OpenaAI, glaring at Larry Ellison: "hold my beer."
[dead]
[dead]