Change a live system without losing what already works
Modernise the software your business depends on without asking people to give up the capabilities they already use. We agree what must stay the same, replace the parts that hold you back and test the result against the existing service.
Need to take this to a board? Read or download the buyer decision pack →
Improve the system without restarting the business
An ageing application can still do an important job. The problem may be that every change takes too long, running costs keep rising, or one tightly coupled part prevents the rest from scaling. Replacing it with a cut-down product asks your staff to absorb the disruption while someone spends years rebuilding what they already had.
Our refactor work starts with that existing job. We identify the parts that need to change, record the rules and workflows people rely on, and agree the improvements the replacement must deliver. That might mean separating a busy part of the application, replacing its server or recovering a codebase that has become difficult to change.
What you commission
The engagement joins three pieces of work around your system:
- Understand the risk and agree the scope. An Architecture Review establishes where change will help, what depends on it and which behaviour must be preserved.
- Build and compare the replacement. Technical Recovery / Refactor changes the agreed parts while old and new behaviour can be compared. Any difference must be resolved as a defect or approved as an intentional change.
- Leave a way to check the next change. A Verification Harness Build makes those comparisons repeatable, alongside migration checks, operating instructions and a tested return path.
These are connected parts of an agreed engagement, not three compulsory purchases. The proposal sets the boundary, deliverables and price after we have inspected the system. You receive the changed software and the evidence needed to accept it—not a cleaner codebase at the expense of the job it performs.
How you know the change is ready
Before implementation, we agree the behaviour to compare, the migration and recovery checks, and any performance or operating-cost targets. The replacement must meet those acceptance conditions before it takes over. Behaviour outside the recorded boundary remains a limit to investigate, not something we claim to have proved.
The Ember work below shows this approach applied to one live product. Its numbers are evidence from that engagement, not a prediction for yours.
Example: replacing Ember’s production server
Phoenix Ember was already running in schools. Its server needed to be replaced, but existing users could not be asked to rediscover every rule by finding out what the new version had forgotten.
The first job was therefore not to write the replacement. It was to turn the behaviour of the running system into something both versions could be tested against.
The agreed boundary
We exercised the existing server across its important operating paths and recorded 2,510 observations of requests, state and responses. The same observations were then run against the replacement.
This was a measured behavioural boundary, not a claim that 2,510 checks represent every theoretically possible action. Its purpose was precise: make any difference inside the agreed surface visible before users encountered it.
What we changed
Zero Drift replaced the whole server behind that boundary. The old route remained available as a rollback path while differences were found, understood and closed. The replacement was not allowed to take over because it looked cleaner or passed a conventional test suite; it had to match the behaviour we had agreed to preserve.
The result
At the release gate, the comparison found zero behavioural differences across all 2,510 recorded observations. That is the bounded claim: no divergence in what was measured. It is stronger than saying the refactor felt safe, and more honest than claiming the system can never be wrong.
The work also left the comparison machinery behind. Future changes can be tested against the same behavioural contract instead of relying on memory.
Release-gate receipt
The final run was recorded on 26 August 2026. It contained 193 corpus rows producing 2,510 comparisons: 2,510 identical, 0 divergent, 0 crashed and 0 unexplained one-sided results. The published machine-readable receipt includes the claim boundary and SHA-256 hashes of the two retained source records, so the public summary can be matched to the underlying evidence during due diligence.
Discuss your system
Tell us what is becoming expensive or difficult, what must keep working and which change you need to make. We can then identify the right starting point and the evidence needed to agree the work.
The exact checks depend on the product. The principle does not: preserve what people rely on, expose divergence before release and retain a tested way back until the new path holds.