What is a legacy system?
A legacy system is a system that still carries the business but runs on technology or knowledge that's become hard to maintain and change. Legacy isn't about age – even a five-year-old system can be legacy if no one dares touch it. The ways forward are to wrap it, modernize it step by step, or replace it entirely.
Legacy system is a phrase that’s often said with a sigh. It’s associated with dusty, ancient systems that should have been retired long ago. But that image misses the point, and it can lead to the wrong decisions. Here’s what a legacy system actually is, how to recognize it, and what you can do about it.
Legacy means hard to change, not old
The most common misconception is that legacy is synonymous with old. That’s not true. A legacy system is a system that still carries the business – it does useful work every day – but that’s built on technology or knowledge that’s become hard to maintain and change.
Age is secondary. A twenty-year-old system that’s been well maintained, documented, and kept alive doesn’t have to be legacy. At the same time, a system built five years ago can already be legacy if it was built messily, if the people who built it are gone, and if no one dares touch it anymore. It’s changeability that decides, not the number of years.
With that definition, legacy becomes a question of risk and workability, not the technology’s birth year.
The warning signs
Legacy usually creeps up on you. There’s rarely a single day when a system “becomes” legacy, but there are clear signs that it’s happened:
- One person knows the system. The knowledge lives in a single employee’s head, and everyone knows nothing can be allowed to happen to that person. This might be the strongest signal of all.
- No one dares upgrade. Every proposal to update a component or change something is met with worry about what might break, so it doesn’t happen – and old technology and security holes keep dragging along.
- Documentation is missing or wrong. Whatever was once written down is out of date, and the truth exists only in the code and in a few people’s memory.
- Everything takes disproportionately long. Even small changes become expensive and slow, because no one really has an overview of the consequences.
If you recognize more than one of these, you very likely have a legacy system – no matter how new it feels.
A concrete scenario
A company runs its order handling in a system built in-house eight years ago. It works, but only one of the original developers is still around, and they’re the one who fixes everything when it breaks. There’s no documentation worth the name. When they take an extended leave, the company barely dares touch the system. A new integration that should take two weeks drags on for months, because no one else understands how the pieces fit together.
The system isn’t old in years, but it’s legacy in every meaningful sense: the business depends on something no one fully masters anymore, and the fear of touching it holds the business back.
Three ways forward
Once you’ve identified a legacy system, there are essentially three strategies, with different risk and cost:
- Wrap it. Leave the system in place, but build a protective layer around it so new parts can connect without touching the core. Fast and low-risk, but it doesn’t solve the underlying problem.
- Modernize step by step. Replace one part at a time while the system keeps running, until the old parts are gradually replaced. Takes longer but keeps risk low and the business running.
- Replace it. Build a new system and switch over. Gives you a clean start but is the riskiest and most costly path, especially if everything is switched at once.
Which path is right depends on how business-critical the system is, how big the risk is, and what the budget allows. For most systems that genuinely carry the business, step-by-step modernization is the safest line.
Taking the next step
Start with an honest mapping: what depends on the system, who knows it, what happens if it fails? That picture determines how urgent it is and which path fits. If you’d like help assessing a legacy system and choosing the right strategy, at Weapp we’re happy to do the review together before you commit to a path.
Frequently asked questions
Does legacy just mean the system is old?
No, that's the most common misconception. Legacy is about the system being hard to change and maintain, not about how many years it's been around. A well-maintained system can be twenty years old and not be legacy, while a messy system can become legacy within a few years. It's changeability that decides, not age.
How do we know we have a legacy system?
The warning signs are clear. A single person knows the system and becomes indispensable. No one dares upgrade or change anything for fear of breaking it. Documentation is missing or out of date, and every new feature takes disproportionately long. If that sounds familiar, you likely have a legacy system, regardless of its age.
Why is a legacy system a risk?
Because the business depends on something no one fully masters anymore. If the knowledge sits with one person, you're vulnerable the day that person leaves. If no one dares upgrade, security holes pile up and the technology ages. And when change becomes expensive and slow, the entire business gets held back by a system that should be supporting it.
What are the options going forward?
Roughly three. Wrap it: leave the system as is but build a protective layer around it so new parts can connect. Modernize step by step: replace one part at a time while it keeps running, at lower risk. Replace it: build something new and switch over. Which one fits depends on risk, budget, and how business-critical the system is.
Do we have to replace the whole system at once?
Rarely, and it's often the worst idea. A big-bang switch, where everything old is switched off and everything new switched on at once, is the riskiest path. For business-critical systems, step-by-step modernization – one piece at a time while the old system keeps running – is almost always safer, even if it takes longer. The size of the risk should drive the decision.