It is not that difficult a problem code wise. It's a very difficult problem culturally though, in that the people that know mainframes and also C/C++ or Java or whatnot and could help do the migration slowly and safely and mostly in-place, are not the people that want to or are able to touch the COBOL. And outside of the systems programming crowd (who mostly don't do COBOL), the applications people at a lot of mainframe shops tend to wind up being heavily siloed, often attached directly to a particular business unit, with one foot in the Computer Science/IT fields and one foot in Finance. As in, they might literally only have ever written COBOL, and might not understand the high level architecture well enough to actually reconstruct anything. It would be like working on a single app that gets packaged in a docker container your whole career, and then somebody comes and starts asking questions about how you would reimplement Kubernetes and container runtimes. That's really how a system like CICS (where a lot of application developer code ends up, and is mostly transparent to them) actually functions. It was containers way before they were called containers, and usually involved some pretty strict restrictions imposed on the runtime environment.
So you've got a situation at a lot of places where you'd need to replace 50%+ of your staff if you wanted to convert to modern tooling, while at the same time it is harder and harder to replace the staff that leave and know the old set of tools. That cannot continue indefinitely. And until you cross some invisible threshold in the number of people that are comfortable in a modern software development environment, things can continue like they are for a long time.
Ultimately this is driven by the strange (for the tech industry) demographics of mainframe teams, in that they are often still dominated by people that entered the industry before microcomputers were ubiquitous. They may only know "the mainframe way" to do things, because they entered the industry the old-school way by stacking tapes in a data center or moving up from accounting, back before CS degrees and LeetCode and all that. It's only like that in mainframe shops because everywhere else has had massive growth (as in from 0 -> however many programmers they have now) and skews much younger as a result of computing not even having been adopted in any significant way until (for example) the late 80s/early 90s.
It's this cultural aspect of Mainframes (due to the history of being the oldest computing platform still running in production) that remains mostly unexamined and is not well understood by those on the outside. These are unique challenges that mostly don't have to do with the well known and arguably solved problem of "how can I convert some COBOL code into logically equivalent <any other language> code".
One final point is that COBOL is ruthlessly efficient (equivalent in speed to C, sometimes with more efficient use of memory for particular kinds of programs it is specialized for) in a way Java is not. Java is only popular on mainframes due to the licensing advantages IBM was forced to give out due to the much higher resource usage, and because their JVM is actually a very good implementation and well-liked by people on non-mainframe teams. If everything starts moving to Java though, I bet those licensing advantages probably go away. So I think more needs to be invested in C/C++ and possibly Go, rather than Java, at least initially. It is possible to write both of those portably and not suffer the huge performance penalty implicit in moving to a Java stack. I suppose this in particular may just be due to me being several years removed from web development, and some of the mainframe attitudes towards code have started to rub off on me.