Legacy system
A legacy system is a system the business still depends on that has become hard or risky to change: its platform may be out of vendor support, few people may understand it, and its tests or documentation may be missing. Age alone does not make a system legacy; dependence plus the cost of change does.
Submit a project Assess a legacy systemReviewed by Huy Nguyen (David), CEO · Updated 21 Oct 2026 · 4 min read
This term is one of the entries in the OutsourcingVN glossary of words buyers meet while deciding what to do about an old system.
Why does a legacy system matter?
A system that is merely old but still supported, well documented and safe to change is not a risk in itself; the label matters once a change to that system becomes expensive or uncertain enough to shape a roadmap. OutsourcingVN is operated by Netbase JSC, and the practical reason to name a system as legacy is to stop treating a quick-looking request on it as quick: a one-line fix on a system nobody fully understands anymore can cost far more than the same fix on a well-maintained one, and carries a real chance of breaking something unrelated.
What is an example of a legacy system in practice?
A retailer runs its order processing on a platform whose vendor stopped issuing security updates two years ago, maintained by one remaining engineer who wrote most of it, with no automated tests covering the discount and tax rules. A new feature request that looks like a day's work turns into a week, because nobody can say with confidence what else the discount logic touches, and the one engineer who could answer quickly is on leave. The system is not legacy because it is old; it is legacy because the business depends on it and almost nobody can safely change it.
What are the common misreadings of a legacy system?
A legacy system is not the same as technical debt: see the technical debt definition for that distinction, since technical debt is a property of the code itself — shortcuts taken for speed — while a legacy label describes the system's overall position, including its support status, its concentration of knowledge and the business's dependence on it; a young codebase can carry serious technical debt without being legacy, and an old, well-supported, well-documented system can carry very little. A vendor's own end-of-support date for a specific version is the kind of fact that belongs in this assessment, not a general impression that a system "feels old."
Plan the next step for your project
Common questions
Not necessarily. Some legacy systems are stable enough to run as they are for years once the real risks are named and accepted, with a review date attached to each one.
Yes, if it already depends on an unsupported component, is held up by one or two people, or has no tests covering its business rules; a system earns the label from its condition, not its birth date.
Which decisions does a legacy system affect?
Deciding what to do about one — accept the risk, modernize in stages, or replace it — starts with an inventory of what the system is, where its rules live, what it depends on and who holds it up, which is the subject of the legacy system risk assessment guide. Once that assessment exists, the legacy system modernization guide plans the route from the finding to a scoped programme of work. When you know which system is holding your roadmap back, describe it and Netbase will respond through Netbase's own outsourcing-services platform; submit a project when you are ready.