Replacing Legacy Business Software Without Losing What Already Works
Your old system still works. Until it doesn’t. Old software is not automatically bad software — if it has run a company for fifteen years it knows things nobody has written down. The question is whether it can still be safely changed.
Does this sound familiar?
The system still works, but nobody wants to touch it.
The person who wrote it left, or the company that built it has gone.
Every small change now costs more than the last one.
It runs on a version of something that stopped being supported years ago.
Getting a straight answer out of it means exporting to a spreadsheet.
There are years of data inside it and no one is willing to risk moving them.
Your software may know more about your business than its documentation does
A system that has run for a decade has absorbed a decade of decisions. The rule about which customers are invoiced differently. The exception for that one supplier. The reason a field is called something odd, which made sense in 2011. None of it is in a specification, because most of it was added a fortnight at a time in response to something real.
That accumulated logic is the asset, and it is also why replacement frightens people. The risk is not writing new software — it is discovering, three weeks after go-live, a rule nobody mentioned because everybody assumed it was obvious.
So the first work is not building. It is understanding what the current system actually does, including the parts nobody can explain any more.
Not everything needs replacing
There are three legitimate outcomes here, and only one of them is a rebuild. Which one you are looking at is a question of evidence, not enthusiasm — and we would rather establish it before anybody quotes.
Keep and stabilise
The system is viable and the real problem is that it is unmanaged: no tested backups, no documentation, nobody on call. That is a support problem, and it is far cheaper to fix than a rewrite. It is also the outcome we recommend more often than clients expect.
Modernise in stages
The core is sound but parts of it are not. Reporting moves out, an API goes on the front, the interface is replaced while the engine keeps running. There is no big-bang cutover because there is nothing to cut over. Where the database is the healthy part, that is modernising around the core.
Replace properly
Sometimes the platform underneath genuinely has no future — unsupported, unhostable, or built on something nobody will maintain. Then the job is carrying the behaviour and the data across without losing either, which is most of the work and all of the risk.
What happens to everything inside it
Data is usually the part that decides whether a replacement succeeds, and it is almost always messier than anyone expects: duplicates, fields used for two purposes, records that only make sense alongside a convention somebody remembers.
The work is discovery and schema analysis first, then mapping, cleaning, migration, validation and reconciliation — proving that what arrived matches what left, record by record and total by total. And a rollback plan, written before anything moves, because the point of a plan is that you have it on the day you did not expect to need it.
Moving without stopping the business
Nobody can switch a working company off for a weekend and hope. So the default is parallel running: the new system does the work alongside the old one, both are reconciled, and the old one is only retired once the numbers agree for long enough to be boring.
Where parallel running is impossible, the migration is staged — one department, one product line, one region at a time — so that the blast radius of anything unexpected is small and recoverable.
How we approach it
Understand
Read the system: what it does, what it holds, and which behaviour the business depends on without saying so.
Decide
Agree honestly whether this is stabilise, modernise in stages, or replace. Sometimes the answer is the cheapest one.
Build
Carry the business rules across deliberately, rather than reimplementing them from memory.
Move
Migrate with validation, reconciliation and a rollback plan. Parallel run until the figures are dull.
Stay
Support it afterwards, so the new system does not become the next one nobody wants to touch.
We’ve solved this before
American Express Business Travel
American Express Business Travel needed to move 1,800 machines from leased Sabre PCs onto their own hardware, across more than sixty locations in the UK and Ireland. Every desktop setting, travel software configuration and ticket printer arrangement had to arrive intact — on machines used all day by people booking travel for clients.
We wrote bespoke software that automated the backup and restoration across all 1,800 computers, and acted as technical lead alongside their other IT partners. The migration ran to a six-week timeline without interrupting the business it was running on.
What this usually involves
Custom Software
Systems shaped around how a business actually works — including the rules the old one learned.
Questions we get asked
Do we need the original source code?
It depends what you want done. Modernising or extending a system generally needs it; replacing one often does not, because the behaviour can be established from the running system and its database. If the code is genuinely gone, say so early — it changes which of the three routes is open, not whether we can help.
Do we have to replace the whole system?
Frequently not. Modernising around a sound core is cheaper, less disruptive and easier to reverse. We would rather propose that where it is true.
Can you migrate the existing data?
That is usually the largest part of the work. Expect discovery, mapping, cleaning, a test migration, and reconciliation proving the totals match before anything is trusted.
Can this be done without taking the business offline?
Normally yes, by running old and new in parallel or migrating in stages. Where a short outage is genuinely unavoidable we will say so up front and plan it with you.
What if nobody here understands the old system any more?
That is the usual starting position. Reading a system nobody can explain is a defined piece of work with its own output, and it is worth doing before anyone quotes for a rebuild.
Not sure whether it needs replacing?
You don’t need to know the technical answer yet. Tell us what is causing the problem. We’ll start there.
Building and running business systems since 2000. The same team that builds it stays to run it.
Start a Conversation