Legacy Systems: When to Refactor, Rewrite, or Leave Alone

Assessment framework

We score three dimensions: business value (is the supported business still growing?), technical debt (maintenance cost and failure rate) and replacement cost (rule complexity and migration volume).

• High value, high debt — refactor first, using the strangler pattern to replace modules incrementally rather than a big-bang cut-over
• Low value, high debt — retire or replace with a standard product; custom development is not justified
• High value, low debt — leave it; invest in surrounding capabilities instead
• Low value, low debt — do nothing until value or debt changes

On rewriting

A common cause of failed rewrites is mistaking "we don't understand the old system" for "the old system has no value". Legacy systems accumulate undocumented business rules and edge cases that rewrites miss, surfacing only after go-live.

If a rewrite is unavoidable, extract business rules thoroughly first — log analysis, database field audits and interviews with long-tenured staff, cross-validated — before writing code.