What distinguishes a strangler migration that completes from one that becomes permanent coexistence?
Show the full answer Hide the answer
What distinguishes them
Whether decommissioning is a deliverable of each slice, with a date and an owner.
A slice is not migrated until the legacy path is removed. Without that rule, each slice ends at "the new implementation serves traffic", the old path remains available "just in case", and the organisation accumulates permanent duplication.
Perpetual coexistence is the characteristic failure of these programmes — both systems operated and paid for, with a synchronisation layer as a standing tax — and it destroys the business case entirely.
The other distinguishing factors
1. A business sponsor and a benefit per slice. A technical programme with a technical sponsor loses priority whenever anything else is urgent, and something else is always urgent.
2. The first slice proves the machinery rather than delivering the most value. Few dependencies, clear boundaries, read-mostly, modest but real traffic. A first slice that takes nine months because it was too ambitious frequently ends the programme.
3. An anti-corruption layer at the boundary. Without it, the new services inherit legacy models and naming, and the "new" system becomes a distributed copy of the old one with extra network calls — the most common way these migrations deliver no benefit.
4. Explicit non-goals. Strangler programmes attract every deferred wish, which is the second-system effect and reintroduces the all-or-nothing risk the incremental approach was chosen to avoid.
5. Data ownership migrated deliberately per entity, with one authoritative system at a time — rather than bidirectional synchronisation, which has no natural end state and therefore never ends.
The machinery that must exist before the first slice
A routing façade all traffic passes through, traffic shadowing with automated comparison, and instant rollback as a configuration change. Building these first is what makes each subsequent slice a measurement rather than a leap.
The measure of progress
Legacy paths removed, not new services deployed. A programme reporting "twelve services built" and "zero legacy paths removed" has produced coexistence, not migration — and reporting it that way is what makes the problem visible while it is still correctable.