Legacy Modernization

Banks, insurance companies, and government agencies often work with computer programs that were written thirty or forty years ago. Such old but still indispensable systems are called legacy systems in technical jargon. They usually run stably but are difficult to change and expensive to maintain. Legacy modernization is the umbrella term for all attempts to renew these systems. This can mean rewriting them completely, moving them to more modern hardware, or merely extending them at the edges. The hardest part is almost never the technology itself, but rather the question of how to rebuild while operations keep running.

Why old systems eventually become a risk

A system that has reliably managed account balances since 1985 is not initially a problem. It becomes a problem because of its environment. Customers expect an app, regulators demand new reports, and the company wants to connect AI tools. All of this requires that the system can be changed.

That is exactly where things fall short. The program code has grown over decades, often without complete documentation. Many companies no longer know in detail why a particular rule exists in the code. Whoever removes it risks errors in unexpected places. Experts refer to this as technical debt: shortcuts from the past for which one later pays with effort.

On top of that comes a staffing problem. Many legacy systems are written in programming languages such as COBOL, which hardly anyone learns anymore. The developers who master them are retiring. Studies estimate that in the banking sector alone, billions of lines of COBOL are still in use worldwide. This mix of rising demands and shrinking knowledge makes modernization a mandatory task.

From relocation to rebuild: the common paths

The simplest variant is a pure relocation. The old program is moved unchanged to more modern hardware or into a cloud provider’s data center. In technical jargon, this is called rehosting. It lowers operating costs but does not solve a single substantive problem: the code remains just as confusing as before.

A rebuild is more elaborate. Here, the business logic is reimplemented in a modern programming language. This is risky because one must first understand what the old system actually does. AI tools are now being applied here. Language models can read old code, summarize it in sentences, and propose drafts for new code. However, the results must be checked, because such models occasionally invent plausible-sounding nonsense.

In practice, a middle path dominates, often called the strangler pattern. The comparison comes from strangler figs, which slowly grow around a tree and eventually replace it. New functions are built around the old system, and tasks are gradually redirected from the legacy system to them. Eventually, nothing important remains of the old core. This takes years but is significantly safer than an overnight switch.

Where legacy systems make the news

The issue becomes most visible in the case of failures. When a bank cannot process transfers for days or an agency fails to process applications, a botched conversion is often behind it. The COVID era also provided examples: in several countries, administrative systems could not cope with the surge because they technically dated from a different era.

For investors, legacy modernization is a business field. IT service providers earn billions from it, and cloud providers specifically court customers with old data centers. When a corporation announces a multi-year modernization program, this usually involves high one-time costs and the hope of later savings.

A common misconception is that modernization is a one-time project with a clear end. In fact, every system continues to age, including the one just completed. Experts therefore view modernization as an ongoing task. Those who regularly renew small parts avoid reaching the point where only a risky complete overhaul will help.