Software engineering · Legacy modernisation
Replacing a system while it stays in use
We replace systems the business has outgrown step by step. The old and new systems run side by side, the data is checked automatically, and the old system is switched off on a date that is actually met.
Where this starts
The complete rewrite that never finishes
Rewriting a whole system from scratch is one of the most common ways for a software project to fail. It is proposed because the existing system is genuinely painful, and approved because the pain is real. It then runs for two years while the old system keeps changing underneath it. The problem is not ambition. It is that switching everything over at once puts all the risk into a single weekend that nobody has been able to rehearse.
What we usually find
- A system that only two people understand, and at least one of them is about to leave
- A platform the vendor no longer supports, or software that no longer receives security updates
- Business rules that only exist inside the system and are not documented anywhere
- A rewrite that has taken so long that its own requirements are out of date
- Direct connections between systems built up over a decade, with no list of what connects to what
- A migration that is stuck because nobody can prove the new data matches the old
Our position
If a switchover cannot be rehearsed, it should not be attempted. Every step we take can be practised in advance and reversed if needed.
What the work covers
Step by step, by default
Our method is deliberately practical. You see results within months rather than at the end, and there is never a single moment when everything has to work at once.
Understanding what the system really does
We work out what the system actually does from its code and data. Documentation usually describes an earlier version, and the intentions of people who have since left.
Replacing it piece by piece
We build new features alongside the old system and move traffic across one part at a time. The old system shrinks steadily, rather than being switched off in one go. This is known as the strangler pattern.
Moving and checking the data
We run the data migration repeatedly against copies of your live data. Automated checks prove the old and new systems agree before anything is switched over. This is usually the longest part of the programme, and the part most often underestimated.
Running both systems side by side
Both systems run live and their results are compared automatically. Any differences are investigated, not assumed to be harmless. It costs more for a while, but it is what makes the final switchover uneventful.
Untangling connections
We list every direct connection between systems and replace them with clearly defined interfaces. This stops the new system from inheriting the tangle it was meant to remove.
Switching off the old system
We agree a dated plan to retire the old system, showing the licence, hosting and support costs it will save. If the old system is left running, the modernisation has not finished. It has doubled the number of systems you run.
How each step is proved
Confidence comes from repeated testing, not analysis
These checks run throughout the programme. They allow the decision to switch over to be based on evidence rather than nerve.
Behaviour tests
We write tests that capture how the existing system actually behaves, including behaviour nobody intended. Any difference in the new system can then be detected, rather than debated.
Data checks
Every migration rehearsal automatically compares the records in both systems. Differences are reported by type, rather than as a single total that hides the important cases.
Shadow testing
Real requests are replayed against the new system and the results compared, without affecting customers. This finds problems that tests miss, because real data is always more unusual than test data.
Rollback
Every switchover step can be reversed, and is rehearsed before the real one. Deciding to go ahead never means you cannot go back.
Progress
The share of traffic, records and features moved across is reported automatically. Progress meetings discuss facts rather than impressions.
What you are left with
- A step-by-step migration plan with a date to retire the old system
- Automated checks proving the data matches
- Tests covering the behaviour the business relies on
- The old system switched off, and its costs removed from your budget
- Documentation of behaviour that previously existed only in old code
Tell us what the old system still does that nothing else can
That is usually the quickest route to a plan, and the list is often shorter than people expect.