The rewrite trap is real: most teams that rewrite from scratch never ship. The alternative — strangling the legacy system incrementally — is slower in the demo and faster in the delivery.
A legacy system looks like a problem to be replaced. It's usually a problem to be migrated. The difference matters because replacement assumes you understand everything the old system does — and ten years of business rules, undocumented edge cases, and 'it works, don't touch it' behavior say otherwise.
“The safest path to a new architecture is the one where the old system stays running the whole way.”
The Strangler Pattern
The strangler fig grows around the host tree until it stands on its own. The software version: pick one slice of behavior, build it in the new system behind the same interface, route traffic to it, and delete the old implementation. Repeat until the legacy system is empty, then remove it.
The key discipline is the interface. If the new slice talks to the rest of the legacy system through a clean contract, you can migrate slice by slice without a big-bang cutover. If it doesn't, you're building a second monolith that happens to be newer.
What Makes It Work
Three things separate successful migrations: a working baseline (the old system keeps running), small slices (weeks, not quarters), and test coverage at the boundary (so the new slice provably matches the old behavior).
In practice, the first slice is the hardest — it builds the whole pipeline: the new stack, the interface, the routing, the comparison harness. Every slice after that is cheaper. That's the compounding payoff of doing it incrementally instead of rewriting.