Some systems can’t simply be switched off on a Friday and replaced on Monday: a clinical record system, a claims engine, a core ledger. This is how we approach replacing one. It describes our method, not a specific client.
Start with a map, not a rewrite
We begin by tracing how work actually flows through the old system: who uses which screens, which jobs run overnight, which reports someone downstream depends on. The output is a map of capabilities, ranked by risk and by how much each one blocks the rest.
Put a front door in place
A thin routing layer goes in front of the old system first. Users and integrations talk to the front door, and the front door decides whether a request goes to the old system or to the new one. Nothing changes for users on the day it goes in.
Move one capability at a time
- Build the capability on the new platform, next to the old one.
- Run both side by side and compare their results on real traffic, without users seeing the new output.
- Switch a small group of users or records to the new path, with a one-step way back.
- Widen the switch when the numbers agree, then retire that part of the old system.
Data moves with the capability
Each capability takes its own data with it, with a reconciliation report both sides sign off. There is no single migration weekend where everything has to go right at once.
The go-live runbook
- Named owners for every step, and a decision point where anyone can call a stop.
- Rehearsals on a copy of production before the real switch.
- Monitoring dashboards agreed in advance, so everyone looks at the same signals.
- A written way back for every step, tested before it is needed.
What you can expect from us
A senior lead who stays with the work from the first map to the last cutover, weekly demos, and a frank view when a piece of the old system is better left alone.
This is an engagement blueprint: how we run this kind of project. It describes our method, not a specific client. Want to see how it would apply to yours? Talk to us.