Changing a system whose behaviour nobody can fully describe. We map what it does and pin that behaviour with tests before touching it, then move it in increments each of which can be reverted on its own.
If more than one of these is true, this is usually the right starting point.
Mapping takes 2–3 weeks; migration is incremental from there.
The sequence this work follows, and why it is in that order.
What the system does in production, traced from real traffic — which is reliably different from what the documentation and the original authors say it does.
Tests that assert current behaviour, bugs included. They are not there to prove the system is right; they are there to tell you the moment it changes.
A facade routes traffic old-path or new-path per route. Each slice ships and can be reverted alone. Big-bang rewrites fail because the cutover is the only moment you learn anything.
Old paths are removed once traffic has moved and stayed moved. Leaving both alive "just in case" is how a modernisation ends with two systems instead of one.
Chosen per engagement, not per fashion. If your team already runs something that works, we use that instead.
InsurTech
Migrated client case data into Safer, an AI-powered injury management platform for Australian teams, and built out its Rehab and Injury product areas.
product areas shipped: Rehab and Injury
Most engagements draw on more than one of these.
One week, and you keep the baseline and the plan either way.
