Legacy Systems Examples: Which Ones Are Worth Fixing, Which to Retire, and Which to Leave Exactly Where They Are

The systems on the list nobody wants to open. The COBOL mainframe that has processed payroll without incident since 1987. The AS/400 that runs the warehouse. The Microsoft Access database a retired finance manager built in 2003 that now, somehow, underpins month-end close. Every organisation above a certain size has at least one of these, and the question that never quite gets answered is not "is it a legacy system?" but "what do we actually do about it?" These are real legacy systems examples - and the honest answer to what you should do differs sharply depending on which one you are looking at.

The word "legacy" gets used as a verdict when it is really only a description. It says the system is old, or unfashionable, or no longer on the preferred vendor list. It does not say what should happen next. And the absence of that distinction is expensive. Organisations spend money modernising systems that were perfectly fine, and they defer decisions about systems that are quietly blocking growth, because both get filed under the same label.

What follows is a category-by-category look at the most common legacy systems examples, what actually makes them difficult, and where the honest verdict lands. Some of these should be modernised. Some should be retired. And some should be left exactly where they are.

What makes a COBOL mainframe a legacy system, and what should you do with one?

The mainframe running COBOL is the most cited legacy systems example in any modernisation conversation, and it is also the most misread. The Stack Overflow Developer Survey consistently shows COBOL near the bottom of the list of languages developers want to work with. That is a talent and succession problem. It is not a performance problem.

Mainframes process somewhere in the range of 95 percent of ATM transactions globally, according to IBM's own figures - which should be treated as self-interested but are consistent with what practitioners report. What makes them genuinely difficult is not that they are slow or unreliable. It is that the business logic embedded in them was written by people who have retired, was never fully documented, and cannot be extracted cleanly without a multi-year mapping exercise.

The honest verdict on a COBOL mainframe is usually not "replace it" but "wrap it and reduce the dependency over time." The strangler fig pattern - documented by Martin Fowler and applicable here - involves building new capability around the mainframe rather than inside it, until the mainframe's surface area shrinks to a manageable core. That takes five to ten years on a large estate and requires the discipline to actually decommission the pieces that have been wrapped, which most organisations do not follow through on.

The case for leaving a COBOL mainframe completely alone is strongest when it handles a narrow, stable function - payroll calculation, for instance - with no integration pressure and no regulatory driver for change. If it processes accurately, runs reliably, and nobody needs it to talk to a system it currently cannot reach, the cost and risk of touching it exceeds any benefit.

Where it tips toward action is when skills atrophy to a single person, when the business needs to change the logic and cannot, or when the data trapped inside it is needed by systems that cannot currently reach it. Those are the conditions that justify investment - not the age of the code.

Why are AS/400 systems still running, and are they actually a problem?

The AS/400 is perhaps the most underestimated system on any modernisation shortlist. IBM released the platform in 1988, and organisations running it today are often running it on hardware that is current and software that IBM continues to support. The name changed; the platform did not retire.

What makes AS/400 a complicated legacy systems example is that the application layer sitting on top of it is often genuinely old, written in RPG - a language that now commands contractor rates above the market average precisely because few people under forty know it. The platform itself is not the problem. The application code, and the institutional knowledge embedded in it, frequently is.

The distribution company running inventory management on an AS/400 is not necessarily in trouble. If the system tracks stock accurately, integrates adequately with the warehouse floor, and the team knows how to operate it, the question is not "why are we still on this?" but "what would we gain by leaving?" If the answer is "a modern API so we can connect it to the e-commerce platform we just acquired," that is a real driver. If the answer is "it would feel more modern," that is not.

The mistake organisations make with AS/400 is treating it as embarrassing rather than assessing it on outcomes. The assessment question is: what does it cost to run, what does it currently block, and what would a replacement cost compared to building the specific integration point the business actually needs? Often the integration point is cheaper and safer than the full replacement, and the right answer is to build the bridge, not demolish the building.

What about the Microsoft Access database someone built in finance?

