Legacy Systems Examples: The Systems Nobody Wants to Touch, and Which Ones Should Stay That Way

Somewhere in your organisation, there is a system that nobody touches without a planning meeting first. It runs something important - payroll, claims, reservations, billing - and the documentation for it either does not exist or was last updated when the person who wrote it still worked there. These are the legacy systems examples that never make it into vendor brochures, because the honest story of what they are and what to do with them is more complicated than any sales deck wants to admit.

The problem with the conversation about legacy systems is that it has been colonised by people selling the replacement. That means the framing is almost always: here is the risk, here is the pain, here is the modern alternative. What it rarely includes is a serious examination of which legacy systems are genuinely causing harm, which are quietly doing their job, and which the organisation would be significantly worse off for touching.

This article names real categories of legacy systems, describes what they are actually doing, and offers an honest account of when the case for intervention is strong, when it is weak, and when the right answer is to close the meeting and leave the system alone.

What counts as a legacy system, and why do the examples matter?

The word legacy is used so loosely that it has almost stopped carrying information. Executives hear it and think "old". Developers hear it and think "code I did not write". Neither definition is precise enough to make a decision on.

A more useful working definition - explored in depth in a previous post on this site - is that a legacy system is one where the cost of change has become disproportionate to the value of the change, or where the system actively constrains what the organisation can do. Age is a contributing factor, not the defining one.

The examples matter because the type of legacy system determines what your options are. A 40-year-old COBOL mainframe running 300,000 transactions a day is a fundamentally different problem to a 2008-era Oracle Forms application used by 12 people in accounts receivable. Both get called "legacy". One might need a ten-year programme to address safely. The other might need six months or a managed retirement.

Naming the specific system type is the first discipline. The second is refusing to let the name carry an implicit verdict.

What are the most common legacy systems examples in large organisations?

COBOL mainframes

COBOL - Common Business-Oriented Language - was designed in 1959 and standardised across the banking and insurance industries in the 1960s and 1970s. The systems built on it are not legacy because the language is old. They are legacy because they encode decades of business logic that was never documented separately from the code itself, run on hardware and operating environments that require specialist knowledge to manage, and interface with adjacent systems through fixed-format file exchanges and batch processes that the rest of the organisation has since moved around.

According to Micro Focus research, more than 95 billion COBOL transactions are processed daily, mostly in financial services. That figure measures transaction volume, not system count. What it reflects is that these systems are still at the centre of the most critical financial processing in the world, not at the edges.

The case for replacing a COBOL system is frequently made on the grounds of talent scarcity. The number of COBOL developers is declining. That is true. But the case is weaker than it appears, because the alternative - a full rewrite - requires understanding what the COBOL system is doing well enough to replicate it. That understanding almost never fully exists. The Australian government's attempt to replace a COBOL-based welfare payment system resulted in a project initially estimated at around AUD 1 billion, with costs rising significantly over its lifecycle and ongoing delivery challenges well documented in government audit reports. The COBOL was not the problem. The problem was the complexity that the COBOL had been accumulating for decades.

IBM AS/400 and iSeries applications

The AS/400 platform, now branded IBM Power and running IBM i, was introduced in 1988 and became the dominant platform for manufacturing, distribution, and mid-market business applications through the 1990s. Applications written in RPG (Report Program Generator) on this platform are among the most common legacy systems in mid-market industrial and logistics companies.

These systems are genuinely difficult to categorise. The underlying platform is actively maintained by IBM. RPG has had modern language extensions added. Many AS/400 applications are running core operations - inventory, order management, plant scheduling - with reliability that cloud-native alternatives have not consistently matched. The question is not usually whether the platform is old. It is whether the application logic has accumulated so much customisation over 25 years that it no longer matches what the business actually does.

MUMPS-based healthcare records systems

MUMPS (Massachusetts General Hospital Utility Multi-Programming System) was developed in the late 1960s and became the foundation for many electronic health record platforms, most notably Epic and VistA, the Veterans Health Administration's patient records system. VistA has run across the US Department of Veterans Affairs for decades and has been the subject of repeated modernization programmes, the most recent a multi-billion-dollar programme to replace it with a Cerner (now Oracle Health) platform that has faced significant cost and schedule difficulties, as documented in VA Office of Inspector General reports.

