I was involved in this for a couple of years in the mid-90s working for a COBOL vendor helping people migrate from mainframes and minicomputers to what was known as the “open systems” (mostly Unix, with Windows NT rising) world, saving a somewhat jaw-dropping amount of cash in annual licensing and support costs.

Even back then, one of the major complaints was that companies refused to pay for training, hoping they'd find someone who already knew everything they needed. I heard multiple stories about people who told their employer that they were planning to retire, left on schedule after not finding anyone qualified to train, and returned later as a consultant at a significantly higher rate.

Many younger programmers wouldn't want to get into mainframe Cobol programming because of the almost compulsory requirement to provide after-hours support duties in most of these jobs. Many managers find it easier to let programmers get woken up at night to fix the problems instead of allowing them to prevent the problems from occuring beforehand during the daytime. Years of getting woken up at 3 in the morning to fix those types of production problems tends to make many people look for other lines of work. The people who do stay employed doing after-hours support are often the ones who deliberately put the problems into the code during the daytime, generating those money-making callouts. US businesses with some India-based programmers will utilize them to fix those overnight problems because of the time zone difference.

The phrase "their offshore contracting firms" there should be enough to make any sensible 20 year old run screaming. Sure, spend a bunch of time learning a dead language, to get paid peanuts and be replaced by an offshore worker within a year, no problem!

unfortunately even assuming the outsourcer can find people who really have COBOL experience there's a world of difference between knowing COBOL and being able to maintain the 30+ years of hacks that many large companies will have built up in these systems.

Unfortunately the alternative (re-write the mainframe/COBOL systems in a more modern platform) is a risky and costly process....

> being able to maintain the 30+ years of hacks that many large companies will have built up in these systems.

It's not even the hacks. It's that "how the business works" was automated into COBOL 30 or 40 years ago, everyone in the "business" who knew how and why things happened retired or got laid off, and the COBOL programmers are the only ones who remember the business rules.

In college a few years ago I had to work with a system written in FORTRAN 77 in the early 90s that has been hacked new features and bug fixes on and off for almost 20 years, one single file with more than 20k lines of code, it worked all right, but understanding it was troublesome.

I lost the count of how many times I thought about rewriting the entire beast in C or even a more recent iteration of FORTRAN.

In the end, it wasn't something that I would use for much longer and I just mapped what all functions that i needed did on a spreadsheet and added a couple of hacks for the next unfortunate person to handle.

Maintaining old codebases full of hacks and without good documentation that can fail without big consequences is boring, but code that handles the kind of data that banks have is something straight from hell.