Between 2023 and last year we ran six of these. Different stacks, different scales, different reasons for starting. The technical work varied enormously. The failure modes did not.
The seam is a product decision
Every migration starts with someone drawing a line and saying “this part comes out first”. That line is usually drawn along a technical boundary — a module, a database table, a service.
It should be drawn along a team boundary. The extracted piece has to be something one group can own end to end, deploy on its own schedule, and be accountable for. A technically clean extraction that leaves two teams jointly responsible for one deploy has not reduced coupling; it has moved it somewhere harder to see.
Strangle, do not rewrite
In all six, the version that worked put the new implementation behind the old interface and moved traffic gradually. The version that did not work — attempted twice before we were involved — built the replacement alongside and planned a cutover.
The reason is not really about risk tolerance. It is that a rewrite has no forcing function for discovering the undocumented behaviour, and every monolith of a certain age is mostly undocumented behaviour. Routing real traffic through the new path finds it. A test suite written from the spec does not, because the spec is what was wrong.
Budget for the dual-write period
The uncomfortable middle — where both systems are live and writes go to both — is where most of the schedule actually goes, and it is routinely estimated at zero. Plan for:
- Reconciliation. The two stores will diverge. You need a job that detects it and a decision about which side wins.
- Double the observability. You are debugging a distributed system now, whether or not you wanted one.
- A rollback that has been rehearsed. Not documented — rehearsed, on a real day, with the people who would have to run it.
The migration is not done when traffic is on the new path. It is done when the old path is deleted, and the gap between those two dates is where projects go to die.
The one that went best
The smoothest of the six spent the first three weeks writing no migration code at all. They instrumented the monolith, found that four of the eleven proposed extractions had almost no traffic, and cut them from the plan.
Deleting work is the highest-leverage thing available at the start of a migration, and it is almost never on the plan.
