Feature Parity Trap
The expectation that a replacement system must match every behaviour of the old one before it can be adopted, which is what makes rewrites never finish.
A long-lived system accumulates behaviour: features nobody uses, edge cases for customers who left, workarounds for bugs that were fixed elsewhere, and rules that exist because of a decision made in 2009. Committing to reproduce all of it means committing to discover all of it, which nobody can scope, and it means delivering no value until the last item is done.
The trap has a specific shape: the last 20% of behaviour takes 80% of the effort and serves a fraction of a percent of usage, so the project stalls in a state where both systems must be maintained.
The escape is to make parity a decision per capability rather than a default. Measure actual usage before committing to reproduce anything; publish a deprecation for what is genuinely unused; and migrate cohorts of users rather than waiting for the whole surface. That converts an unbounded scope into a series of bounded ones, and it delivers throughout instead of at the end.
This is also the strongest argument for strangler-style replacement over rewrite: it forces the question "which capability, for whom, by when?" at every step.