Legacy Systems Modernization is not simple : is Claude Code COBOL Modernization a useful tool or Hype?

In previous posts titled Anthropic code or Hypethropic code? and Anthropic code: No Revenues Plan as Immaturity indicator I was very skeptical about current Anthropic code capabilities.

This post is about the unrealistic dream of transforming Legacy Mainframe COBOL Systems to modern systems by using Claude code COBOL tool.

More than 50 years ago I was a COBOL Programmer.

Afterwards I was a Systems Programmer and a CTO.

I participated in Mainframe systems architecture changes, replacement and maintenance, as well as Mainframes migration projects and Modernization projects.

The main issues are not pure coding issues. Some of the major obstacles will be dwelled upon in the following paragraphs.

Functionality and flow of the System

Usually nobody knows and understands it completely.

Claude code COBOL tool will create System which is not downward compatible.

The systems were written decades ago and if there is documentation, probably it is not updated.

The original programmers not necessarily available.

Those who maintain the Systems do not understand the System and the code as well as the original programmers understood it.

Large Unstructured Silo Systems

Many Mainframe systems are Large Silo systems.
The systems are not Component Based or Service Oriented. It is not possible to transparently replace a component by modern code such as code created by Claude Code.

Data and Systems Integration

The APIs between systems are not standard modern API's

Could Claud Code build them correctly?

Other less known Programming Languages

The Mainframe applications include code written in other programming languages.

Among them are Assembler, Obsolete programming languages such as Mark4, UFO and other languages such as PL/I, Software AG's Natural.

Bugs and Debugging

Even in cases of AI tools writing simple applications there are many bugs.

Expect for more bugs in large Mission Critical Mainframes systems.

Performance Issues

Even if the code will be fully compatible to functionality requirements, bad Performance could limit its usage.
Is the performance of code created by Claude Code good enough?

Large Systems performance requirements are different from small simple single user systems requirements.

Maintenance

Most of the resources spend during Application Life Cycle are for Maintenance and Application Changes (Estimated as 70% or 80% in Large old Silo Systems).
How difficult is Claude Code COBOL Maintenance?

Reducing Migration Risks

In many cases Migration Projects are performed in steps in order to reduce Risks.

Each step includes Migration of part of the System.

However, the mixed new and old code System should be integrated in order to perform its task as it did before the partial migration.

The integration is maintained by writing and executing temporary code, such as Bridges and APIs.

After verification correct operation of the the part of the system which was migrated together with other parts the next step should be executed.

The temporary APis and Bridges should be adapted for the next step.

Is Claude Code Capable of creating those Bridges and API's?

Conclusion

Currently, Claude Code is far from being able to create COBOL Mainframe Systems or other COBOL Systems such as UNIX Microfocus Cobol Systems.

My Take on Migration from Mainframe

Migration Processes from old Mainframe Systems are difficult and expensive.

The Justification of such Migration projects is not easy.

The top Management could identify many Risks and no direct Business benefits.

The best scenario is new system which is performing the Business Functionality and Processes as good as the previous system performed without any addition of Functionality and Processes e.g. no Business Value.

In many cases the best way is System Modernization i.e. gradually transforming the Silo System to Services.

Services could be Reused and moved to other platforms or recoded in modern programming languages.

Previous promises of migrating Core Banking Systems of Large Banks to other platforms on the Public Cloud failed.

These promises were not realized due to some reasons similar to the reasons that Claude Code is not capable to accomplish its promises.

For example, read Public Cloud Core Banking: Hype or Reality?

The mainframe: still alive and kicking

Recently, I was interviewed by Pcon (unfortunately the link points to an Hebrew only site) as part of debriefing on Legacy Systems. Pcon is an Israeli company investigating IT topics by quoting professional articles and interviewing experts. They publish the results of the investigations including practical recommendations. This post is mainly about topics raised by me during the interview, but not included in the debriefing, which will be published. What are Legacy Systems? The term Legacy Systems refers to old application systems and/or veteran technologies still in use. Usually, the term Legacy Systems is associated with: 1. Mainframe Hardware e.g. IBM System z and its Operating Systems or Proprietary Servers and Operating Systems such as HP Alpha and OpenVMS Operating System, IBM AS/400 and OS/400 Operating System. 2. Development and Production Environments, e.g. COBOL , Natural and DBMS systems such as Adabas ...

Will Business and IT Aligned?

For decades we are talking about closing the gap between business and IT , but the gap is still as wide as it was. In the beginning of the ERP era, we focused on aligning Business Processes and Core Systems, but in most enterprises we failed. SOA was the next alignment promise: defining the SOA Services in Business boundaries instead of Technical boundaries, should narrow the gap. However, despite of SOA Business Value ( Agility and Reuse ) in most enterprises, the large Business-IT Gap remained as large as it was. The IT Community aimed at the next alignment attempt: SOA is technical and BPM is its Business related complement. Will the current BPM based alignment attempt succeed? I do not know, but Nick Heath's article titled: Stop doing what the vendors tell you, CIOs told , published in Tech Republic , suggests that the root of the problem is not Technological . Stop Doing What the vendors Tell You Nick Heath's article is based ...

Vendors Survival: Will Software AG Survive until 2019?

This post is another post in the Vendors Survival series following posts on Microsoft , Google , HP , Sun and EMC . On July 14 th Software AG and IDS Scheer announced that Software AG is going to take over IDS Scheer . The intended acquisition is an opportunity to add another post in my Vendors Survival posts series. A brief history of Software AG Mainframe products Software AG is larger than any German software company except SAP . It was established in the Mainframe age (in 1969). I worked with many customers, who used and some of them are still using, its two flagship products Adabas and Natural . Although these products support many platforms, their main platform is IBM Mainframe. Adabas is a database and Natural is a development environment. Like other pairs of Database and Development Environment in the mainframe environment (e.g. Ideal and Datacom , Mantis and Supra) build by the same vendor, they are tied together. As a result, although it is possible t...

SOA filling the Gaps

Search This Blog