Start with the current system, not the assumed design

The term "legacy system" is often used loosely to mean any software that feels outdated, but that interpretation misses the point. A legacy system is not defined by its age. It is defined by the friction it creates between what the business needs now and what the system was built to deliver.

A system becomes legacy when it still performs a necessary function but has become difficult, expensive or risky to change. The technology may be unsupported, the people who built it may have left, or the way the business operates may have shifted so far from the original design that every new requirement demands a workaround. The system is not dead — it is trapped.

This distinction matters because it changes how you evaluate your software. A ten-year-old application that is well documented, regularly updated and easily modified is not a legacy system in any meaningful sense. A three-year-old application built with a niche framework, abandoned by its developer and impossible to integrate with your current CRM may already be one.

The characteristics that actually matter

Rather than counting years, look for a combination of the following traits:

  • Dependency on outdated or unsupported technology. The programming language, framework, database or server operating system no longer receives security patches or has a shrinking pool of people able to work with it.
  • High cost of change. Even small adjustments take disproportionate time and money because the codebase is poorly structured, poorly documented or both.
  • Key-person risk. Only one or two individuals understand how the system works, and their departure would leave the business unable to maintain it.
  • Integration difficulty. The system cannot easily exchange data with newer tools, forcing manual exports, spreadsheet bridging or fragile custom scripts.
  • Knowledge gap. There is no accurate, up-to-date documentation of what the system does, how data flows through it or what business rules are embedded in the code.
  • Mismatch with current processes. The business has evolved, but the system has not. Staff work around its limitations rather than with its design.

No single characteristic on its own necessarily makes a system legacy. A key-person risk, for example, can be resolved through documentation and knowledge transfer. It is the combination — particularly when paired with a genuine business need to change — that turns a stable system into a constrained one.

Legacy systems appear across a wide range of business contexts. Understanding what they look like in practice helps you recognise them in your own organisation rather than waiting for a crisis to force the issue.

Internal tools and admin systems

A common scenario is an internal application — an order-management system, a booking ledger, a staff rota tool — originally built by a former employee or a small agency. It runs on a server in the office or an old cloud instance. It works, but nobody has touched the code in years. When the business needs to add a new reporting field or connect it to an accounting package, the estimate comes back surprisingly high, or the response is simply that it cannot be done.

The system is not broken. It is legacy because the cost and risk of adapting it now outweigh the value of what it delivers.

Customer-facing portals and CRM systems

Customer portals built five or more years ago frequently fall into this category. They may use older authentication methods that do not support modern single sign-on, or they may store data in a way that makes compliance with current privacy obligations difficult. The portal still lets customers log in and view their orders, but adding self-service features, document uploads or real-time notifications would require a level of rework that approaches a rebuild.

Custom CRM systems are similarly prone. A CRM built around the business's processes five years ago may have been perfectly fit for purpose at the time. If those processes have changed — new product lines, different sales stages, new compliance requirements — the CRM becomes a record-keeping tool rather than an operational one, and the gap between what it does and what the business needs widens with every quarter.

Systems built on discontinued platforms

Some legacy systems sit on platforms that have been formally discontinued. This includes older versions of content management frameworks, database engines that have reached end of life, or hosting environments that the provider is phasing out. The system may function correctly today, but it exists on borrowed time. When the underlying platform can no longer be patched, the system becomes a security liability regardless of how well it performs its business function.

Acquired systems

When a business acquires another company, it often inherits software that was built to different standards, on different technology, with different assumptions about data and processes. Even if the acquired system is relatively modern, it can become legacy in the context of the combined business because it does not fit the target operating model and cannot be economically integrated.

Mistaking age for legacy status

The most frequent error is assuming that old software is automatically legacy and new software is not. A system built last year with a poorly chosen stack, no tests and no documentation can be harder to maintain than a fifteen-year-old system built on stable, well-understood technology with thorough records. Evaluate the system by its current constraints, not its birthday.

Assuming legacy means broken

Legacy systems are often remarkably stable. They have been running for years, the bugs have been found and fixed, and the staff know exactly how to use them. The problem is not that they fail — it is that they cannot adapt. Treating a legacy system as if it is unreliable leads to the wrong remediation strategy. You do not need to fix something that works; you need to address the inability to change it.

Confusing legacy with end of life

End of life is a specific, verifiable status: the supplier has announced a date after which no patches or support will be provided. Legacy is a broader condition. A system can be legacy while still running on supported technology. It can also be end of life without being particularly legacy — if the business was already planning to replace it and the announcement simply accelerates the timeline. These are distinct situations that require different responses.

Overlooking data as part of the system

When assessing whether something counts as legacy, people often focus on the application code and ignore the data structure. A system with clean, well-organised data in a standard format is far easier to migrate or modernise than one with years of accumulated inconsistencies, duplicated records and undocumented fields. The data layer can be the part that makes a system genuinely legacy, even if the application itself looks manageable.

Key checks to apply

If you are unsure whether a system in your business counts as legacy, work through these questions:

  • Can you make a small, well-defined change within a predictable budget and timeframe?
  • Could a new developer or supplier understand the system from existing documentation alone?
  • Is the underlying technology still receiving security updates?
  • Can the system exchange data with your other tools without manual intervention?
  • If the person who maintains the system left tomorrow, could the business continue to operate and modify it?
  • Does the system support your current processes, or are staff routinely working around it?

Turn the assessment into a controlled next step

If the answer to most of these is no, you are likely dealing with a legacy system — regardless of when it was built. The practical question then is not what to call it, but what to do about it, which is where modernisation planning and risk assessment come in.