Why replacing legacy systems takes more than AI

The FR sat down with Paul Holland, chief technology officer of Amdocs Studios’ mainframe modernization practice, to discuss AI’s potential and limitations in updating banks’ legacy systems. Amdocs is a software and services company whose offerings include mainframe modernization.

How is agentic AI changing the way mainframe modernization projects run, compared to the traditional multi-year, phase-by-phase approach?

Agentic AI is already impacting modernization projects in three significant ways. First, by providing more autonomous and self-correcting processes, modernization projects require fewer resources. Second, an agent approach is reducing project timelines. At this time, this may not be significant, but the trend is toward projects being completed faster. Third, as a result of these two trends, modernization costs are coming down.

Having said that, I think we also need to temper some of the claims that are being made in the market. Agentic AI may accelerate some aspects of the modernization project. Areas such as code conversion have always been automated, and frankly, producing new Java or C# that compiles and runs has always been a relatively small part of a project.

Mainframe modernization projects are typically large transformation projects that require program management of many disciplines within an organization. Even with the level of automation that agentic AI brings, the nature of these programs means they will still require months or years. Vendors’ claims that agentic AI has brought modernization projects down to weeks or a few months just don’t match the reality of what these projects require.

Where is agentic AI proving most useful in mainframe modernization, and where does it still fall short?

It’s still early to judge the full impact of agentic AI on the task of modernization of mainframe applications. Having said that, changes are happening fast. Using agents for application discovery and project planning is now common. The big change with using agents to conduct automated application portfolio discovery is the level and style of documentation that can be generated from the discovery process. One very exciting capability of discovery agents is documenting the business processes and functions in the application code. This is often giving organizations a level of insight they have never had.

Many mainframe applications are 30, 40 or even 50 years old, and literally hundreds of modifications have been made to the code as the business requirements have changed. Add to this the fact that many of the subject matter experts who understood the depths of the application have moved on or retired. It is not unreasonable to say that many organizations don’t have complete knowledge of all that the mainframe applications do and how they do it.

Providing business functionality insights as well as system and technical insights is now more than achievable using agentic AI.

Another area where agentic AI is already making an impact is accelerating the testing and remediation of refactored applications. Using agents to automate the creation of test cases and drive the automated testing process speeds up this stage of the project. If we add to this agents that can help debug and remediate issues during the testing phase, then what used to be a significant part of a modernization project can be streamlined and conducted faster without reducing test coverage or quality.

The most significant area agentic AI is impacting is code transformation. Things are moving very fast in this space, and today the market seems to be focused on a “reverse engineer the old and forward engineer the new” approach. In demos, this works well, but the critical premise of this approach is the “reverse engineer the old” part. If agents can’t mine a complete understanding of what the legacy application does, then the forward engineering part of the process will generate a new application that has holes in it – either missing functionality or, worse still, functionality that the agent has guessed or made up.

While I do believe this approach has great merit, it needs to be understood that it requires even more diligence in the testing part of a project. This is especially the case when the forward engineering process is not generating a fully functionally equivalent version of what the legacy application did. The new application is often a rearchitected version of the legacy application, and therefore like-for-like testing is not an option.

What role does COBOL-to-Java conversion play in modern transformation projects, and what can make that translation difficult to get right?

Automated conversion of legacy applications from older programming languages to Java or C# is a very well-established pattern for modernizing and migrating mainframe applications. COBOL is by far the most common programming language for mainframe applications. There are billions of lines of COBOL code spread across all the world’s mainframes. COBOL-to-Java conversion is common, and there are good solutions for this transformation in the market. However, converting COBOL only gets you so far. Even if an application is predominantly COBOL, it is extremely likely that there will be non-COBOL components. For example, most applications will have some level of assembler programs included in them.

As well as COBOL, many mainframe applications are written in other legacy programming languages. Some are completely written in assembler, others in PL1. Then many are written in code generator or 4GL languages, such as Telon, CA Gen and Natural. Add to this the batch scripting languages, like EasyTrieve, Focus, REXX or CLIST.