The lesson from VistA is not that legacy healthcare systems are fine. It is that the complexity embedded in a system running clinical operations for millions of patients over decades does not disappear when you buy a replacement. It reappears as implementation problems, data migration failures, and clinical workflow disruptions.

Oracle Forms and PowerBuilder desktop applications

Oracle Forms and PowerBuilder represent a generation of client-server development tools widely used in the late 1980s and 1990s to build data-entry and reporting applications. These applications are legacy in a more straightforward way: Oracle ended mainstream support for older Forms versions, PowerBuilder has a small and declining developer base, and the applications typically run on Windows infrastructure that is itself becoming harder to maintain.

These are cases where the modernization argument is usually strongest - not because the systems are failing, but because the operational cost of keeping the surrounding environment alive is rising, and the talent pool to maintain them is genuinely shrinking faster than for the mainframe technologies.

Custom ERP platforms built between 1990 and 2005

Before SAP and Oracle ERP became widely accessible to mid-market companies, many organisations built their own enterprise resource planning systems. These are typically the most dangerous category to touch. They encode the specific way a particular business runs: its pricing logic, its customer hierarchy, its production sequencing rules. That logic was built by people who have since retired or moved on. It is embedded in stored procedures, batch jobs, and integration points that have been modified hundreds of times. The organisation often does not know what the system does in full - it only knows what happens when it stops.

Which legacy systems are worth leaving alone?

This is the question that rarely gets asked directly, so it is worth spending time on it.

The Gartner TIME model - Tolerate, Invest, Migrate, Eliminate - gives portfolio managers a framework for categorising applications, and "Tolerate" is a legitimate answer. It means: this system has low strategic value and low technical quality, but the cost of changing it exceeds the benefit. Leave it. Run it down. If it fails, retire it; do not rebuild it.

What is less often said is that some high-criticality, low-change systems also belong in a holding pattern. Consider:

A COBOL batch processing system that runs end-of-month financial reconciliations. It runs once a month. It has run correctly for 22 years. The business process it supports has not changed materially. The team has three people who understand it. Replacing it carries a multi-million-pound programme risk. Leaving it running costs less than £200,000 a year in infrastructure and support.

The case to leave it alone is straightforward, and any consultant who opens a discussion about that system with "we need to modernize this" should be asked what problem they are actually solving.

The systems worth leaving alone share characteristics: stable underlying process, low frequency of required change, contained and understood maintenance cost, and no meaningful constraint on what the business wants to do. When all four are true, the burden of proof falls on the case for change, not the case for staying still.

When does a legacy system become a problem you cannot defer?

Deferral is a rational strategy until it is not. The organisations that get into genuine trouble with legacy systems are rarely the ones who made a considered choice to leave them alone. They are the ones who deferred indefinitely without monitoring the conditions that would change the calculus.

The people problem is the one that tends to arrive without warning. A mainframe team of four becomes a team of two when two people retire. The remaining two are now single points of failure for a critical system. When one of them leaves - for any reason - the organisation discovers that institutional knowledge cannot be reconstructed from documentation, because the documentation was never written.

The Stack Overflow Developer Survey consistently shows COBOL as one of the least-used languages among working developers. That does not mean the people maintaining COBOL systems are impossible to find, but it does mean they are increasingly expensive and decreasingly available. For a CIO managing a mainframe estate, that is a workforce planning problem, not just a technology problem.

The infrastructure support problem is more predictable but equally ignored. When a vendor ends support for a platform - as IBM has done with older AS/400 operating system versions, as Oracle has done with Forms - the organisation faces a choice: pay for extended support at premium rates, upgrade the platform (which requires testing every application on it), or accelerate modernization. All three options have costs. The only one that is genuinely free is the one that was already in place: a managed plan.

The regulatory constraint problem has become more acute in financial services and healthcare, where real-time reporting requirements, open banking standards, and interoperability mandates require systems to expose data and processes through interfaces that many legacy platforms were never designed to support. A COBOL system that cannot produce a JSON response to an API call is not broken. It is constrained, and the constraint is now a commercial and compliance problem, not just a technical one.

