Skip to content

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.

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.

ComponentWhat it coversTypical weight
Discovery and specificationReading the existing system, documenting the process, agreeing the mappingSmall, and the worst place to economise
Application buildForms, reports, permissions, workflow, documentsThe largest single line
Data migrationExtraction, cleaning, import, reconciliation, files and attachmentsLarger than expected wherever the old data is messy
IntegrationEach connected system, built and testedPriced per integration, not as a block
Training and changeRole-based sessions, documentation, the parallel runUnderestimated in most failed projects
Hypercare and supportThe monitored window after go-live, then ongoing supportShould be explicit, not implied
Platform subscriptionOngoing per-user licensing for the platformRecurring, 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 Legacy System Cost

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.

#QuestionScore 2 if yes
1Does more than one person depend on this system daily to do their job?Β 
2Does anyone outside the office β€” field, site, customer, supplier β€” need access it cannot give?Β 
3Would you struggle to answer β€œwho changed this record, and when” if asked tomorrow?Β 
4Does exactly one person understand how it works?Β 
5Has it caused a visible failure in the last year β€” a wrong invoice, a stockout, a lost record, a compliance query?Β 
6Are 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:

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.

Where to Go From Here?

Not Sure Which Band You Are In?

Book a scoping call. We will look at the system, work through the decision framework 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.

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.

Resources

Latest Blogs