Software engineering · Legacy modernisation
Replacing a system while it stays in service
Incremental replacement of a system the business has outgrown, with old and new running together, data reconciled automatically, and a decommissioning date that is actually reached.
Where this starts
The rewrite that never lands
The full rewrite is the most reliably failed project in the industry. It gets proposed because the existing system is genuinely painful, approved because the pain is real, and then runs for two years against a moving target while the old system keeps changing underneath it. The flaw is not ambition. It is that a single cutover concentrates every risk into one weekend that nobody has been able to rehearse.
What we usually find
- A system two people understand, at least one of whom is close to leaving
- A platform out of vendor support, or a runtime no longer receiving patches
- Business logic that exists only in the system and is documented nowhere
- A rewrite that has run long enough for its own requirements to be out of date
- Point to point integrations built over a decade, with no inventory
- A migration blocked because nobody can prove the new data matches the old
Our position
A cutover you cannot rehearse is a cutover you should not attempt. Every step we take is one we can run twice and reverse once.
What the work covers
Incremental by default
The method is unglamorous on purpose. Value arrives in months rather than at the end, and there is never a single point at which everything has to work at once.
Discovery of actual behaviour
What the system really does, established from the code and the data rather than from documentation that describes an earlier version of it and the intentions of people who have left.
Strangler pattern
New capability built alongside the old, with traffic moved route by route behind a facade, so the legacy system shrinks steadily rather than being switched off in one movement.
Data migration and reconciliation
Migration run repeatedly against production copies, with automated reconciliation proving old and new agree before anything is cut over. This is usually the longest part of the programme and the part most often underestimated.
Parallel running
Both systems live, results compared automatically, differences investigated rather than assumed benign. It costs more for a period, and it is what makes the eventual cutover uneventful.
Untangling integrations
Point to point connections inventoried and replaced with contracts, so the replacement does not quietly inherit the sprawl it was commissioned to remove.
Decommissioning
A dated plan to switch the old system off with the licence, hosting and support cost attached to it, because a modernisation that leaves the legacy running has not finished, it has doubled the estate.
How each step is proved
Confidence comes from repetition, not analysis
These run continuously through the programme, which is what lets a cutover decision be made on evidence rather than nerve.
Characterisation
Tests written against the existing system’s actual behaviour, including the behaviour nobody intended, so any difference in the replacement is detectable rather than debatable.
Reconciliation
Automated comparison of records between systems on every migration rehearsal, with differences reported by type rather than as a single total that hides the interesting cases.
Shadow traffic
Live requests replayed against the new path and the results compared, without affecting the customer. This finds what a test suite will not, because production data is stranger than test data.
Rollback
Every cutover step reversible and rehearsed before the real one, so the decision to proceed is not simultaneously the decision to commit.
Progress
Share of traffic, records and functionality moved, reported automatically, so the programme reports facts rather than sentiment in a steering meeting.
What you are left holding
- A route by route migration plan with a decommissioning date
- Automated reconciliation proving the data matches
- Characterisation tests covering the behaviour the business relies on
- The old system switched off, and its cost out of your budget
- Documented behaviour that previously existed only in legacy code
Tell us what the old system still does that nothing else can
That is usually the shortest route to a plan, and the list is often shorter than anyone expects.