This is the legacy system that never appears on the official application inventory because it was never formally purchased, approved, or deployed. Someone built it. It solved a problem. And then it became load-bearing.

The month-end close process that depends on an Access database, the HR team's headcount tracker that feeds the board pack, the operations spreadsheet-turned-database that calculates job costing - these are consistent legacy systems examples in every sector. Gartner's application portfolio management work consistently identifies "shadow IT" as an underestimated risk category, particularly because these systems are excluded from formal assessments and therefore never rationalised.

The risk profile here is specific. These systems typically have no backup regime. They have no access controls worth the name. They are maintained by someone who also has a full-time job doing something else. When that person leaves, the organisation discovers simultaneously that the system cannot be operated and that it cannot be replaced quickly because nobody documented what it does.

The verdict on a critical Access database is almost always "retire and replace," but the replacement does not need to be complex. The business process it supports is usually narrow enough that a modern low-code tool, a properly licensed SaaS product, or a well-structured spreadsheet with version control handles it adequately. The investment is in the documentation exercise - understanding what the system does before the person who built it is unavailable to explain it.

The exception is the Access database that has grown to contain genuinely complex logic over fifteen years of iteration. That is a different problem, and it deserves a proper assessment rather than a quick swap.

Are ERP systems from the 1990s and 2000s a category of legacy system worth modernising?

These are the systems that generated most of the failed transformation projects of the 2000s and 2010s. The Standish Group CHAOS Report has consistently found that large ERP implementations have high rates of cost overrun and schedule overrun - the 2015 report put overrun rates for large projects above 50 percent, measuring projects against their original budget and timeline, which is the relevant figure here.

An ERP from 1998 running finance, procurement, and inventory for a manufacturing business is a genuinely difficult case. The system is probably stable. It is probably deeply customised, which means the vendor's standard upgrade path does not apply cleanly. The customisations were built by a consultancy that no longer exists, documented in a project folder nobody can locate, and maintained by a team that learned by doing rather than by reading specifications.

The cost to run it is often lower than the market rate for its replacement, because the licences were bought long ago under different terms. The cost to change it is high, because every change requires reverse-engineering what the customisations do before anyone can safely modify them.

The honest question for a 25-year-old ERP is: what is it blocking, and can that be solved without replacing the whole system? A reporting modernisation that moves data from the ERP into a contemporary analytics layer costs a fraction of an ERP replacement and may solve 80 percent of the business's frustration. That is not a reason to defer the ERP decision forever, but it is a reason to separate the two questions.

Where full replacement becomes defensible is when the vendor has ended support, when the system cannot be integrated with anything the business now needs, or when compliance obligations require capabilities the system cannot support. Those are real drivers. "It is old" is not.

What do Visual Basic 6 and Oracle Forms applications tell you about risk?

This is the category where platform risk dominates the assessment. A system written in a language or on a platform the vendor no longer supports faces a specific cliff: the day the operating system it runs on stops being updated, or the browser plugin it requires disappears, or the hardware it runs on is no longer manufactured. That is not a hypothetical. Oracle Forms applications that relied on the Java plugin in browsers hit exactly this cliff when browsers dropped plugin support, and organisations scrambled to extend their lives through thin-client workarounds that were never intended to be permanent.

Visual Basic 6 is in a similar position. The runtime still works on current Windows versions because Microsoft has been careful not to break it, but that goodwill could end. The developer ecosystem has effectively dissolved. Finding someone who can maintain a VB6 application competently is possible but increasingly expensive, and the pool of candidates is not being replenished.

What these systems share is that the risk is external and not entirely in the organisation's control. A COBOL mainframe runs on hardware IBM still sells and supports. A VB6 application runs on a platform where the trajectory is clearly terminal. That is a material difference for a risk assessment.

The verdict on a VB6 or Oracle Forms application is usually "plan for replacement, but define the trigger before you start." The trigger might be a specific operating system end-of-life date, or the retirement of the last person who can maintain it, or a compliance requirement the system cannot meet. Setting the trigger in advance is better than reacting to the crisis.

