Legacy modernisation & re-platforming
The full rewrite is one of software’s most reliable ways to lose a year. Old systems are ugly, but they encode years of decisions nobody wrote down - and a rewrite has to reproduce all of it, under deadline, while the old system keeps changing. We take the incremental route instead: carve off a piece, replace it safely, repeat.
Service details
At a glance
- Incremental migration with cheap rollback at each step
- Strangler-pattern re-platforming
- The system stays live throughout
- Undocumented behaviour found and preserved
The systems we usually meet
It is usually the platform the business actually runs on - bookings, dispatch, policy admin, the order book - a decade or two old, built by people who have mostly moved on, in a stack the market has too. Releases happen quarterly because everyone is scared of them. There is a person who is the documentation, and they are talking about retiring. And lately the pressure has a new shape: an AI and automation agenda that cannot be built on a system nobody can safely change. None of this means the system is bad - it means it is due some deliberate attention.
- Releases so risky they happen quarterly, at 2am
- Knowledge concentrated in one or two irreplaceable heads
- A stack your hiring pipeline has never heard of
- Modern ambitions - integrations, data, AI - the platform cannot host
Why we talk people out of rewrites
Starting again always looks simpler. It almost never is. The legacy system is the only complete specification of how your business works, and a big-bang rewrite bets everything on reproducing it perfectly, in one go, while trade continues. Incremental modernisation retires the same risk a slice at a time - and starts paying back in months, not years.
Four weeks of reading before anything is recommended
Every modernisation here starts with a fixed-fee assessment: we read the code, the incident history and the change log, and sit with the engineers who live with the system. The point is to find where the pain actually is - which is rarely where the reputation says. On one national logistics platform, a year of incidents mapped to three specific places in a system everyone had written off wholesale; fixing those in place took ten months and made the eighteen-month rebuild unnecessary. Sometimes the assessment will tell you to modernise less than you feared. We will say so, even when the bigger contract was ours to take.
Read the rebuild we talked a client out of →How the migration runs
First we learn what the old system really does, including the undocumented behaviour people depend on without realising. Then we sequence the work so each increment delivers something useful, keeps rollback cheap, and is checked against the old system so behaviour does not silently change. The strangler pattern does much of the heavy lifting: new functionality gradually takes over until the legacy core can be switched off.
- Real behaviour mapped first, undocumented quirks included
- Each increment validated against the old system
- Rollback kept cheap at every step
- Early increments deliver value, not just plumbing
Where you end up
A system on modern, maintainable foundations, migrated without downtime, with the business logic preserved and - for the first time in years - written down. Plus a clear route to retiring the last of the legacy for good.
The people who hold the system up
Every legacy system has its keepers - the one or two engineers who know why the Tuesday job must never run before the Monday one. Modernisation done badly treats them as an obstacle; done well, they are the richest source in the building. We work alongside them from the first week, and the knowledge in their heads gets captured into tests, documentation and monitoring as we go - not as an exit interview, but as the natural by-product of changing the system safely. The key-person risk falls with every increment, which for many boards is half the reason the work was approved.
Modernise for what comes next
The strongest reason to modernise now is rarely the old system itself - it is everything queued up behind it. The integration a partner keeps asking for, the data the board wants to see weekly, the automation that would pay for itself in a quarter: all of it lands on the platform that cannot safely change. So we choose the sequence with the destination in mind - early increments unlock data access and integration points, which means the modernisation starts funding the next agenda before it is even finished.
What modernisation costs
The assessment is a fixed fee with a fast turnaround, and it produces a costed, sequenced plan that is yours whatever you decide to do next. Delivery is priced increment by increment - scoped projects from £8,000, or an embedded team from £4,500 a month per engineer for the long middle of a larger migration. The financial shape matters as much as the total: because each increment ships working value and keeps rollback cheap, you are never more than one slice deep in risk, and never funding a distant cutover on faith.
Frequently asked questions
- Why not just rewrite the whole thing?
- Because a rewrite must reproduce years of accumulated behaviour perfectly, under deadline, while the old system keeps moving. Some succeed; many burn a year or two first. Incremental modernisation delivers value sooner at a fraction of the risk.
- Can the system stay live during the work?
- Yes. Approaches like the strangler pattern replace it piece by piece while it keeps running, and every step has a way back.
- What about undocumented behaviour people rely on?
- Finding it is part of the job. Each increment is validated against the existing system, so nothing people depend on quietly disappears.
- How long does modernisation take?
- It scales with the size of the estate - but because delivery is incremental, value and reduced risk arrive throughout rather than at one distant cutover.
- What does legacy modernisation cost?
- The assessment is a fixed fee and stands on its own. Delivery is incremental - projects from £8,000, or an embedded team from £4,500 a month per engineer - and because each increment ships working value, the spend can pause at any slice without leaving you mid-air.
- Our system has no tests and no documentation - is that a problem?
- It is the normal case. The early work builds a safety net around the behaviour that matters - characterisation tests, monitoring, a rehearsed rollback - so change becomes safe before it becomes ambitious. The documentation gets written as we learn, which is how it finally ends up true.
- Which technologies can you modernise?
- The approach matters more than the language - the pattern is the same whether the estate is ageing .NET or Java, a sprawling PHP application, an Access-and-VBA empire or a database nobody dares upgrade. What we put at the end of the road is mainstream, hireable technology, chosen around your team.
- Do we have to move to the cloud?
- Only if your workloads justify it. Cloud is often the right destination and occasionally an expensive detour; the assessment costs the options against what you actually run. Modernisation means making the system safe to change - where it lives is a separate decision.
- Can we keep shipping features during the modernisation?
- Yes - and it is usually essential, because the business does not pause. Increments are sized so feature work and migration share the same rhythm, and the early safety-net work tends to make both faster within a couple of months.
- The developer who built it has left. Can you still help?
- Yes - it is one of the most common ways this engagement starts. The code, the incident history and the database are a surprisingly complete record once someone sits down to read them, and reading them is the first thing we do. The knowledge gets written down this time.
- Is it cheaper to just keep patching it?
- Sometimes - and the assessment will say so if it is. But the costs of standing still are usually paid invisibly: slow releases, fragile changes, hiring against a dead stack, and every new ambition blocked. The assessment puts numbers on both sides so the board is comparing costs, not fears.
- What is the strangler pattern?
- A migration approach where new code gradually takes over responsibilities from the old system - one route, one module, one workflow at a time - until the legacy core has nothing left to do and can be switched off. Each step is small, reversible and verifiable against the old behaviour, which is why it is our default for systems that cannot afford downtime.
- Can you modernise the database as well as the application?
- Yes - and often the database is the heart of the problem: an unsupported version, a schema nobody dares touch, business logic hiding in stored procedures. The same incremental discipline applies, with the added care that data migrations get rehearsed until they are boring.
Ready to talk through Legacy modernisation & re-platforming?
Book a free 30-minute consultation with a senior engineer to see how we can help.
Other services
Cloud migration
A move to the cloud designed around your workloads - costs modelled first, cutovers phased, nothing lost on the way.
ExploreTechnology & architecture consulting
Vendor-neutral advice on the technical decisions that are expensive to reverse.
ExploreTechnical due diligence
An unsentimental read on a company’s technology before you invest, acquire or commit.
Explore