I remember reading about a company writing a Cobol to Java translator to migrate their codebase over 10 years ago. It seems it was very successful. They had focused on making the conversion entirely automatic and reliable, so that they could keep on retranslating new / modified Cobol code during the transition process.

We did it to replace a Cobol core-banking system. The hard part is not so much the code as all the interfaces (DB, queues, printing, etc).

Sounds ugly, but if it's important enough and you have somebody who understands all the angles, it could be possible.

That excludes 99.999% of government employees, though.

It’s not immediately clear what benefits that would bring though besides ticking a box of “technically a modern language”. Automated translation won’t be much more readable than assembly and it won’t magically become enterprise grade OOP either.

You don't think it's easier to develop in Java than assembly? And setting aside the development experience, it might be easier to hire Java programmers.

I was wondering the same; I guess it would be easier to refactor step by step (renaming functions and variables as you work through the code)

From experience, i have seen cobol code stashing entire copybooks into char/varchars, along with some binary switches to select the appropriate copybook. Unless you have the copybook or a translated version, it's pretty much unreadable. In general it's useful if only to interface with those old parts you don't want or can't change.

According the the article, they want to move from a local environment using assembler to Java, which apparently gives them a direction for network access, including web.

Didn't Micro Focus already do something like this, to allow legacy systems to be retired without needing software rewrites?