A 15-year-old system is unmaintainable. The team wants a full rewrite. What do you advise?

What the interviewer is testing

Whether you can assess a rewrite honestly rather than reflexively opposing it.

Why rewrites usually fail

The specification is the legacy system, and nobody knows what it does. Fifteen years of business rules, edge cases, regulatory adjustments and undocumented behaviour are encoded in the code, and the people who added them have gone.

The business does not stop. The legacy system must keep receiving changes during the rewrite, so the target keeps moving and the team is building against a specification that changes weekly.

Value arrives only at the end, so the programme is exposed for its whole duration and can be cancelled with nothing delivered.

The cutover is a single high-risk event with limited rollback.

When a rewrite is nonetheless right

Technology with no future — an unsupported runtime, a language nobody can hire for, a platform being decommissioned.

A genuinely small system, where a rewrite is weeks and the risk is contained.

The functionality is being fundamentally reconsidered, so preserving current behaviour is not the objective.

Decomposition is genuinely impossible because the system is so entangled that no slice can be extracted — which is rarer than teams claim and should be tested rather than asserted.

The advice

Default to strangler, with slices chosen for value and separability, running behind a facade, with each step individually reversible.

Before committing either way, do the assessment: what does it actually do (from code analysis and observed usage), who depends on it (from network traffic and database access, not from the register), what is the data quality, and what is the true annual cost. Programmes that pick an approach and then investigate discover constraints that invalidate the choice after funding is approved.

Check what can be retired. A meaningful portion of a fifteen-year-old system is typically unused.

What a strong answer adds

If a rewrite is chosen, insist on parallel run with automated reconciliation for any correctness-critical calculation — and prepare stakeholders for the finding that some differences will be defects in the legacy system that the business has been relying on for years.

Common weak answers

"Never rewrite" as a rule. Approving the rewrite without an assessment of current behaviour and dependencies.