Replacing systems you cannot switch off, without switching them off.
What this actually involves
Most modernisation projects fail because they are rewrites in disguise. We work incrementally: characterise the existing behaviour, put a seam around it, move traffic in slices, and keep a rollback path open the whole way.
You get a system you can change again — and, just as importantly, a team that understands why it now works the way it does.
Codebase archaeology
Static analysis, traffic capture and interviews to recover the behaviour nobody documented.
Strangler-fig migration
Route-by-route cutover behind a facade, with instant reversal.
Data migration
Change-data-capture, dual-write and reconciliation with provable parity.
Behaviour parity testing
Shadow traffic against old and new, diffed continuously.
What lands in your repository
Every engagement ends with artefacts your team owns — not a slide deck describing artefacts your team could have owned.
- Current-state architecture and risk register
- Incremental cutover plan with rollback gates
- Parity test harness and diff reports
- Decommissioning runbook
A short conversation with an engineer, not a sales qualification call. If we're the wrong people for it, we'll say so and point you somewhere better.