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.

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