The exception is a VB6 application that runs on an isolated machine, performs a specific industrial task, and has no network exposure. Some of these are running equipment that the business could not replace anyway. Leave it, monitor the hardware, and document what it does in enough detail that a crisis replacement is feasible.

What about mainframe and mid-tier systems in government?

The government context deserves its own section because the modernisation calculus is different. A commercial organisation can decide to accept the risk of a failed ERP replacement and recover. A government department that fails to process benefits or tax returns correctly faces consequences that are political, legal, and immediately visible to millions of people.

McKinsey's research on government technology transformation - read with the caveat that McKinsey also sells transformation programmes and so has a structural interest in recommending modernisation - consistently identifies government as having the largest concentration of aging systems. The US Government Accountability Office has periodically published lists of "legacy systems most in need of modernisation," measuring systems by age, running cost, and risk of failure. The systems that appear on those lists are not there because anyone forgot about them. They are there because replacing them is genuinely hard.

The government legacy system that has not been touched in decades is frequently an engineering achievement, not a failure. It has absorbed thirty years of regulatory change, budget cuts, and staff turnover, and it is still processing accurately. That does not mean it should run forever. It means the replacement decision should be made with clear eyes about what the system is actually doing, not dismissed as an embarrassment.

The honest modernisation path for large government systems is almost always incremental: expose the data through a modern API layer, build new citizen-facing services on top, and reduce the surface area of the core system over a decade rather than attempting a single replacement. That is slower than a vendor will suggest and more realistic than a minister will want to hear.

Frequently Asked Questions

What are examples of legacy systems still in use today?

Common examples include COBOL-based mainframes in banking and government, AS/400 systems in manufacturing and distribution, Microsoft Access databases used as departmental reporting tools, Oracle Forms applications from the 1990s, and bespoke Visual Basic 6 systems built for a single business process and never replaced. Many run without issue; others quietly block every adjacent improvement.

Should a legacy system always be replaced?

No. Replacement is one of four verdicts. A system that is stable, well-understood, cheap to run, and not blocking anything else is frequently best left alone. The cost and risk of replacement often outweighs any benefit, particularly when the system handles a narrow, unchanging function and no integration pressure exists.

What makes a system a legacy system in a practical sense?

A system becomes a legacy system when it costs more to change than the change is worth, when it cannot connect to the tools the business now needs, or when institutional knowledge of how it works exists only in the heads of two or three people approaching retirement. Age alone is not the definition.

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

Assess four variables: the business value the system still delivers, the technical condition it is in, the cost of keeping it running, and what it blocks. High business value with poor technical condition points toward modernization. Low business value regardless of condition points toward retirement or replacement with something simpler.

What does it cost to run a typical legacy system?

Running costs vary widely, but organisations frequently undercount them. Direct costs include licence fees, specialist contractor rates for skills like COBOL or RPG that now command a premium, and hardware maintenance. Indirect costs include the developer hours spent working around integration gaps and the opportunity cost of features that cannot be built because the system cannot support them.

Why do organisations keep legacy systems running for decades?

Because replacement is genuinely hard and genuinely risky. The system often holds data in formats nobody has fully mapped. The business rules encoded in it were never written down. A replacement project that fails mid-flight leaves the organisation worse off than the original system did. These are rational reasons for caution, not simply institutional inertia.

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

Technical debt is accumulated within a system: shortcuts taken during development that now slow every subsequent change. A legacy system is a whole application that the organisation has outgrown, regardless of its internal code quality. A legacy system often contains technical debt, but technical debt does not automatically make something a legacy system.

When is the strangler fig pattern the right approach for a legacy system?

When the system is too risky to replace in a single cut-over, still delivers genuine business value, and has interfaces stable enough to route traffic around. It is not appropriate when the system has no clean interface boundary, when the team does not have the discipline to maintain two parallel systems, or when the underlying data model is so tangled that extraction is itself the hard problem.