01Why rewrites stall
A rewrite must reach feature parity with a decade of undocumented behaviour before it delivers a single benefit. Meanwhile the old system keeps changing, and the gap never closes.
The business is asked to fund two systems and wait. Enthusiasm runs out before the cutover date does.
02Strangle instead
Put a routing layer in front of the legacy system, move one capability at a time behind it, and let each move deliver value on its own.
Start with a slice that is high pain and low coupling — reporting, notifications, a customer-facing portal — to build confidence and prove the pattern.
03Data is the hard part
Plan dual-write or change-data-capture early, and decide how you will detect divergence. Most migration incidents are data mismatches, not code failures.
Keep a reversible path for every step. If you cannot roll back a slice within an hour, the slice is too big.
04Document while you go
Every extracted capability is an opportunity to write down the rule it encodes. That documentation is often the most valuable artefact of the whole programme.