When does a system become legacy?

A couple of years ago, I did some work with a client’s legacy system. But this wasn’t an ancient relic written in COBOL or Assembler; it was a relatively new C++ application. Let’s call it “App1.” So, when did App1 become “legacy?” When did my client’s relationship with it sour?

A stale relationship?

The UK Government defines legacy IT as “outdated and often obsolete technology.” Or in other words, too old. But when is an application too old?

It’s unlikely my client was bored with App1 when it was first commissioned. Even after a honeymoon period, there would have been years when things were going along just fine. But somewhere along the way, the relationship went downhill.

The Linux operating system was created in 1991, now over 35 years old. Yet it’s still a key server operating system, not exactly outdated. Java was created in 1995, but at 31 years old remains a strategic programming language. Although not a baby, App1 was younger than both: around 15-20 years old at the time. Some may be happy in a 20-year relationship; others will be ready for something else far before this.

Although something becomes legacy with time, there’s no set timeframe for when this happens. It could be 35 years; it could be one. Something happened in the past to make App1 legacy. But, what?

Money issues

The Australian government says that legacy applications can be, amongst other things, “no longer cost-effective.” Like the US government, many organizations spend a lot of their money on legacy systems. But are they really more expensive?

Many believe so. A study by banking consulting firm Digital Bank Expert states that modernizing legacy IT infrastructure has reduced banks’ TCO by up to 52%. Not everyone agrees. HPE NonStop expert Justin Simonds agrees with Rocket Software that legacy systems aren’t as expensive as many think.

Something doesn’t have to cost more to become legacy: it only needs people to believe it. My application client was aware of costs, but that didn’t seem a big deal. But it was very different for the mainframe infrastructure team and management. Multiple CIOs had set a direction to move away from the mainframe because of its perceived cost alone.

Like a frog in hot water, there probably wasn’t a particular time when my client’s legacy application costs became a problem. But at some point, they were noticed, and this crack in the relationship grew.

Misunderstood

Legacy skills are a key concern to many of my clients. They lament the lack of COBOL and Assembler programmers, and staff that understands the mainframe. Like many other clients, they have had little interest in training new graduates, despite options like those from IBM. Understanding the technology or programming language isn’t enough. Legacy systems can be complex, taking even the best experts time to understand.

My clients had lost most of their technical knowledge of App1 as older experts retired and weren’t replaced. To mitigate this, they relied on a service provider, who themselves had issues finding staff. This probably became apparent to my client when one of those staff retired, or their service provider struggled to fix a problem.

Not feeling safe

In 2022, Fujitsu announced the retirement of their legacy GS21 mainframes, ending support in 2035. Telling your partner that it’s over is unlikely to help the relationship, even if it is 13 years in the future. If GS21 clients didn’t consider their mainframe legacy before 2022, they do now.

All systems require a technology stack supported by someone providing fixes and help to keep it running: vendors or staff. But as highlighted by the US GAO, a big reason for support is security. High-profile issues like the Apache log4j vulnerability were only fixed for supported systems.

GS21 mainframes are older technology, missing basic operating system enhancements like 64-bit addressing. So, GS21 users will have considered it legacy far before 2022. Is this when something becomes legacy – when it stops changing or innovating?

App1 ran on IBM’s flagship IBM Z mainframe: hardware less than two years old. The rest of the technology stack was similar: recent versions of the z/OS operating system and CICS transaction manager with regular security patches and fixes. In fact, a 2025 survey by ITIC found that IBM Z mainframes had the lowest downtime due to security hacks of any platform. Security wasn’t an issue.

Another non-issue was an inert technology stack. The IBM Z mainframes ecosystem continues to adapt with features like onboard AI functionality, new languages like Python and Node.js, and support for Java SpringBoot applications. But the stack was still seen as legacy, and that’s all it takes.

A big issue was the application itself. There had been no major enhancements for many years, and my client had little interest in leveraging the new IBM mainframe goodies. Few changes meant that support staff had less experience in making changes, which slowly morphed into a culture where changes were resisted by the supporting teams.

At the same site, another application group was making big changes to their application: moving from a legacy file-based storage system to Db2. Despite this, that second application was also considered legacy. Innovation isn’t guaranteed protection against the legacy label.

Despite using an active and secure technology stack, App1 itself was stagnant. This didn’t happen in an instant, but was a result of ongoing management decisions, helping App1 win the legacy badge. But this wasn’t the only issue.

Not enough from the relationship

The user interface of App1 was old: old web pages, and even some 3270 screens, like relying on a UNIX Telnet screen. This was fine when the application was first created, but unpopular today. They could have leveraged some of that new IBM mainframe technology but could not get the budget. The old screens were there to stay.

Changing legacy systems is always harder than creating new ones. As it gets older, it has more history and becomes more complicated. Any change must satisfy the requirement but also avoid breaking anything else. This ‘technical debt’ can slow down changes, frustrating a business that isn’t standing still. My client felt this, with changes requiring weeks to be migrated into production. Legacy systems can be mission-critical, and there was little tolerance for an outage of App1.

No one wants a partner that they’re ashamed of taking out in public, and none saw App1 as attractive. And it’s not just the user interface. I had another client ready to move their application from the mainframe simply because of marketing: a flagship system running on the mainframe was not sexy.

When did App1 become difficult and ugly? Perhaps when the business needed a change that could not be made. Or when a manager saw the old interfaces and didn’t like them.

The moment it changes

There’s no official definition of ‘legacy,’ no metric or equation to calculate when something becomes legacy. But the answer is simple: App1 became legacy the moment my client started looking for something better. I don’t know when that was: it’s unlikely there was a ‘eureka’ moment.

Senior management fell out with App1 because of the perceived cost; the business unit because the unattractive application resisted change. The application support team was also ready to move on, with few staff capable of supporting App1.

The last time I talked with my client, the relationship hadn’t ended yet. They were on the IT application equivalent of dating apps, while their legacy relationship continued to do their critical processing. The reasons they disliked App1 weren’t enough to overcome the cost and risk of moving away.

It’s not too late for this relationship. My client could refresh it: train new staff, invest in new technologies. More likely, things will reach a breaking point, and my client will swipe right and move on.