Rewrites, Migrations and Restarts: A Business Economics Framework for CEOs

Every CEO or operator I've worked with faces this eventually (and then usually calls me): engineers pushing for legacy modernization or major migrations while the P&L says otherwise. The team pitches an 18-month rewrite, everyone gets nervous and it stalls. Teams will also spend 6 months getting into the effort before stalling, which is even more entertaining.

Here's what nobody says: this isn't a technical decision. It's business economics. And the right framework depends entirely on what you're optimizing for.

The Real Economics of Legacy Modernization

Skip the rewrite estimate. Start with three numbers:

• Technical debt service: What percentage of engineering capacity goes to workarounds instead of features right now? This shows up in your DORA metrics - long lead times, low deployment frequency. If your team spends 40% on infrastructure babysitting instead of product work, that's $400K annually on a 10-person team. Multiply by your planning horizon.

• Opportunity cost: Revenue you're not capturing because the platform can't support it. Enterprise deals dead in procurement. Sales and product complaining because the feature requests they get can't be implemented. Poor DevEx (Developer Experience) directly impacts business outcomes.

• Bus factor premium: Extra comp for engineers who know the old system, plus retention risk. It's easy to get backed into a corner, and pay 40% above market for two Perl experts. One leaves, consultants cost $200K for knowledge transfer. That's your risk premium, compounding annually.

• Quality and stability costs: Legacy systems often mean more production incidents, longer resolution times, and customer-facing reliability issues. Track your incident frequency and mean time to recovery (MTTR). If you're firefighting instead of shipping, that's real cost—both in engineering time and customer trust.

Add those three. Compare to modernization cost amortized over your hold period. That's the equation.

When Legacy Makes Sense

Don't touch the system if:

• Cash flow is strong and stable. Extracting $5M EBITDA from a product that hasn't changed in five years? 95% renewal rate? Don't optimize for engineering happiness, optimize for cash.

• Customers are risk-averse. Hospitals, government, insurance—they audit your stack. Boring tech is a feature, not a bug. "We trust you because you're still on-premise" is a huge moat.

• Recruiting isn't constrained. Geographic advantages or fascinating domain problems can overcome stack limitations. I've seen ancient Ruby codebases with zero turnover.

• Growth isn't the goal. Harvesting cash at steady 5% growth? Legacy tech that works is perfect.

When Legacy Modernization Has ROI

Modernize when economics clearly favor it:

• Aggressive growth plans. Doubling the team or expanding markets? Legacy tech becomes a brake on velocity. One company waited until $30M ARR—the rewrite cost 3x more because they had to maintain feature velocity simultaneously. Timing matters.

• M&A strategy. Rolling up competitors means integrating codebases. Modern, well-documented platforms make integration 10x easier. Integration risk kills deal economics.

• Talent acquisition is critical. Competitive markets (SF, NYC, Seattle, Toronto) and stack matters. Tooling and tech choices directly impact hiring and retention. Recruiting costs for legacy stacks run 30-50% higher in my experience.

• Security and compliance risk. Unsupported frameworks, unmaintained dependencies, and outdated security practices create material risk. SOC 2, ISO 27001, or industry-specific compliance requirements often force modernization. One breach or failed audit can cost more than the entire rewrite. If your enterprise sales team is losing deals to security questionnaires, calculate that cost.

• Platform limits revenue. Sales blocked by technical limitations? Calculate deal value. If it's material relative to modernization cost, the answer is obvious.

• Security and stability risk profile doesn't track to growth.

The Hybrid Play: Strangler Fig Pattern

Most see this as binary: rewrite or don't. There's a third option with better economics.

Build new features on modern tech. Route traffic incrementally. Leave stable features on the old system. Over 2-3 years, the new system "strangles" the old one on your timeline.

This approach spreads cost over multiple years, reduces risk (you can pause), lets you recruit on modern tech immediately, and maintains velocity. Economics often beat big-bang rewrites. Instead of $2M upfront and 18 months of reduced velocity, spend $400K/year while maintaining close to full productivity.

Your Decision Framework

Apply structured decision-making to legacy modernization:

Baseline: Measure current state

• Technical debt service: % engineering time on workarounds × team cost

• DevEx metrics: DORA scores, cycle time, deployment frequency

• Bus factor premium: Extra comp + retention risk for key personnel

• Opportunity cost: Revenue blocked by platform limitations

Goal: What you're optimizing for

• Growth trajectory: Planned team/revenue scaling

• Customer risk tolerance: Do they care about your stack?

• M&A plans: Integration requirements

Decision rule: If technical debt service + opportunity cost + bus factor premium exceed 20% of engineering budget, legacy modernization pays for itself. If you're doubling the team, you need modern tech. If customers and M&A plans favor stability, legacy works.

Iterate: Start with Strangler Fig if you're uncertain. Measure quarterly.

Why "Never Rewrite" Doesn't Always Apply

"Never rewrite" comes from startup land, optimizing for product-market fit before running out of cash, which can be correct advice for that context.

Different business models need to optimize for different things. For instance, PE portfolios target sustainable cash flow over 10-20 years. You can invest in infrastructure if returns are there. Different time horizon, different economics, different answer.

Your engineers read the same blogs, internalize the same dogma. Reframe it as business economics, not technical preference. Run the numbers. Sometimes legacy is right. Sometimes it leaves millions on the table.