What does a legacy system replacement actually cost, and why are early estimates wrong?

The Standish Group CHAOS Report has tracked IT project outcomes since 1994. Its methodology has limitations - it surveys project managers and uses self-reported data, and its definitions of "success", "challenged", and "failure" have shifted across editions, so any specific percentage from it should be treated as directional rather than precise. What its longitudinal data consistently shows is that large IT projects overrun budget and schedule at rates far higher than initial plans anticipate, and that the larger the project, the worse the overrun tends to be.

The specific pathology of legacy replacement is well documented in post-mortems. The pattern is consistent: the organisation scopes the replacement based on what it believes the legacy system does. It discovers, 18 months into the programme, that the legacy system is doing additional things nobody mentioned in the scoping exercise because nobody thought to mention them. Those things are not undocumented because anyone was negligent. They are undocumented because they were obvious to the people who built them, who have since left.

The honest risk figure for a legacy replacement programme is not in the initial business case. It is in whether anyone has done a disciplined inventory of what the system does before the estimate was written.

This is the reason independent assessment exists as a service distinct from implementation. A firm that also builds the replacement has a structural incentive to begin the programme. A firm that only assesses has an incentive to tell you what the programme will actually cost and what it will actually find.

Konnectedly's model is built on that distinction: the assessment is the product, and there is no implementation revenue to protect.

Frequently Asked Questions

What are common examples of legacy systems still in use today?

COBOL-based banking and insurance mainframes, RPG applications on IBM AS/400 or iSeries platforms, Oracle Forms and PowerBuilder desktop applications, MUMPS-based healthcare records systems, and custom ERP platforms built in the 1990s on early Microsoft or Delphi stacks are all widely documented examples of legacy systems actively running critical operations in large organisations today.

Does a legacy system always need to be replaced?

No. A system running a stable, well-understood process with no growth requirement and low maintenance cost is often best left alone. The case for replacement must be built on what it costs you in constraints, not on the age of the technology. Many mainframe COBOL systems process more reliably than their proposed replacements.

What is the biggest risk of replacing a legacy system?

The biggest risk is not the new platform - it is incomplete knowledge of what the old system does. Decades of undocumented business logic embedded in legacy code is routinely underestimated. Projects fail or massively overrun when the replacement team discovers the original system was doing things nobody had written down and nobody remembered commissioning.

How much does it cost to maintain a legacy system versus replacing it?

Maintenance costs vary enormously by system type, but Gartner research on application portfolio management consistently identifies that organisations running fragmented legacy estates spend 70 to 80 percent of their IT budget on keeping existing systems running, leaving very little for new capability. Replacement projects routinely cost two to five times initial estimates when undocumented complexity is discovered mid-project.

What is COBOL and why is it still used in banking?

COBOL is a programming language from 1959, designed for business data processing. Banks still run COBOL because the code works, the systems have been tuned for decades, and the volume of transactions they handle - estimated at over 95 billion transactions per day globally according to Micro Focus - exceeds what any modern rewrite has been proven to match at equivalent cost and reliability.

How do you decide whether to modernize or leave a legacy system alone?

The decision rests on four factors: what the system costs to run and maintain, what it prevents you from doing, whether the people who understand it are leaving, and whether a replacement carries credible cost and risk estimates. If all four point toward intervention, modernize. If only one does, the case is probably not strong enough yet.

What is the difference between a legacy system and technical debt?

A legacy system is an application that creates operational constraint regardless of why it was built. Technical debt is the accumulated cost of past shortcuts in any system, old or new. All legacy systems carry technical debt, but not all technical debt lives in legacy systems. A five-year-old microservice with no tests and no documentation can carry more damaging technical debt than a 30-year-old mainframe.

What industries have the most legacy systems?

Banking, insurance, government, healthcare and utilities carry the heaviest concentrations of legacy systems. These are sectors where core processes were computerised early, often in the 1960s and 1970s, have run continuously since, and face high regulatory and reliability requirements that make replacement genuinely risky rather than just organisationally difficult.