I think the real problem here is that the mainframe assembler codebase is undocumented, and decades of idiosyncratic corner-cases and bug fixes are only present

I think the real problem here is that the mainframe assembler codebase is undocumented, and decades of idiosyncratic corner-cases and bug fixes are only present in the source code. If the system was fully documented, it could be trivially re-implemented in any language or platform of choice. That's why I think this kind of "modernization" project can be really useful, because it forces the organization to define its requirements. Edit: Just to take this concept a little but further, I'd argue that "software" is an illusion. Most software, and nearly all 'enterprise' or 'business' software should be able to be fully defined and written on paper, by humans, before a single developer is engaged to translate those requirements to something a computer can run. The exceptions would be more elaborate things like video games, AI stuff, and things that rely on computers to do what they do. Anything that is automating what humans do (like the IRS here) should be written on paper first, code second. All too often non-technical management doesn't understand this, as it's boring and hard. It's easier to throw money at 'consultants' to pry the requirements out of them and then complain at how expensive the "software" is - while the real expense is just asking your business people what they actually do.