I'm not saying I'll do things the conventional way. Once you give up the conventional way, it becomes a different ball-game.
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.
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.