It’s never been a technical reason, it’s the fact that most systems still running on COBOL are live, can’t be easily paused, and there’s an extremely high risk of enormous consequences for failure. Banks are a great example of this - hundreds of thousands of transactions per hour (or more), you can’t easily create a backup because even while you’re backing up more business logic and more records are being created, you can’t just tell people “hey we’re shutting off our system for 2 months, come back and get your money later”, and if you fuck up during the migration and rectify it within in hour, you would have caused hundreds/thousands of people to lose some money, and god forbid there was one unlucky SOB who tried to transfer their life savings during that one hour.

And don’t forget the testing that needs to be done - you can’t even have an undeclared variable that somehow causes an overflow error when a user with a specific attribute deposits a specific amount of money in a specific branch code when Venus and Mars are aligned on a Tuesday.

Well, I’d rather the day be sooner than later.

Agreed, but we’re not the ones making the decision. And the people who are have two options: move forward with a risky, expensive, and potentially career-ending move with no benefits other than the system being a little more maintainable, or continuing on with business-as-usual and earning massive sums of money they can use to buy a bigger yacht next year. It’s a pretty obvious decision, and the consequences will probably fall on whoever takes over after they move on or retire, so who cares about the long term consequences?

You run months and months of simulated transactions on the new code until you get an adequate amount of bugs fixed.

The stakes in financial services is so much higher than typical software. If some API has 0.01% downtime or errors, nobody gives a shit. If your bank drops 1 out of every 1000 transactions, people lose their life savings. Even the most stringent of testing and staging environments don’t guarantee the level of accuracy required without truly monstrous sums of money being thrown at it, which leads us back to my point above about risk vs yachts.

There will come a time when these old COBOL machines will just straight die, and they can’t be assed to keep making new hardware for them.

Contrary to popular belief, most mainframes are pretty new machines. IBM is basically afloat purely because giant banks and government institutions would rather just shell out a few hundred thousand every few years for a new, better Z-frame than going through the nightmare that is a migration.

If you’re starting to think “wow, this system is doomed to collapse under its own weight and the people in charge are actively incentivized to not do anything about it,” then you’re paying attention and should probably start extending that thought process to everything else around you on a daily basis.

Nah, dump it all.

COBOL programs don’t handle utf8 and other modern things like truly variable length strings.

Best thing to do is refactor and periodically test by turning off the mainframe system to see what breaks. Why something was done is lost to the sands of time at this point.