This means that conversion of COBOL to Java or C# is not enough. Organizations need transformation solutions for a wide variety of mainframe technologies to truly be able to refactor applications to modern technology stacks.

Many refactoring vendors do not offer support for multiple legacy source languages in their conversion solutions. This leaves customers having to multisource their refactoring solutions, and this introduces a challenge of marrying the output from different conversion processes.

The issue of supporting transformation of all the varying technologies mainframe applications can be written in is certainly a challenge for the new generation of code refactoring agents. Many of the agentic AI offerings so far have not been able to tackle the non-COBOL applications that are out there.

How can organizations preserve decades of valuable business data without losing functionality or data integrity?

This is a very important question. A lot of focus is put on code transformation, but mainframe workloads are made up of code and data. Very often, the data may be stored in a Db2 RDBMS. However, massive amounts of critical business data are still stored in VSAM files or old proprietary hierarchical or network databases, such as IDMS, IMS, Adabas and even Datacom.

When building the roadmap for modernizing and offloading mainframe applications, it is critical that the plan includes ETL capabilities for transforming data to modern RDBMS platforms, such as Postgres or SQL Server.

Some organizations consider jumping all the way to non-SQL data stores. However, if the goal is to preserve functional equivalence and meet the same performance and throughput standards of the mainframe, organizations must realize that mainframe apps are fundamentally high-volume transaction processing systems, and therefore traditional RDBMS databases will match this need best.

Are financial institutions ready to trust AI in these systems, or do you see adoption trailing behind the technology?

I think financial institutions are more cautious about AI in general, and this is the case when it comes to modernization solutions, although things are changing fast. At an overall level, it is important for any agentic AI modernization solution to be able to make use of LLMs already approved by the organization and to ensure that the agents fit into the frameworks and guardrails already in place. Getting a new LLM approved by a financial institution is a major undertaking.

There does seem to be more acceptance of agentic AI as a means of application discovery and test automation. However, some financial services organizations are not so willing to accept agentic AI as a means of legacy code transformation.

How does regulatory compliance shape modernization approaches in financial services compared to other industries?

For banks, I see regulatory compliance as one of the major drivers for application modernization and even moving workloads off the mainframe.

While mainframes provide an extremely resilient and reliable platform, the cost of creating hot-hot, fully mirrored failover systems can be very high. It is proving to be more affordable to build this type of environment in open systems or in the cloud. This is prompting some banks to look at how they can position workloads in a more hybrid architecture, thereby reducing single points of failure and implementing more economical “never-down” solutions at different stages of processing.

Also, as we have already discussed, modernization, especially agentic modernization, provides an added benefit of improving application documentation and understanding. This can help greatly when addressing regulatory and governance requirements.

Finally, legacy application modernization creates an opportunity to bring these older applications into line with the current development standards of the bank. Issues like coding standards and code vulnerabilities can be addressed as part of the modernization process, tackling problems that may not have been tackled previously because of the legacy technologies used to develop and maintain the applications.

How is the definition of a "modern core system" likely to evolve over the next five years?

For banks, modernizing the core is a big issue over the next five years. Mainframe core banking systems are regarded as generation 1 or, at best, maybe generation 2 systems. In other words, their roots are old. Often, the applications are packages developed and owned by a core banking system vendor, such as Hogan and Systematics. In many cases, while the banks have source licenses to these applications and have been able to modify and customize them considerably, they do not have the rights to modernize or migrate the applications to another technology platform.

Those banks actively modernizing their applications have adopted a “strangler fig” or “strangle the core” methodology. This means focusing on the modules that surround the core and have been developed internally. This is a good approach to progressively reduce and modernize mainframe workloads, but it still leaves the legacy core system unchanged and in place. In the next five years, banks will need to address modernizing the core, and for many, the only option will be replacing the current core system with a current generation 3 or generation 4 core banking platform. This will be a big endeavor.