When to Refactor vs Rewrite

Price the current constraint

Identify which outcomes the existing design prevents and measure the operational cost. “The code is old” is not enough; security exposure, release lead time, defect rate, and unavailable capabilities are stronger evidence.

Map replacement risk

List hidden behavior, integrations, data migration, compliance needs, training, and the period where both systems must run. Rewrites fail when teams underestimate everything the old system quietly does.

Create reversible steps

Strangler patterns, module boundaries, API seams, and incremental data ownership let value ship before the final state. Choose a rewrite only when incremental paths cannot cross a fundamental constraint.

Inventory behavior before replacing it

Old systems often contain requirements that were never written down. Reports may depend on a strange query, an integration may rely on a field that appears unused, or editors may have developed workflows around behavior nobody considers a feature. Replacing the implementation without discovering those contracts turns the rewrite into an accidental requirements project.

Characterization tests, production logs, analytics, support tickets, and conversations with users can help identify what must remain compatible and what can intentionally change.

Create seams before large migrations

A system does not need to be perfectly designed before it can be improved incrementally. Introduce a service boundary around an external integration, move one content type to a cleaner model, replace one route behind a stable URL, or move one responsibility behind an API. Each seam creates another point where old and new implementation can coexist.

This approach also produces evidence. The team learns whether the proposed architecture works in production before committing the entire system to it.

When a rewrite can be justified

A rewrite becomes more reasonable when the current platform blocks required capabilities at a fundamental level, safe incremental migration cannot cross the constraint, and the organization can afford the period of parallel development and validation. Even then, migration planning, data reconciliation, observability, and rollback deserve as much attention as the new code.