Migrating the COBOL Legacy to Modern Systems and Their Challenges

Cobol – a relatively unknown language to the modern programmer. Those who have heard of it regard it as a relic of a past era, succeeded by modern languages. It used to run on massive computers called mainframes(created by IBM)  But what if I tell you that around half of the banking software still uses COBOL (short for Common Business Oriented Language) and mainframe systems? 

COBOL: The Scary Statistics

Did you know that

43% of banking software is still using COBOL? Over 80% of in-person transactions at U.S. financial institutions use COBOL. Fully 95% of the time you swipe your bank card, there’s COBOL running somewhere in the background. There are more than 400 billion lines of code of COBOL that are still in use today, and that is only in the USA.

But barely anybody teaches COBOL. In fact, only 37 universities in the world have a dedicated mainframe course. And the average age of the COBOL developers is only getting higher and this is a ticking time bomb. Because at some point, there won’t be people able to support a big amount of the banking infrastructure that we rely heavily on today.

What Led to this Situation?

The COBOL systems that are in use today are battle-tested over a long period of time. Тhey have proven their reliability and are the workhorse of the banking software. Millions of lines of code have been tested extensively in real-world scenarios. In a way, it is difficult to justify the cost of migration to the stakeholders when they have a perfectly working system and some developers want it replaced simply to be “modern”. 

The language is perfectly backwards compatible with code written in the 70s, which is a rare feat. Banks are notorious for their conservative practices, they don’t want to modernise something that is working just for the sake of modernisation. But the clock is ticking, there are fewer and fewer COBOL developers and many financial institutions may soon find themselves with a black box of code that does the vital transactions, but no one understands it.

Just Rewrite COBOL?

Some of the more junior developers will say that this legacy code needs rewriting. Easier said than done. To rewrite the logic from one language to another, you will need to be an expert in both languages and also the business domain. And as we said, there are almost no universities that teach you COBOL and mainframe systems.

There have been attempts, most of them unsuccessful. I know of an insurance company in Europe that tried several times to modernise their mainframe and gave up after multiple failures. Many clients still use VSAM files as data (think of them as key-value storage) which is the predecessor of the SQL format. You have to prepare yourself to handle that as well. Also, the data would be encoded in EBCDIC which is older than ASCII and not compatible with it. You need to account for GDG files, which are generational files that save each of their changes in a new version. The COBOL program could request a version 30 generations ago, so you need to account for that. The front-end language of the mainframe system is called BMS, and I advise you to have a way to migrate it to HTML.

Finally, prepare your punch card reader. I hope it uses USB. Have fun.

Actually Viable Approaches

If you want to get away from the mainframe, you could potentially emulate it on AWS. But this is just a stopgap at best. You still have all your COBOL problems and, at best, just have a lower cost and a higher performance machine. In the end, you gave a car from 1920 a new paint job. If it satisfies your business needs for now, great, but you will have a new problem in 20 years.

Rewriting is the most optimistic approach. It is extremely risky, as the new code hasn’t proven itself reliable in the real world. The business domain will be known by the COBOL developers and they have to explain it to the new developers who will try to get the legacy system under control. If you succeed you will have to fire your COBOL devs, as there is no longer any place for them in the development. If you fail, you have to fire your Java devs, as you no longer need them. The data and IBM mainframe middleware have to be exported to usable formats. Millions of lines of code have to be written and tested again. It is an extremely costly and risky proposition.

Currently at Dreamix, I’m working on a client’s project that’s successfully providing replatforming services. We aim to make COBOL a first-class citizen on the JVM. We compile the COBOL and provide all the runtime services so that COBOL programs run in exactly the same way as on the mainframe but using standard Java and cloud components to replace the mainframe ones. This will allow you to have both the COBOL and Java devs working side by side without the need to fire one of these groups when they finish the migration. We have multiple clients that are already in production with this model and we have seen great results. 

Final Words

The world runs on old technologies and old software. Being battle-tested and reliable will always trump the new shiny thing. On the other hand, old technologies inevitably go through stagnation and sooner or later something needs to change. And with change comes opportunity. COBOL is the workhorse of the bank industry, there is no denying that. The mainframe modernisation business arena is worth hundreds of billions of dollars. Big firms are waking up to the fact that soon they will have a black box of code that no one could change or understand. But that could provide the opportunity for those with enough preparation.

The modernisation of the mainframe will happen regardless. But every year it is delayed, the cost to maintain the old infrastructure will rise until it proves financially unviable. If you want to book a consultation regarding your system, we at Dreamix are happy to help.

Book free consultation and a Dreamix representative will contact you directly.