Legacy System Examples You Will Recognise in Your Own Business
Eight legacy system examples from ordinary established businesses, not mainframes. What made each one legacy, what it now blocks, and the cheapest way out of each.
Luka Abramovic7 min read
A legacy system is any system still carrying real operational load that nobody wants to change. Age is not the test and neither is the programming language. The test is whether you could confidently modify it next week, and most legacy systems in ordinary businesses are far younger than the word suggests.
Discussions of legacy software tend to reach for mainframes and COBOL. That is not what it looks like in a forty to three hundred person business. It looks like the eight examples below, each of which we meet regularly, and none of which is exotic.
For each one: what made it legacy, what it now blocks, and the cheapest realistic way forward.
1. The Access database that runs a department
What it is: a desktop database built years ago by a capable member of staff, now holding scheduling, stock or quality records for an entire team. It sits on a shared drive. One person understands it.
What made it legacy: nothing about the technology. It became legacy the moment the business started depending on it while nobody owned it.
What it blocks: remote work, concurrent users, reliable backup and any integration. It usually also blocks an accurate answer to how the department actually performs, because the data cannot be reported on alongside anything else.
Cheapest way out: extract the data and the rules first, then decide. The rules are the valuable part and they are undocumented. Rebuilding the interface without recovering the logic reproduces the problem somewhere more expensive.
2. The internal tool built by someone who left
What it is: a web application, a set of scripts or a reporting tool built in-house. It works. The person who built it has moved on and left no documentation beyond the code.
What made it legacy: the departure, not the code quality. A well-written system with nobody who understands it is harder to change than a poorly written one with an author on hand.
What it blocks: every change, because each one starts with an investigation. Small requests sit in a queue for months because nobody can estimate them.
Cheapest way out: fund a deliberate handover to someone, internal or external, whose first deliverable is a written account of what it does and where the risks are. This is unglamorous and considerably cheaper than the rebuild that usually gets proposed instead.
3. The ERP customisation that blocks every upgrade
What it is: your ERP was modified years ago to handle something specific. Vendor updates would overwrite it, so updates stopped.
What made it legacy: the gap between your version and the current one, which grows every quarter until an upgrade is a project rather than a task.
What it blocks: security patches, new integrations that assume a current version, and vendor support, which often narrows once you are far enough behind.
Cheapest way out: identify each modification and ask what business need it serves. Some can be retired outright. Some can be reimplemented outside the vendor's code so they survive updates. A few are genuinely essential, and knowing which is which converts a stalled upgrade into a scoped one. The wider set of constraints this creates is covered in our software improvement service.
4. The spreadsheet that became a system
What it is: a workbook with macros, lookup tables and several sheets nobody opens. It calculates pricing, plans capacity or tracks work in progress. Its file name ends in a version number and a person's initials.
What made it legacy: accumulation. Nobody decided to build a system, so nobody designed one, and the business rules ended up in formulas.
What it blocks: more than one person working at once, any audit trail of who changed what, and confidence in the output. Spreadsheet errors are quiet by nature.
Cheapest way out: write down the rules the workbook implements, in plain language, and have the business confirm them. Only then choose where they should live. Our integrate, replace or build guide works through where those rules should end up.
5. Software from a vendor that no longer supports it
What it is: a product still in daily use whose vendor has been acquired, has discontinued the line, or has moved everyone to a successor you have not adopted.
What made it legacy: the support ending, which changes the risk profile without changing the software.
What it blocks: not much day to day, which is precisely the danger. It blocks your response when something does break, and it usually means no security updates.
Cheapest way out: establish what your data export route actually is, and test it now rather than during an incident. Knowing you can get your data out converts an urgent problem into a scheduled one.
6. The on-premise server nobody wants to touch
What it is: a physical or virtual machine in an office or a rack, running something important. It was last restarted a long time ago and there is an unspoken reluctance to find out what happens if it goes down.
What made it legacy: configuration drift. It has been adjusted repeatedly over years, and its current state exists nowhere except on the machine itself.
What it blocks: recovery. If the server were lost tomorrow, rebuilding it would be an act of archaeology.
Cheapest way out: prove you can restore it somewhere else, before doing anything about the software running on it. A restore you have not tested is a hope, not a backup.
7. The three-year-old application that is already hard to change
What it is: a recent custom build, still in warranty-adjacent memory, where every change takes longer than expected and touching one area breaks another.
What made it legacy: usually delivery under time pressure with no tests, plus requirements that changed after the architecture was fixed. Age was never the factor.
What it blocks: the iteration the business expected to get by building custom in the first place, which is the whole justification for having built it.
Cheapest way out: resist the instinct to rewrite. Establish which part is genuinely fragile, put tests around the behaviour that matters, and change that part alone. Full rewrites of three-year-old systems rarely recover their cost.
8. The integration nobody can explain
What it is: two systems exchange data. It works. Nobody currently employed knows precisely how, what happens when it fails, or whether anyone would notice.
What made it legacy: invisibility. It has no owner, no monitoring, and it only surfaces when something has already gone wrong.
What it blocks: replacing either system, since the true scope of the change is unknown.
Cheapest way out: observe it before changing it. Record what it moves, how often, and what it does with a failure. The ownership and exception rules described on our systems integration service give a format for writing it down.
The pattern underneath all eight
| Not the cause | The real cause |
|---|---|
| Age of the system | Nobody currently understands it |
| Old programming language | No safe way to test a change |
| Poor code quality | Business rules recorded nowhere else |
| On-premise hosting | Current state exists only on the machine |
| Lack of a modern interface | No owner with capacity to change it |
Every example above is a knowledge problem before it is a technology problem, which is why the first useful step is almost always investigation rather than construction. A recommendation to rebuild made at first contact is a guess, and it is usually an expensive one.
If one of these describes something in your business, bring the system, the workflow depending on it and the change you have been postponing to a conversation. Our software improvement and rebuild work starts with an assessment, and sometimes concludes the smallest useful change is the right one.