A team proposes rewriting a critical system from scratch, arguing the existing one is unmaintainable. How do you evaluate this?

Test the diagnosis before the prescription

"Unmaintainable" usually means one of several different things, and they have different remedies:

• Nobody understands it — a knowledge problem, addressed by documentation and pairing, not by a rewrite.
• Changes take too long — measure where the time actually goes. Frequently it is the test suite or the release process rather than the code.
• The technology is unsupported — genuine, and often solved by re-platforming rather than rewriting.
• The design prevents a required capability — the strongest case, and the one worth examining closely.

The arithmetic that usually settles it

A rewrite must reproduce every behaviour the current system has, including the ones nobody has documented and the ones that look like bugs but are relied upon. That is almost always larger than the estimate, because the estimate is based on the requirements people remember rather than on the behaviour that exists.

Meanwhile the existing system must keep changing during the rewrite, so either the rewrite chases a moving target or the business accepts a freeze — and a freeze on a critical system for two years is rarely acceptable once stated plainly.

Propose the strangler alternative

Incremental replacement behind a facade delivers value continuously, keeps the rollback available at every step, and lets the programme stop partway with the benefit already banked. Its total cost may exceed a rewrite's; its risk profile is completely different, and risk is what matters on a critical system.

When a rewrite is genuinely right

Small enough to complete in a few months. A fundamentally different requirement that the current design cannot express. A platform that is genuinely unsupported with no migration path. Or the current system is genuinely small.

Those are real cases and they are rarer than proposals suggest.

How to respond

Ask for the behavioural inventory first — what does the current system actually do, established from usage rather than from memory. If the team cannot produce it, they cannot scope the rewrite either, and that is the answer.