When should you refactor, replace, or retire a legacy system?

Question

Accepted Answer

Legacy systems are uncomfortable but often valuable, they run the business. The decision to **refactor, replace, or retire** must be driven by cost and value, not by distaste for old code. "It's old and ugly" is not a reason; "it's costing us" is.

## A decision guide

```text
REFACTOR (improve in place) when:
  - Core logic is sound; it's holding business value
  - Problems are localized; you can improve incrementally

REPLACE (rewrite/migrate) when:
  - It blocks important work and can't be incrementally fixed
  - Maintenance cost > rebuild cost over a sensible horizon
  - It's a growing security or reliability liability

RETIRE (remove entirely) when:
  - Its value no longer justifies any maintenance cost
  - Usage has dwindled; a simpler path exists
```

## Beware the rewrite trap

Full rewrites are seductive and often disastrous, they take longer than expected, reintroduce old bugs, and the working system rots in the meantime. Prefer incremental refactoring or strangler-fig replacement. Reach for a full rewrite only when incremental paths are genuinely closed.

## A concrete example

A monolith is painful but runs fine and isn't your bottleneck, refactor the worst modules, don't rewrite. But a system on a database version that loses security support next year, with no upgrade path, that's a forced replacement, and you plan it deliberately.

## A pitfall

Emotional decisions: replacing good-enough systems because they're unfashionable, or clinging to dying ones out of sunk cost. Decide on cost and value.

## Why it matters

Unnecessary rewrites waste years and reintroduce solved problems; neglected legacy becomes a ticking liability.

Getting this call right, on evidence, not aesthetics, is one of the highest-stakes judgments a senior TL makes.