How to Know When to Rewrite Instead of Patch

Patching is the default response to system problems. But defaults aren't always right.

Patching is fast, low-risk, and maintains continuity. These are genuine advantages — until they're not. When patches accumulate to the point where each new patch creates more problems than it solves, the system has crossed the threshold from "maintainable" to "dying."

Patch fatigue signals

The system is telling you it needs more than patches when: - Each bug fix introduces new bugs in seemingly unrelated areas - Patches require increasingly complex workarounds - The time to implement patches is growing exponentially - Developers avoid touching certain areas of the codebase entirely - The patch history for a single component exceeds the original implementation time

Performance bottleneck analysis

Performance bottlenecks come in two varieties:

Optimizable: The bottleneck is a specific query, algorithm, or resource constraint that can be improved without structural change. Patch this.

Architectural: The bottleneck is inherent to the system design. The data model, the processing pipeline, or the deployment architecture cannot support the required performance. Rewrite this.

The diagnostic: If optimizing the bottleneck would require changing the fundamental approach (not just the implementation), it's architectural.

Cost comparison model

Compare the total cost of continued patching vs rewriting:

Continued patching cost: - Average patch cost × expected patches per quarter × quarters remaining - Opportunity cost of features not shipped due to maintenance burden - Risk cost of system failure probability × failure impact

Rewrite cost: - Development time × team cost - Opportunity cost during rewrite period - Migration risk and cost - Learning curve for new system

When continued patching cost exceeds rewrite cost within 12 months, rewrite.

The trigger threshold checklist

Rewrite when three or more of these are true: 1. Patch time exceeds 50% of total development time 2. New feature development takes 3x longer than equivalent features 12 months ago 3. System reliability is declining despite increased maintenance effort 4. The architecture cannot support a known, committed business requirement 5. Onboarding new developers takes more than 4 weeks to productivity 6. The team's morale is measurably declining due to system frustration

How this decision shapes execution

The rewrite decision changes the execution trajectory from incremental improvement to structural investment. It requires different planning, different communication, and different success metrics. Execution during a rewrite must balance continued operation of the old system with construction of the new one — a dual-track that demands clarity and discipline.