Rearchitecture Threshold
The conditions under which rebuilding a system is justified, given that it is the most expensive treatment and is chosen far more often than it is warranted.
Rebuilding is attractive to engineers and is usually the wrong answer. The threshold is deliberately high.
Conditions that justify it, and it needs more than one: the capability is genuinely differentiating — the business competes on it; the current implementation demonstrably blocks something the business needs, with evidence rather than discomfort; the change cost is high and rising, shown by lead time and change failure rate; and the domain is well understood, so the rebuild is not also a discovery exercise.
Conditions that do not justify it: the technology is unfashionable; the code is unpleasant; the team would prefer to work on something new; or a rewrite is estimated as cheaper than the maintenance, which it essentially never is.
The failure mode of full rewrites is well documented: the second-system effect, where the rebuild accumulates every deferred wish; feature parity as a moving target, since the old system keeps changing; and the knowledge in the old code, which encodes years of edge cases nobody remembers and which the rewrite rediscovers in production.
Which is why the practical form is almost always incremental: a strangler migration, capability by capability, with the old path retired as each is proven. That converts an all-or-nothing bet into a sequence of reversible steps, and it allows the programme to stop part-way with value delivered.