Changing a system whose behaviour nobody can fully describe. This is the work that most needs someone inside the team rather than across a contract, because the knowledge that matters is undocumented and lives with your people. We map what the system does, 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 in the first two or three weeks; migration runs in slices you can stop between.
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 deployment, not per fashion. If your team already runs something that works, we work in 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 deployments draw on more than one of these.
Talk to an engineer who has done this before — and if this is the wrong place to start, they will say so.
