A decision framework for legacy systems: the five signals that justify a rebuild, the cheaper options most teams skip, and what each route costs in the UK.
Most growing companies eventually hit the same wall: the system that got you here will not get you there. Two recent engagements — one a fast-scaling healthcare fulfilment business, the other a multinational retail brand — point to a consistent way of modernising a legacy system without blowing up the business in the process.
The healthcare company came to us having scaled far beyond what its original e-commerce platform was built for. Clinicians reviewing patient orders faced page loads of 20–30 seconds. Every new member of staff made performance worse, not better. Basic actions — opening a questionnaire, raising a support ticket — had become genuinely unbearable for daily users, driving complaints and creating real risk of human error under pressure.
Leadership’s first instinct was to “just move the database to a better cloud platform”. The technical reality was more nuanced. The performance problem lived in how the system was built: a poorly structured database with no pagination, and everything crammed into oversized tables. Moving a badly structured database to faster infrastructure would simply have relocated the same problem to a more expensive address.
Rather than a 12-month “rebuild everything” project, we chose phased displacement, targeting the highest-pain group first — the staff reviewing and dispatching orders — by optimising the database, building a fast interface on top of the legacy backend through APIs, then migrating modules out of the old system one by one. We kept what worked and replaced only what did not: integrations that functioned perfectly well, such as shipping label generation and identity verification, were left untouched in phase one. The company went on to onboard more than eleven clinicians and cut the time spent processing patient orders by more than 30%.
“Is this system old?” is not the question. Many of the systems the world runs on were built in a different decade. What does this system stop us from doing? is the question worth asking before anyone considers a rebuild.
Five signals that justify a rebuild
There is no universal framework for making the call. These are the five signals that, in our experience, actually justify one.
The team spends too much time working with it. You know something is wrong when it takes an hour to pull a simple report or fill in a form. The longer it is left, the more the cost of lost productivity accumulates.
You cannot hire for it. Not “it is hard to hire” — you have genuinely failed to hire for twelve months. A system only two people can maintain is a business risk, not a technical preference.
The cost of change is too high. When a two-day change reliably takes three weeks because of regression risk, the system is charging interest on every future decision.
It blocks a revenue commitment. A contract you cannot sign, a market you cannot enter, an integration a major client requires.
The data model is wrong for the business you now are. The most expensive signal, and the only one where a rewrite is genuinely unavoidable — you cannot refactor your way to a different set of nouns.
If none of these is true, modernisation is likely to be an expensive way to feel better.
The alternatives most teams skip
A full rebuild is one option among several, and rarely the first one worth costing.
Strangler pattern. Put the new system in front, route one journey at a time through it, and let the old system shrink. Slower on paper, but every step ships and nothing is irreversible. This is the right default for anything with real users.
Re-platform without rewriting. Same code, current runtime, cloud database. Buys three years of supportability for a fraction of a rewrite, and often removes the security argument entirely.
An API in front of the monolith. Leave the system alone and expose what other systems need through a documented interface. Solves “we cannot integrate” without touching the thing everyone is afraid of.
Rewrite one bounded piece. Billing, or reporting, or the customer portal. Small enough to finish, valuable enough to justify, and it teaches you what a full rewrite would really cost before you commit to one.
What each route costs in the UK
| Route | Typical cost | Risk |
|---|---|---|
| Re-platform (lift, upgrade, cloud database) | £30,000 – £60,000 | Low |
| API layer over the existing system | £15,000 – £40,000 | Low |
| Strangler migration, journey by journey | £120,000 – £360,000 over 12–24 months | Medium, but reversible at every step |
| Full rebuild | £200,000 – £1m+ | High, and highest at the cutover |
| Do nothing | £0 now | Rises every year, and the bill arrives unscheduled |
The last row is not a joke. Doing nothing is a legitimate choice for a system with a known end date — a platform being replaced by an acquisition, or a product being sunset. It is only negligent when nobody has decided it.
The cutover is the project
Most rebuild failures are not build failures; they are migration failures. Before approving anything, insist on answers to four questions.
How does data move, and what happens to records that do not fit the new model?
Can both systems run at once, and for how long?
What is the rollback, and who decides to use it — at what hour, on what signal?
Which reports must reconcile exactly on day one, and who checks them?
A plan that cannot answer these is a plan for the easy 80%.
Where AI-assisted development helps
AI coding agents have already proved themselves on re-platforming and migration work. On legacy modernisation projects we use them for assisted refactoring of specific modules and for generating tests — the parts where the shape of the answer is known and the volume is the problem.
How to start without committing
Two weeks of paid discovery on the real system — its code, its data, its incident history — gives you a decision you can defend: which of the five signals genuinely applies, which route removes it, and what that costs. That is a far better purchase than a rebuild proposal written from a requirements document.
We do this work as part of our bespoke software development practice, and where the answer is a web platform, our web development agency in London page covers the same ground.
Alexander Bessudnov
Alexander is an accomplished Chief Product Owner with a proven track record of leading successful product development initiatives at Magora. With a passion for innovation and a keen understanding of market trends, Alexander plays a pivotal role in shaping Magora's product strategy and ensuring the delivery of cutting-edge solutions to clients.
LinkedIn