If the CEO asks what to do with the COBOL

If the CEO asks what to do with the COBOL

Over time, issues linked to COBOL have been postponed and today innovation is being crippled by this ongoing debt. Here's how to defuse it.

The COBOL Challenge

COBOL ascended to become a dominant programming language and a standard in the Mainframe Era throughout the 1960s and 1970s.

In 1977 a Jimmy Carter's officer declared "If It's Not Broken, Don't Touch It". The idea was to save billions if the government adopt this simple motto. It was explained:  'That's the trouble with government: Fixing things that aren't broken and not fixing things that are broken.”

The motto sounded good to institutions CEOs. Those years they regarded IT as an expense, never as an investment.

Since then, the IT world went through constant evolution but any CIO looking for budgets to modernise the systems would hear that it is not broken.

The COVID-19 pandemic brought to light the difficulties associated with the computer systems within U.S. government agencies. The sudden increased demand for services, especially unemployment benefits, overwhelmed systems that used COBOL.

Facing COVID 19 and the difficulty to bring COBOL to the cloud government and the private enterprises understood the need to modernise their systems.

There is no quick solution. Modernising COBOL is a slow process that starts by recognising the immense inversion made building those systems and it contains a huge number of intelligent solutions that must be preserved. It is also necessary to understand that COBOL prevailed sixty years because it is the best software language for business. COBOL is not the responsible for the data storing Americans of 150 years of age and the so-called spaghetti is consequence of patches, repatches of the code through the years. No other software language survived.

Modernisation Solutions

Many are the alternatives for COBOL modernisation.

·       Rebuilding is not only expensive and risky - it is almost impossible. Defining the business rules, regulations and promises embedded within legacy COBOL code presents a significant challenge.

·       Translation to JAVA will not erase the data problems or untangle the spaghetti. It will only create another layer of difficulties for maintaining the COBOL.

·       Microservices create redundancy problems.


SO, if any CEO ask you what can be done tell them:

·       Build your future team: Start paying your COBOL programmers better salaries. Instruct HR people to stop discriminating older people and start COBOL courses on the premises.

·       One by one, slowly but steady refactor your COBOL program: Break the monolithic programs of ten thousand lines into small modules and document them.

 #LegacyModernization,  #COBOLTransformation, #TechnicalDebt ,   #ITLeadership,

  #MainframeEvolution


Alina Zmazhenko

Aspiring Junior COBOL Developer | Mainframe & Legacy Systems Enthusiast | JCL, ZOS, VSAM | Cyber Security | Background in Project & Marketing Management | Multilingual 🌍

3w

Spot on: the problem isn’t COBOL itself, but decades of accumulated technical debt. Rewriting from scratch is often unrealistic or too risky. The real solution lies in steady modular refactoring, preserving business logic and training a new generation of developers. COBOL survived 60 years for a reason — it’s still unmatched in precision and business rule clarity.

Like
Reply
Apolo Heringer Lisboa

médico e ambientalista, na Universidade Federal de Minas Gerais

1mo

Boa noite Mely, aqui tá bom demais....

Titus Aguilar

Solutions/Application Architect, IT Project Manager, IBM-i (AS400, iSeries) Specialist

1mo

Very good analysis. COBOL is never the issue. Its the numerous changes applied to the aging programs over the years. Loads of commented out codes that obscure the logic. And then there's the lack of documentation in the old codes because in the past, memory was limited. Which makes IT teams scared of modifying these ancient programs. And yet somehow, most decide to junk and redo everything. JAVA even. And then the CIO complains when it all goes over budget???

Captain Uday Prasad

Master Mariner | Mainframe Guru | Six Sigma Black Belt | Co-Founder & CEO at ZedInfotech Canada

1mo

The owners of the cobol codes should do an introspect and examine if their codes are still in cobol 74 or before or in cobol85 format. From my years of experience in this line I can bet that more than 75 % of the codes are still not in 85 cobol. Changing over from 74 to 85 version will do an immense change to the performance of cobol programs. It is better than switching over from cobol to Java on the name of modernisation. Cobol is still the only business oriented language and is customized to run batch programs on the mainframe which none other modern languages can.

Captain Uday Prasad

Master Mariner | Mainframe Guru | Six Sigma Black Belt | Co-Founder & CEO at ZedInfotech Canada

1mo

Very informative

Like
Reply

To view or add a comment, sign in

More articles by Mely Lerman

  • Keep IT Simple

    Yes, Keep IT Simple! IT being Information Technology. Why do we software folks sometimes stray from this fundamental…

  • COBOL Toolkit White Paper

    Author: Mely Lerman Date: April 16, 2025 Executive Summary Financial institutions rely heavily on COBOL systems that…

    2 Comments
  • COBOL next stop: AI

    There is a lot of contempt for COBOL, in special among young developers. This is a big mistake! COBOL is the most…

    26 Comments
  • COBOL: The Profession of the Future

    COBOL is often dismissed as an outdated technology: “COBOL is a dinosaur” , “grandpa’s code”, “COBOL is not sexy”. Try…

    27 Comments
  • Reliable COBOL and the Cloud Chaos

    Cloud migration is indeed a blessing! Agility, scalability, innovation are strategic reasons for cloud migration. Cloud…

    13 Comments
  • Three Paths to Legacy Modernisation

    Five years ago, I read an article by a German PhD discussing why companies are maintaining their COBOL code rather than…

    18 Comments
  • COBOL programmers, founders of the Digital Age

    The period of the 1960s was a time of monumental change, marked by significant cultural, social and technological…

    1 Comment
  • Is COBOL Conversion to Java the Answer?

    I've been working with COBOL systems for a long time and have a deep appreciation for this robust and reliable…

    20 Comments
  • COBOL Toolkit DEMO

    In the rapidly evolving world of technology, we often forget that true innovation isn't about discarding the old, but…

  • Innovation: Breathing Life into Legacy

    We are so busy chasing disruption, looking for the latest and we forgot a profound truth: true innovation is not just…

    15 Comments

Insights from the community

Others also viewed

Explore topics