Why a Clean Rewrite Increased Long-Term Risk

8 years of edge cases were invisible in the old system but critical in production. The rewrite forgot them.

[Overview] System Overview

The billing system processed $10M annually. It was ugly code written over 8 years by dozens of engineers. Leadership wanted a clean rewrite in a modern framework.

The rewrite took 18 months. Launch day revealed what was hiding in the ugly code.

[Context] Situation before

The old system worked. It had 1-2 minor incidents per year. But the code was difficult to maintain and new features took weeks.

##### Hidden Knowledge

Edge cases for timezone handling, credit card validation quirks, race conditions that had been fixed. All invisible unless you read every line.

[Diagnosis] The real problem

The rewrite was built from idealized requirements, not production reality. What looked like messy code was actually encoded knowledge.

Understanding the root cause changed everything.

[Boundaries] Working constraints

IMMUTABLE

• 14 payment processor integrations
• 8 years of customer-specific workarounds

Constraints are features, not obstacles. They guide design decisions.

[Decisions] Key tradeoffs

REJECTED

Clean rewrite

Start fresh with modern patterns

Hindsight: should have been rejected. The knowledge loss was catastrophic.

DEFERRED

Incremental refactoring

Improve existing code piece by piece

This is what we eventually did after the rewrite failures.

[Design] Architecture design

After 12 incidents in 6 months post-rewrite, we began porting edge case logic from the old system. The "clean" code became just as complex.

What Clean Rewrites Forget

8 years of edge cases lost in 18-month rewrite

clean-rewrite-increased-risk-architecture

[Approach] Execution model

##### Recovery

Dual-ran both systems. Identified edge cases from production discrepancies. Ported logic one case at a time.

[Results] Measurable outcomes

##### Cost

18 months rewrite + 12 months recovery. Net: 30 months for marginal improvement over incremental refactoring.

Key improvements achieved:

• System handles 10x burst load without degradation
• Delivery latency reduced from seconds to milliseconds
• Zero message loss during traffic spikes
• Operational complexity reduced by 60%

[Anti-patterns] What could have gone wrong

##### What We Learned

Ugly code that works beats clean code that does not. Old systems encode knowledge. Rewrites throw away knowledge.

• Over-engineering the initial solution
• Ignoring operational constraints during design
• Premature optimization without load testing
• Skipping failure mode analysis

[Applicability] Where this pattern applies

##### When Not to Rewrite

Revenue-critical systems. Anything with significant edge cases. Code older than 5 years.

Every system is different. Context always matters.