A legacy system is an existing system whose continued operation or change is constrained by unacceptable risk, operating burden, or loss of the capability needed to maintain it. Age describes when the system was created; legacy status describes a problem with its continued use.
The boundary is contextual. A program that meets one organization’s needs can impose an unacceptable constraint in another organization with different recovery requirements, staffing, or transaction volumes. Calling a system legacy therefore requires both a description of the system and a statement of the requirement it cannot adequately meet.
Three distinct judgments
Age is a historical property. Support status is a relationship between a product, version, supplier, and service commitment. Operational suitability is a judgment about the deployed system against its required business role. These properties interact, but none is a substitute for the others.
An application can run successfully while depending on a component for which new defects cannot be repaired. That is a support problem even before the component fails. Conversely, a supported product does not establish that the organization can restore its own deployment or find someone able to change its business rules.
The UK public-sector definition updated in August 2026 explicitly places operating burden and risk ahead of age or technological fashion. It includes inadequate maintenance knowledge and dependence on another legacy component. That definition supplies a classification within its administrative context; it does not establish a universal threshold for every organization.
The deployed combination
The assessment unit is the combination that performs the work. Source code, runtime, operating system, database, integrations, identities, and supporting people participate in that combination. A supported application release running with an unsupported driver still contains a dependency whose disposition must be explained.
Possessing source code establishes access to one artifact. It does not establish a usable compiler, a reproducible build, rights to redistribute a component, or a maintainer who understands an exception path. Those are different capabilities with different evidence.
Suppose a company has two applications written in the same language. One has a working build, tested recovery, documented interfaces, and two available maintainers. The other runs from an executable on one workstation, with no recovered build or known replacement for an attached device. The common language does not explain the difference in their operational constraints.
Classification does not select treatment
A diagnosis identifies the missing capability. A treatment changes the conditions that produced the diagnosis. If the decisive problem is an unsupported database driver, a driver or connection change addresses a different scope from replacing the entire business application.
If the work itself is no longer required, retirement addresses a different problem again. Rewriting an unnecessary workflow preserves its operating burden in a new implementation. If the business need continues but the current implementation cannot support it, replacement becomes a candidate whose transition costs and risks still require assessment.
Containment and final disposition also answer different questions. Restricting exposure can reduce an immediate risk while a replacement is prepared. It does not create new vendor fixes or establish that the retained system is suitable indefinitely.
A reviewable legacy assessment
A useful assessment names the required outcome, the constraint, the evidence, and the condition under which the judgment changes. “Old database” names a technology. “The available recovery procedure cannot restore the required records within the agreed interruption window” identifies a testable operational problem.
The same structure supports reassessment. Recovering the build changes the maintainability evidence. A newly unsupported dependency changes the support evidence. A business process ending changes the remaining value of the application. Legacy status is therefore a dated judgment about a deployed system and its obligations, rather than a permanent attribute inherited from a programming language.