How Do You Replace COBOL Software? A Short Guide for Getting Rid from COBOL Coding

COBOL has been in business for over 60 years. For those who use COBOL and have an “If it ain’t broke, don’t fix it?” attitude, there’s good news: COBOL is not broken.

And now for the bad news. COBOL is obsolete.

COBOL software has become a bottleneck.

Several US state governments have been gridlocked recently in a long-existing snare. Departments of Labor are unable to handle the dramatically increased numbers of unemployment claims. While departments try to figure out a quick fix, everyone needs to start a scalable long-term solution.

Businesses with COBOL code on production have long faced this problem. With global lockdown, it has become blatantly obvious.

On the bright side, global lockdown is probably the best time to test a system, determine its weak points, and figure out a long-term solution.

Read about both problems concerning COBOL software and a path towards a solution.

What is wrong with Cobol?

Nothing. COBOL is neither bad nor good when comparing it to other software development platforms or languages.

COBOL is different.

Like any other platform, COBOL has its benefits and tradeoffs. It has its haters and supporters with a “holy war” between them.

COBOL programming code looks nearly perfect for COBOL developers.

COBOL software looks clumsy and old-fashioned for those who have moved on.

However, could an ponderous platform sustain so many years in production? No, it could not. COBOL is no exception.

But COBOL is the top choice as a programming language in its respective niche: financial data processing on IBM mainframes.

Typical product owners of COBOL programs include enterprises and many kinds of authorities, including:

banking
insurance
government institutions
local administrations

Of note: IBM has done its best to prolong Cobol’s life cycle. IBM implements COBOL compilers on its mainframes to help run source code immediately. It also keeps improving mainframe architecture and provides COBOL programmers with software development tools and guidance.

What is the problem then?

The benefits of COBOL programming have fostered drawbacks.

During these many years, COBOL has been polished to perfection to work as best as possible for one specific use case—only one.

And it did! Programmers always choose the best tool for a specific job. For financial calculations, mainframes and COBOL are the top tools.

COBOL long ago left all its rivals in the programming world in the dust. However, with no competition, COBOL lost its edge. Philosophy of the language became outdated.

As result, its benefits have become drawbacks:

What are the results?

For young developers, working on COBOL software might well signal a dead-end career path. Programmers must dig regularly into low-level system settings, prepare another sort of glue that will connect ancient legacy code with modern front-end systems and focus on IBM mainframe technologies. For those who get bored and decide to change specialization? For most, they face do-overs: starting again as a junior software developer. COBOL knowledge and skills are useless in the rest of the programming world.

Why not opt for Google, Facebook or Microsoft and work with cutting-edge technologies?

For businesses, governments, and administrations, COBOL software means losing competition in the labor market and being left one-on-one with updates and maintenance of critical software components.

Product owners must keep a balance between budget, maintenance costs, unforeseen costs, introduction of new features, and ROI where maintenance costs eat up the biggest part of the budget.
Eventually, those faithful COBOL software users get stuck between three options:

no good – keep running old COBOL system as is
everything can get worse – redevelop software using modern platform
run out of cash – maintain both

Here are main challenges of both paths:

Do the options look like a “recipe for disaster”? Only if product owners keep ignoring the problem for the next decade.

Okay, what IS the plan?

Gradual, step-by-step migration into the cloud.

Generational change is inevitable not only for people but for software, too.

The main goal is to modernize software iteration by iteration without causing delays or downtime. When possible, developers maintain proven best practices and reverse compatibility within the ecosystem.

Redesign of old COBOL software requires the following steps:

Discovery

Discuss project aims, requirements, and expectations.
Explore system.
Study system architecture.
Carry out code inspection and reverse engineering to learn exactly how system works.

Decomposition

Determine interdependencies and links between system components.
Prepare scope of work needed to turn old COBOL code into cloud native source code.
Establish a list of job priorities.

Redesign of architecture

Redefine components.
Eliminate technical debt by dividing components into critical, nice-to-have, and redundant.
Determine what components block moving to the cloud.
Optimize system architecture ensuring new dependencies do not impair the system.

Redevelopment

Rewrite source code based on priorities.
Use short Sprints to produce results every two weeks.
Introduce CI / CD to automate routine.

Migration

Modernize system in stages without interruption of business processes.
Orchestrate old and new programming code.
Ensure easy roll back.

Replacement

Start using new source code gradually.
Analyze backlogs to keep track of nuances.
Keep two systems working in parallel.
Switch to the new system when both work identically.

Maintenance and updates

Use monitoring tools to constantly check system status.
Provide regular updates to ensure security.
Introduce best practices such as regression testing to reduce risks and dockerizing to boost delivery.

Have we ever used this plan?

Yes, we have done this before. It takes time. But achieving excellence does take time.

You, too, can move away from COBOL. It pays off in the end.