Legacy system replacement: four routes out

The expensive risk is not the software. It is that one person understands it. Four routes out, honestly costed.

Updated 19 September 2026 · 9 min read

The short answer

Legacy systems are rarely broken. They usually work, which is exactly why they survive. The reason to act is almost never the technology.

It is that one person understands it and the business depends on them. Two of the four routes below take days. Two take months. Find out which you need before anybody quotes you.

Somebody built a working system without a budget, a developer, or permission, and the company has run on it for years. That is a genuine achievement and it is worth saying, because most writing on this subject opens by telling you that you made a mistake.

You probably did not. What changed is the business around it. The old Access database, the Excel workbook several departments depend on, the bespoke thing written in 2011 by a contractor: they all fail in the same four ways, and only one of the four needs a rebuild.

The risk that should worry you is a person

Ask one question. If the person who understands this left in a month, what happens?

In most businesses the honest answer is that nothing breaks immediately and nothing can be changed afterwards. The system keeps running, and it keeps running exactly as it is, permanently, because the rules inside it exist nowhere else. Every request after that becomes a workaround, and within two years the business is shaped around the software rather than the other way round.

That is the expensive problem and it survives whatever you decide about the technology. It is also one of the standard deductions a buyer applies when valuing a small business, which is covered in making the business run without you.

The four ways these fail

What you notice	What is actually wrong	Cheapest real fix
One person understands it, and everybody knows who	The rules the business runs on are inside the system and written down nowhere.	Recover the rules and write them down. Worth paying for on its own, before any decision about software.
Nobody can use it from home, a client site, or a phone	It is a desktop program or a file on the office network, and the work is not.	Rebuild it as something that runs in a browser
It breaks when several people use it at once	It was built for one user and is being used as a shared system. Access, for instance, documents 255 concurrent users and turns unreliable past about 20.	Move the data to a proper database and keep the existing screens
It has gone slow, or it will not save any more	A hard file limit, or every action dragging whole tables across the network. Access databases stop at 2 GB and the failure arrives mid-save.	Split it, archive old records, then move the data

The bottom two are days of work. The top two cost real money, and only one of them needs a rebuild.

Three checks before you spend anything

How many people genuinely use it at the same time? Not how many have it installed. The number that matters is the peak, usually a Monday morning or a month end.
How big is the data, and is there a ceiling? An Access file stops at 2 GB. At 1.5 GB you have a deadline. At 1.9 GB you have an emergency.
Is anybody outside the office blocked by it? If the honest answer is yes and it matters, that is the one case where a rebuild is genuinely the cheapest answer.

The four routes out

Route	Fixes	Does not fix	Effort
Write down what the system decides	The key person risk, which is the expensive one	Anything technical	Days
Move the data, keep the screens	Crashes, size limits, real backups, several users at once	Remote access, key person risk	Days to weeks
Rebuild it to run in a browser	All of the above, plus phones, home working and client access	Nothing, though it is the expensive option	Months
Buy a product instead	Everything, at a monthly cost and with no build	Only works when your process is ordinary	Weeks

The second row is the one most people are never offered. The data moves somewhere robust while the screens your staff already know stay exactly as they are. No retraining, nothing changes day to day, and it costs a fraction of a rebuild. Where a supplier goes straight from "this is a risk" to a quote for a new system, that is the option they skipped.

Buying something instead is a real answer

A lot of these systems are a contact list, a booking diary or a stock count with twenty years of habit grown around them. Where that is the case a product already exists, it costs a few hundred pounds a year, and commissioning a replacement is the wrong purchase. Build or buy is the longer version of that argument.

The test is whether the awkward parts of your process are a reason clients choose you. Where they are, they are worth building around. Where they are merely awkward, buy something and spend the difference on something that grows the business.

The part that costs more than anybody budgets

Old systems hold decisions nobody recorded. Which customers get the other discount. Which orders skip a step. Why one report quietly leaves out a branch. Whoever built it knew, and has either left or has stopped remembering.

Recovering those rules is most of the work in any replacement, and it is the line that gets cut when a quote is under pressure. Skipping it is the commonest reason a new system gets rejected by the people who have to use it: the software does what the specification said, and the specification was written by somebody who never saw the workaround.

Never cut over in one go

Old and new run alongside each other while data and users move across gradually. Big-bang cutovers are how these projects make the news. Every step needs a way back, so that if something goes wrong on a Tuesday you are still trading on Wednesday.

Bands and timescales are published on the pricing page, and the staged approach we use is on the service page. The number moves on two things above all: how many other systems it has to talk to, and how inconsistent twenty years of records have quietly become.

Common questions

When should a business replace a legacy system?

When one of four things is true: only one person understands it, people cannot reach it from outside the office, it breaks when several use it at once, or it has hit a hard limit. The first is the expensive one and it is fixed by documentation rather than by software.

Can we keep the screens our staff know and change only what is underneath?

Usually yes, and it is the option most people are never offered. The data moves to a proper database and the screens your staff already use connect to it. Nothing changes for the people using it, no retraining is needed, and it costs a fraction of a rebuild.

Is Microsoft Access still supported?

Yes. Access still ships as part of Microsoft 365 and backward compatibility is unusually good, so support is rarely the reason to move. The reasons are the 2 GB file limit, unreliability past roughly 20 simultaneous users against a documented 255, and the fact that there is no supported way to use it over the web.

Do we have to replace all of it at once?

Usually not, and you should not. A common approach leaves the core alone and rebuilds only the parts causing pain, at a fraction of the cost of a full replacement. Where a full replacement is right, old and new should run in parallel rather than cutting over on a Monday.

Can you work with a system nobody documented?

Yes, and it is the normal case. The work runs from the database, from the behaviour, and from the people who use it daily, who usually know more than any document would have recorded.

What happens to our historical data?

It comes across. Where the old structure is inconsistent, and after twenty years it usually is, the cleaning rules are agreed with you in writing before anything moves rather than being decided quietly during the migration.

Tell us what is not working

Describe the process that is costing you time. If software is the wrong answer we will say so, and if a product already covers it we will name the product.

From £10,000Most projects land between £15,000 and £55,000.

Start a conversation See pricing