Why would you want to replace 2 billion lines of working COBOL code?
Easy...COBOL, while still in use and working well now, is not a language which is still growing...it is shrinking. Nobody would choose COBOL for a new project. The only jobs left for COBOL programming are maintenance. That means that there are no "exciting" COBOL jobs, and that only coders who learned COBOL, not engineers who are good at design or interested in building/maintaining good design.
"So it's old and all you can get is people willing to maintain, not engineer, the COBOL universe. so what?"
Well, what's what is that:
a) over time, code maintained by "coders" rather than "engineers" i.e. those who are simply proficient in a language, rather those with true engineering talent, will degrade. I have worked with both. I notice a trend. Those with engineering talent...a knack for understanding large systems at a high level and seeing bigger pictures, tend to improve the cleanliness, stability, and re-usability of existing code as they fix or extend it, because they look at the big picture and try to make a change such that it works well in the whole system. "Coders" tend to find the location where the logic goes wrong, and make the most obvious spot adjustment to make the problem go away. Even extensions are treated similarly. Hence, with mostly these types of engineers working on COBOL code, those systems are going to degrade over time. This effect can happen rapidly...I've seen it happen to code that was less than 5 years old. The fact that COBOL code still works is probably more a side effect that all coders of that generation had some engineering skills beaten into them. The younger generation with their "learn a language and get paid" mentality will bring that code to it's knees in a decade or less.
(a) implies problem #2:
b) With code which will degrade as younger, less "design" oriented maintainers are forced to take it over, maintenance becomes a primary concern. Yet as the language gets older, and the code ages and begins to break, gaining more of a reputation for being in shambles, there will be less interest in working on it. Meaning that each generation will produce fewer and fewer COBOL programmers, an effect we are already seeing.
Businesses will be content to sit back and look at their well working, low cost maintenance systems, and think that things will always be that way as long as the don't ask anything new of the system that will cause it to need replacing. This is NOT the case. Eventually COBOL programmers will be all but gone, and those that remain will come at a high premium, and there will not be enough for everybody. At that point, the code will start to break, with nobody to maintain it.
This is when businesses will freak out and think "we need to replace this COBOL program with something in a modern language that we can find programmers for." Except that these old systems are probably not well documented at an algorithm level. The best document is, well, the code. So what they will need is simply someone willing to read through the old code and duplicate it's behavior in a more modern program. Well that doesn't sound SO hard..except, wait, what? You mean, in order to port a program away from COBOL, you need an engineer who still _understands_ COBOL? oh, crap...
