A platform's core system cannot support a capability the business needs. The team proposes a rebuild. What must be true for rebuild to beat incremental re-architecture?

What must be true

All of these, not some:

1. The required capability is genuinely unreachable incrementally. Not "would be cleaner" — structurally impossible. Usually this means a data model that cannot represent the required concept, or a concurrency and consistency model incompatible with the requirement.

2. The existing system's behaviour is documented or recoverable. A rebuild must reproduce the accumulated handling of real-world edge cases. If that knowledge exists only in the code, a rebuild is a reverse- engineering project with an uncertain end date.

3. The old system can be frozen, or the team can afford to build a moving target. If the original keeps changing throughout, the rebuild is chasing it, and this is how rewrites fail to ever catch up.

4. There is a path to incremental delivery. A rebuild that delivers nothing for two years will be cancelled when priorities change — and priorities always change.

5. The organisation has the appetite for a multi-year programme with no new features from it.

Why incremental re-architecture usually wins

• Value delivered continuously, so the programme survives priority changes.
• Risk is bounded per slice rather than concentrated at a single cutover.
• Behaviour is preserved by construction, because each slice is replaced against real traffic and compared.
• It can be stopped. Halfway through an incremental programme, you have half the benefit. Halfway through a rebuild, you have nothing.

That last property is the decisive one and is consistently underweighted.

When rebuild genuinely wins

• The existing system is small enough that a rebuild is measured in months.
• The domain is genuinely well understood and the behaviour is specified rather than discovered.
• The existing technology is unsupportable — no expertise available, no security patches, no path forward.
• The existing system can be frozen because the business has stopped asking it to change.

The middle path that is usually right

Strangle rather than rebuild. A façade in front of the existing system, then replace capability by capability, each with its own sponsor and benefit, with the old path removed as each slice completes.

This gets most of the rebuild's benefit with the incremental approach's risk profile — and it forces the scope discipline that rebuilds notoriously lack, because each slice must justify itself.