What is the true cost of maintaining legacy code vs rewriting from scratch?

The "Second System Effect" is the silent killer of enterprise software companies. While engineering teams almost universally advocate for greenfield rewrites—citing brittle legacy code and developer misery—the true financial devastation of a rewrite is the Opportunity Cost of Stalled Features.

The Rewrite Fallacy

When a CTO authorizes a "v2.0 rewrite from scratch," they are implicitly agreeing to halt or severely bottleneck net-new revenue-generating features on the existing platform. If an engineering organization spends 18 months rebuilding the core infrastructure, you must calculate the exact Net Revenue Retention (NRR) you will bleed to agile competitors executing against modern customer demands during that dark period. A massive rewrite often equates to giving your market share away for free.

Calculating the Legacy Drag

Conversely, maintaining toxic legacy code carries a compounding interest rate. To measure this, calculate your Debt Interest Rate:

• Onboarding Friction: How many months does it take a senior engineer to become context-aware in the codebase?
• Maintenance Ratio: What percentage of story points are dedicated to patching technical debt versus shipping new features? If this creeps above 40%, the system is insolvent.
• Catastrophic Risk: The mathematical probability of a severe data breach or critical failure due to unpatchable dependencies.

The Executive Case Study

A leading healthcare CRM provider decided to rewrite their 10-year-old monolithic portal from scratch using modern React and Go. They estimated it would take 9 months. It took 2.5 years. During that 30-month freeze, a heavily-funded startup entered the market, matched their feature set, and aggressively courted their customer base. Because the incumbent CRM couldn't ship any new compliance tools while their entire staff was trapped in the rewrite, they lost $14M in ARR to churn. The rewrite succeeded technically, but destroyed the company financially.

The 90-Day Remediation Plan

• Day 1-30: Measure the "Maintenance Ratio". Tag every Jira ticket strictly as "Feature" or "Maintenance". Calculate exactly how much payroll capital is being spent just keeping the engine running.
• Day 31-60: Identify the specific domain within the legacy code that has the highest bug rate. Do not rewrite everything; target the single most toxic organ.
• Day 61-90: Execute the Strangler Fig Pattern. Surround the toxic module with an API facade. Build the new module alongside it. Route 1% of new traffic to the new module, then 10%, slowly strangling the legacy code without ever stopping main feature development.