Legacy System Replacement Cost
Everyone asking this question has already been given a number, and it was either so large it ended the conversation or so vague it was useless. Both happen for the same reason: “legacy system” covers everything from an Access database used by four people to a decade-old application running a factory, and nobody can price that range in a sentence.
What can be set out honestly is the shape of the cost — what the bands are, what the money is actually spent on, what the delay costs in the meantime, and how to work out which side of the decision you are on. That is what this page does. It will not give you a quote, because a number produced without seeing your system is not a quote, and vendors who provide one usually revise it after discovery.
Home / Legacy System Replacement Cost
What Legacy Replacement Actually Costs
Three bands cover the great majority of projects. What moves a project up a band is almost never data volume — it is the number of processes involved, the number of systems it has to talk to, and how many people have to change how they work.
Band 1 — Single-process replacement
One system, one team, one process end to end: an Access database, a critical spreadsheet, a small legacy app, or a departmental tool. Typically a handful of entities, a few dozen fields, straightforward reporting, no external users, and at most one integration. Delivered in weeks. This is the band most businesses are actually in when they ask the question.
Typically £6,000–£18,000 for the build, delivered in four to eight weeks, plus platform licensing per user.
Band 2 — Departmental platform
Several linked processes across a department, or two or three legacy systems consolidated into one application. Approvals and scheduled automation, role-based access with several distinct profiles, dashboards, document generation, and usually an integration with accounting or CRM. Delivered over several weeks to a couple of months, with a parallel run.
Typically £18,000–£50,000, delivered over six to twelve weeks including the parallel run, plus platform licensing and per-integration cost.
Band 3 — Core operations replacement
The system the business runs on, spanning multiple departments, often with external users through a portal, multiple integrations, data migration from several sources with real quality problems, and meaningful change management. Delivered in phases over months, deliberately, because a big-bang cutover on core operations is how these projects fail.
Typically £50,000–£150,000+ across phases, delivered over four to nine months, with licensing, integrations and hypercare costed separately.
What the Money Is Actually Spent On
Two quotes for the same project can differ by half simply because they include different things. These are the components; when you compare proposals, compare them line by line rather than on the total.
| Component | What it covers | Typical weight |
|---|---|---|
| Discovery and specification | Reading the existing system, documenting the process, agreeing the mapping | Small, and the worst place to economise |
| Application build | Forms, reports, permissions, workflow, documents | The largest single line |
| Data migration | Extraction, cleaning, import, reconciliation, files and attachments | Larger than expected wherever the old data is messy |
| Integration | Each connected system, built and tested | Priced per integration, not as a block |
| Training and change | Role-based sessions, documentation, the parallel run | Underestimated in most failed projects |
| Hypercare and support | The monitored window after go-live, then ongoing support | Should be explicit, not implied |
| Platform subscription | Ongoing per-user licensing for the platform | Recurring, and separate from the build |
A low quote usually means discovery, data migration or training has been left out. It is worth asking which.
The Cost of Not Replacing It
The comparison people make is “cost of replacement versus zero”, and zero is never the alternative. The current system has a running cost; it is just distributed in places nobody adds up. These are the buckets worth measuring for your own situation before deciding anything.
- Time. Hours per week spent re-keying between systems, reconciling figures, chasing status, and rebuilding the same reports each period. Multiply by loaded salary cost and annualise — this alone is often the largest number in the exercise.
- Errors and rework. Invoices raised wrong, orders dispatched against a stale figure, stock variance found at count, credit notes issued for mistakes that a validation rule would have prevented.
- Decision latency. The cost of running on numbers that are two days old — purchasing to a stock position that has moved, quoting from a price list someone forgot to update.
- Key-person dependency. One person understands the VBA, the macros or the original build. Price the risk honestly: what happens to the business in the fortnight after they leave, and what a replacement with those skills costs to hire.
- Platform and licensing. Server hosting, remote-desktop licences, desktop software licences, and support contracts for things kept alive purely to run the old system.
- Opportunity cost. The things you cannot do at all: give customers a portal, let field staff work on a phone, add a product line, open a second location without duplicating the whole arrangement. Harder to quantify, and usually the reason the decision eventually gets made.
- Compliance and audit exposure. Where there is no audit trail, no access control and no defensible record of who changed what, the cost is contingent — but it is not zero, and it is not evenly distributed across the year.
A useful discipline: fill in those seven lines with your own figures before reading any proposal. If the annual total is a meaningful fraction of a Band 1 or Band 2 project, the arithmetic makes the decision for you. If it is not, the honest answer is to leave the system alone for now — which is a legitimate outcome.
A Decision Framework
Six questions. Score each one, then read the total.
| # | Question | Score 2 if yes |
|---|---|---|
| 1 | Does more than one person depend on this system daily to do their job? | |
| 2 | Does anyone outside the office — field, site, customer, supplier — need access it cannot give? | |
| 3 | Would you struggle to answer “who changed this record, and when” if asked tomorrow? | |
| 4 | Does exactly one person understand how it works? | |
| 5 | Has it caused a visible failure in the last year — a wrong invoice, a stockout, a lost record, a compliance query? | |
| 6 | Are you about to expand — new site, new line, more people — on top of it? |
10–12: replace now. The system is a constraint on the business and the failure modes are already visible. Delay increases the migration cost, because more data and more workarounds accumulate.
6–8: stabilise, then replace on a plan. Fix the immediate risk — take a proper backup regime, remove the single-person dependency, document what the system does — and schedule the replacement for the next quarter or the next budget cycle rather than treating it as an emergency.
0–4: leave it alone. It works, few people touch it, nothing has broken. Replacing a system that is not costing you anything is a project with no return. Revisit when one of the answers changes.
One caveat that applies at every score: replacement cost rises with time, and not linearly. Every year adds data to migrate, workarounds to unpick, and integrations built around the old system’s quirks. A system scoring 6 today that scores 10 in two years does not cost the same to replace then as it would now.
Where to Go From Here?
If you know what your legacy system is, the specific route is usually already mapped:
- A Microsoft Access database → Access to Zoho Creator migration, or Access database to cloud migration if you are weighing hosting against a rebuild
- A spreadsheet running a process → Excel to custom app development, or replace spreadsheets with an app if you are still diagnosing
- A process spanning departments on Excel → replace Excel with custom software
- A Google AppSheet app → AppSheet to Zoho Creator migration
- An older Zoho Creator application → Creator 5 to 6 migration
If you do not know which band you are in, that is what the scoping call is for. We will look at the system, work through the framework above with your figures rather than generic ones, and tell you the band, the timeline and the honest case for doing nothing if that is where it lands.
Not Sure Which Band You Are In?
Hear From Our Clients
Industries We Replace Legacy Systems For
Frequently Asked Questions
Because two systems that look identical on a description can differ by a factor of three in effort — one has clean data and no automation, the other has fifteen years of undocumented business rules. A credible fixed price comes after a short paid or free discovery that reads the actual system. A fixed price offered before that is either padded to cover the unknown or will be revised later.
Only if you count the licence and ignore everything else. Compare the annual total from the seven buckets above against the amortised cost of a replacement over three years. For many Band 1 systems the replacement pays for itself inside that window; for a stable system with few users, keeping it is genuinely the better economics.
Yes, and for Band 3 it is the recommended approach. The sequence matters: replace one complete process end to end rather than partially replacing several, because a half-migrated process means running both systems and reconciling between them, which costs more than either option alone.
Data migration, closely followed by change management. Old data is dirtier than anyone expects — duplicates, missing references, dates stored as text, values that mean something only to the person who entered them. And a technically perfect system that people work around because they were not brought along has not replaced anything.
Band 1 is weeks. Band 2 is several weeks to a couple of months including a parallel run. Band 3 is months, phased. Timelines lengthen most often for reasons on your side rather than the vendor’s — availability of the people who know the process, and decisions about what changes versus what is reproduced.
No, and you rarely should. Most businesses have one system that is genuinely urgent and two that merely annoy people. Replace the urgent one properly, learn from it, and let the second phase inherit the data model, the users and the permissions already built.
It migrates. History is not optional — reporting continuity, audit and customer records all depend on it. Where old data is inconsistent, it is normalised during migration and the exceptions are reported rather than silently dropped, and the original system is archived intact rather than switched off at go-live.