I've been unfortunate enough to witness first hand what +-5,0000,000 lines of Natural Adabas code transpiled to +-15,000,000 lines of Java code looks like, and it was not pretty.
This. Friend of mine worked at a company that did COBOL to Java compilation, with the intent of producing "maintainable" code, and he reported (after several years of work) that this just wasn't possible (for them).
I've had to port some old Visual Basic WinForms apps to C#, only a few hundred lines of code for each app, and even that was a huge pain in the butt. Transpiling anything of significant size and complexity will require a metric ton of cleanup and refactoring just to make sure it all works right and can be reasonably maintained by other developers.
This is from hearsay, since I was only there a few weeks before getting out, so I only spent some time on the floor and looked at the code for a bit:
It was a municipal management system that grew over time (decades).
At some stage a government standards body raised the legacy risk inherent in the Natural Adabas codebase.
Some (pretty impressive) 3rd party tool was used to transpile the codebase to a more "modern Java web application architecture".
The code wasn't idiomatic Java and used some extension libraries to supply missing capabilities. For example I don't recall ever seeing any other Java system that uses continuations.
I spent an entire day tracing one field from the front-end to the database. I documented the components, flows, logic and db structures and then asked one of the team leads to verify if I got it right. She confirmed that I did. I then asked what the code on question actually does, functionally.
She replied something to the effect of "Good heavens, I don't know either - you'll need to speak to one of the functional guys and then spend some time with the Natural code from before the transpilation".
She needed about 6 months to get a new Java dev to a level where they could do minor feature requests or bug fixes. Understandably her ability to retain developers was quite low - they tended to leave quickly after spending time with the system.
Business didn't seem to get why the velocity for new features was so slow.
They didn't have an architect, documentation was fragmentary.
Previous modernisation initiatives had already become obsolete as well: IIRC the App server was Glassfish and front-end (web) components were using some JBoss widget library that was already deprecated at the time.