A team inherits a system nobody fully understands and is asked whether to rewrite it. What should be established before answering?

What must be established first

• What it actually does, which is not what the documentation or the original requirements say. Years of patches encode behaviour that customers now depend on, and the undocumented behaviour is frequently the behaviour that matters most.
• Who depends on it and how. A system with three known consumers usually has seven, including a report someone built, a job scheduled by a departed engineer, and a partner integration nobody owns.
• Which parts change and which do not. Change history tells you where the value and the risk are. A module untouched for four years is not a rewrite candidate however unpleasant it looks; the module changed weekly is.
• What it costs today: incidents, engineering time, opportunity cost of the changes not made because it is too risky to touch.
• What breaks if it stops, which determines the risk appetite for any migration.

Why "rewrite" is usually the wrong first answer

A rewrite discards the encoded knowledge and reproduces it slowly, and the reproduction is incomplete. The edge cases embedded over years are invisible until customers report them, and the new system fails on exactly the cases the old one handled — which is the classic pattern and it is why rewrites overrun.

It also requires feature freeze on the old system or parallel development, and both are expensive.

The options that should be considered first

Improve incrementally behind a boundary. Put a façade in front, extract the parts that change most, leave the stable core alone. This delivers value continuously, is reversible at each step, and preserves the encoded knowledge in the parts nobody understands.

Or do nothing. A system that is unpleasant, works, and is cheap to run does not need fixing — and saying so protects capacity for what does.

When a rewrite is genuinely right

When the platform is unsupportable — an unsupported runtime, a vendor that no longer exists, a technology nobody can hire for — or when the business requirement has fundamentally changed such that the existing model cannot express it.

Not when it is merely unpleasant, which is the usual motivation and the usual regret.