What does legacy system replacement involve?
Legacy system replacement is the planned migration of a business off software that is unsupported, undocumented or no longer fit for purpose. The work is mostly archaeology and risk management rather than new development: establishing what the old system really does, migrating the data faithfully, and moving across in stages so the operation never stops.
- Starts with documenting the existing behaviour, including the undocumented.
- Migrates in stages, with old and new running together and reconciled.
- Treats data migration and validation as a first-class deliverable.
Why it matters
The risk is real, and so is the risk of waiting.
Everyone involved knows the system is a liability. It runs on an operating system that stopped getting security patches years ago, the database is a format nothing modern reads, and the one person who understood it has left. Nobody replaces it because the day it stops, the business stops.
So the decision gets deferred, and the risk compounds. Cyber insurance starts asking questions. A corporate customer sends a security questionnaire. A hardware failure becomes an existential event because the install media no longer exists. The cheapest moment to do this was always earlier; the second cheapest is now.
The honest risk register
Why it gets deferred
We write this down in week one, because an unnamed risk cannot be managed and because the board usually needs to see it before funding the work:
- It runs on an unsupported OS, or on one specific machine nobody reboots.
- No source code, no documentation, no original supplier.
- Integration happens by exporting a file and importing it somewhere else.
- Your insurer or a major customer has started asking about it.
- It cannot be accessed remotely, so the team cannot work flexibly.
- Reporting means exporting to Excel and rebuilding it by hand.
Scope
How the replacement is actually done.
There is no single big switch. Each of these is a discrete, priced piece of work, and after the first one you know far more than you do today.
-
Discovery & behaviour mapping
We establish what the system does from the outside in — its data, its outputs, and the staff who know its quirks — and write it down. This is the deliverable everything else depends on.
-
Data extraction & profiling
Getting data out of whatever it is in, then profiling it honestly: duplicates, orphans, invalid dates, the free-text field three different things have been stored in for a decade.
-
Business rule recovery
The logic that exists only in the application or in someone’s head, recovered, written down and confirmed with the people who rely on it.
-
Target design & build
The replacement, designed around the process as it should be rather than reproducing twenty years of accumulated workaround.
-
Migration & parallel running
Rehearsed migrations, reconciliation reports proving the numbers match, and a period where both systems run so confidence is earned rather than assumed.
-
Decommission & archive
A legally sufficient read-only archive of the old system, documented retention, and the old infrastructure switched off deliberately rather than forgotten.
Deliverables
What you get out of it.
The point is not a shinier interface. It is removing a category of risk from the business and getting back the ability to change.
-
A supported, patchable platform
Current operating systems, current frameworks, security updates that arrive without a project. The insurer question and the customer security questionnaire both become answerable.
-
Your data, intact and verified
Migrated with reconciliation reports that prove balances, counts and histories match. Signed off on evidence rather than on a spot check of ten records.
-
The ability to change again
A documented, tested system a developer can safely modify. The reason legacy hurts is not that it is old, it is that nobody dares touch it.
-
Knowledge out of people’s heads
Business rules, edge cases and the reasons behind them, written down. This outlives the project and is often the most valuable thing produced.
Is this the right answer?
When legacy replacement is worth doing — and when it is not.
We would rather lose a project at this stage than six weeks in. If the right-hand column describes you, say so and we will tell you what we would do instead.
Worth doing when
- The system runs on an unsupported platform or one machine nobody dares reboot.
- There is no source code, no documentation and no surviving supplier.
- Your insurer or a major customer has started asking questions about it.
- You cannot change it, so you cannot change the business either.
Probably not when
- It is old but supported, documented and doing its job perfectly well.
- The business has no appetite for a programme measured in quarters.
- Nobody internal can be made available to answer questions about how it works.
- You want everything replaced in one weekend. We will decline that.
How we deliver
Incremental, because big-bang cutovers fail.
We have never recommended replacing everything in one weekend, and we would advise against anyone who does.
-
Phase one
Map it, honestly
Two to four weeks establishing what the system does, what the data looks like and where the risks are. Output is a written assessment, a risk register and options with prices — yours to act on with or without us.
-
Phase two
Strangle the edges
Replace one bounded piece first — reporting, or a single module — reading from the old system while it still runs. Real value, contained risk, and the team learns the new platform while the stakes are low.
-
Phase three
Move the core
The central workflow and its data, migrated with rehearsals and reconciliation, then run in parallel until the figures agree for a full cycle.
-
Phase four
Cut over & decommission
Switch, support through the first month end, archive the old system read-only, then turn the hardware off. The project is not finished until that last step is done.
What you receive
The things that actually land.
Artefacts, not adjectives. Everything below is listed in the scope document before a phase starts, so “done” is a defined state rather than an opinion.
-
A written description of the current system
What it actually does, derived from its data, outputs and users. Usually the first time anyone has had one, and yours regardless of what you do next.
-
An honest risk register
Named risks with likelihood and consequence, in the language a board needs to see before it funds the work.
-
Costed options
Replace, rebuild, extend or leave alone, each with a price and a consequence. Including the option of doing nothing, with its cost stated.
-
A data profile
Duplicates, orphans, invalid dates and the free-text field that has held three different things for a decade, quantified rather than guessed.
-
Reconciliation reports
Proof that balances, record counts and histories match between old and new, signed off on evidence rather than a spot check.
-
A documented archive
The old system preserved read-only for your retention period, with instructions that make the archive genuinely usable.
Golden Triangle
Legacy in the Midlands industrial base.
This region industrialised early in software terms too. A lot of excellent, now-unsupportable systems were written here in the 1990s and 2000s.
- Manufacturing MRP Bespoke and ancient Advanced manufacturers across Coventry, Birmingham and Derby often run MRP or scheduling software written for them decades ago. It encodes genuinely valuable process knowledge, which is exactly why it must be recovered rather than discarded.
- Access and Excel The hidden estate A surprising amount of the corridor’s distribution and wholesale sector still depends on Access databases and macro-heavy workbooks that one person maintains. These are usually the fastest, highest-return replacements.
- On-premise only One server, one room Systems that cannot be reached from outside the building constrain how a business can work and how it recovers from a fire or flood. Moving them is as much a continuity decision as a technology one.
We have assessed legacy estates for manufacturers, distributors and professional firms across Birmingham, Coventry, Derby, Nottingham, Leicester and Northampton, including systems with no surviving supplier.
Technology
What we migrate from, and to.
The source is whatever it is. We have not yet met a format we could not get data out of, though some take longer than others.
- MS Access
- FoxPro / dBase
- SQL Server
- Legacy AS/400
- VB6 / Delphi
- PostgreSQL
- Azure
- AWS
- ETL & reconciliation
- Written rule recovery
Where we deliver this
Legacy Replacement across the Golden Triangle.
35 locations, each with a page written for it — the sectors it is actually built on, and what that means for this work. See all areas we serve.
Northamptonshire 10
- Legacy Replacement in Brackley
- Legacy Replacement in Corby
- Legacy Replacement in Crick
- Legacy Replacement in Daventry
- Legacy Replacement in Kettering
- Legacy Replacement in Northampton
- Legacy Replacement in Raunds
- Legacy Replacement in Rushden
- Legacy Replacement in Towcester
- Legacy Replacement in Wellingborough
Warwickshire 5
West Midlands 5
Buckinghamshire 4
Leicestershire 4
Staffordshire 4
Derbyshire 1
Greater London 1
Nottinghamshire 1
Questions
Legacy replacement, answered plainly.
Asked by the person who has to sign off the risk.
How do you replace a system nobody understands any more?
From the outside in. We work from the data, the outputs and the people who use it daily, and we read the application’s behaviour rather than relying on documentation that does not exist. The first phase produces a written description of what the system actually does, which is usually the first time anyone has had one.
Can you migrate our data without losing anything?
We migrate with rehearsals and prove it with reconciliation reports — record counts, financial balances and spot-checked histories compared between old and new until they agree. Where the old data is genuinely broken, which is common, we surface it and agree a rule for each case rather than quietly discarding records.
Do we have to replace everything at once?
No, and you should not. We use an incremental approach: replace a bounded piece first, often reporting, while the old system keeps running, then move the core once the team trusts the new platform. Big-bang cutovers concentrate all the risk into one weekend, and that is how these projects fail publicly.
What does a legacy assessment cost?
The assessment phase is a small, fixed-price piece of work — typically a few thousand pounds over two to four weeks — and it produces a written map of the system, a risk register and costed options. It is deliberately a standalone deliverable: you can take it to any supplier, including ones who are not us.
Is it safer to just keep it running?
Not usually, and the risk is not static. An unsupported system accumulates vulnerabilities, becomes harder to recruit for, and eventually fails an insurer or a major customer’s security review. The honest comparison is not replacement cost against zero, it is replacement cost against the cost of an unplanned failure at the worst possible moment.
What happens to the old system afterwards?
It gets archived read-only for as long as your retention obligations require, documented so the archive is actually usable, and then the infrastructure is deliberately decommissioned. Leaving an old server quietly powered on “just in case” is one of the most common unmanaged risks we find.
What if the data is in a format nobody supports any more?
We have not yet met a format we could not extract from, though some take longer. Options run from direct file parsing and ODBC, through the application’s own export routines driven automatically, to reading the printed output as a last resort. We establish feasibility in the assessment phase so you are not committing to a migration on hope.
Can we keep the old system running in parallel?
Yes, and we insist on it for anything significant. Parallel running is where confidence is earned: both systems process the same work, the numbers are reconciled, and the old one is only switched off once they agree for a full cycle including month end. It costs a few weeks and removes most of the risk.
How do we keep the business running during the change?
By replacing in stages rather than at once. One bounded piece goes first — often reporting — reading from the old system while it still runs. That delivers real value, contains the risk, and lets your team learn the new platform while the stakes are low. Big-bang cutovers concentrate every risk into one weekend.
What if we start and decide not to continue?
You keep the assessment, the written description of the system, the risk register and the costed options, and you can take them to any other supplier. Each phase is priced and scoped separately precisely so that stopping is a real option at every point rather than a conversation about sunk cost.
Related services
Next to this, usually.
-
Build
Bespoke Software
Operational systems written for one business, not licensed to a whole market.
Explore -
Connect
ERP Integration
ERP connected to everything around it, without touching the core.
Explore -
Automate
Data Pipelines
Data moved, cleaned and reconciled on a schedule, so reporting has one source.
Explore
Next step
Start with an assessment you can take anywhere.
A few weeks of work produces a written map of the system, an honest risk register and costed options. Even if you never commission the replacement from us, you will know what you are dealing with.