Having worked in COBOL extensivly in the 80s and 90s, as well as working for a software house that did migrations (Craziest was Plan assembler to Dec Vax C).

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.