You have no idea. That code is "it does what it does" - no docs, no specs, no tests. Over the decades, "correct is what the procedure does", because 1. it works in most cases 2. nobody remembers why it was written that way 30 yrs ago, but there must be a reason somewhere.
It's not a job for the faint of heart.
And it has complex, undocumented connections to north of a hundred other systems. Screwing up any one of which could have hugely impactful effects on the business (or not, who knows?). So you're going to be coordinating testing with 30-40 teams in diverse parts of the organisation (and externally).
And your couple of million won't pay for the redesign of all those feeds. Hopefully they won't take the testing costs out either or you'll be broke in 2 years.
See, the thing with extracting these old, large systems isn't really the language they're written in, or the hardware they run on. Though those are nasty, ugly problems. It's the coupling. What will almost always defeat you, unless you give the problem the respect it deserves (and often even then) is the coupling.
I hadn't thought of coupling, the distributed nature, so you have a point. However we can think of splitting up the system into pieces, and try to localize the update. For example, for a worldwide distributed system keep everything else the same but replace this one mainframe with modern hardware and code so that the rest of the system doesn't get effected. And so one.
As for the couple million, that's for me :) But I guess if you factor in cost of supporting hardware/software/infrastructure, it's really past 5 million (maybe 10 million), just as an estimate.
To elaborate on my 'unconventional way', I'm talking about using all of:
- complete view of the source code,
- runtime behavior on the screen (even recorded with cameras, or even better, display debug hooks)
- runtime storage logging,
- runtime network logging,
- modern inference methods beyond parsing (semantic inference, logic programming, maybe even some statistical analysis).
- But most importantly, automation-first approach (no, we're not doing things by hand. 'The Machine TM' will do the work for us). E.g., I won't be reading the COBOL code line by line. The code, plus the runtime behavior, would be the input to the inference engine, the output would be 'explanations, documentation, etc'.
- and so on
It would be a very challenging project, hence the 5-10 year timeframe. But I'm not convinced it's intractable. And I'm not convinced the cost is in the billions.
