ThreeNorth

  • Nov 3, 2025

The Strangler Fig Pattern for CEOs: Why Your Legacy Software Rewrite Will Probably Fail (And What to Do Instead)

  • Jason Gallaugher
  • 0 comments

Your legacy codebase works and makes money. A full rewrite costs $2-3M and 18 months. There's a better way to modernize incrementally.

You have a cash-flowing software business. The product works, there's a long list of satisfied customers. Revenue is solid. But the code is ancient - Power Builder, Classic ASP, PHP from 2006. You're facing what appears to be an all-in choice - leave it, or rewrite it to the tune of 18-24 months, $2-3M and feature development probably stops for that time.

I've see this with both migrations and rewrites after big promises are made (assuming it even makes it 18 months without stalling):

  • Month 6, you're behind.

  • Month 12, customers are asking where their promised features went.

  • Month 18, your best engineer leaves.

  • Month 24, you're still not done, revenue has flatlined, and you're wondering if you should just stick with what you had.

Big-bang rewrites are high-stakes bets that usually don't pay off. There's a better approach.

The Strangler Fig Pattern

Named after a plant that grows around a host tree and eventually replaces it, the Strangler Fig pattern is a metaphor and a strategy to allow you to modernize incrementally. You build new features in a modern stack, gradually migrate old functionality, and run both systems in parallel until the legacy code disappears.

It works like this: put a facade layer in front of everything, usually an API gateway or proxy. Requests come in, and the facade routes them - old features go to old code, new features go to new code. To customers, it looks like one system. To you, it's a gradual replacement that never stops value delivery.

Why This Fits Your Economics

Your fund has a 10-20 year horizon, or your board is putting pressure on you to grow (and commit to those plans). You can't afford 18 months of zero feature velocity. If you're growing 15% annually and you pause for a rewrite, you've cost yourself millions in enterprise value and handed competitors a window.

With Strangler Fig, you're always moving forward. For instance:

  • Q1: new authentication system, migrate 10% of users.

  • Q2: rebuild reporting, migrate another 15%.

Each quarter adds value and reduces risk. If you need to slow down, you can.

Emergent Architecture vs. The Grand Plan

This is where Strangler Fig aligns with how I believe that good architecture actually evolves. You're not designing the entire future system upfront. You're letting it emerge based on what you learn. You cannot know everything up front.

Traditional rewrites assume you can predict everything:

  • what the system needs to do

  • how users will interact with it

  • what scaling challenges you'll face.

That's rarely true. Requirements shift and markets change. You discover edge cases you didn't know existed.

Strangler Fig forces you to make small architectural decisions repeatedly, informed by real usage. You migrate authentication first and learn that your session management is more complex than you thought. You adjust. You migrate reporting and realize certain queries need optimization. You adjust again. The architecture emerges from actual constraints, not theoretical ones.

This is also how I always de-risk technical decisions. Instead of betting everything on a single framework or approach, you can validate choices incrementally. Pick the wrong database? You've only migrated 20% of features, switching costs are manageable. Discover your API design doesn't scale? Fix it before you've built everything on top of it.

The Basic Playbook

Start with the facade. This routing layer is critical—all traffic flows through it. Most teams use Kong, nginx, or a similar gateway. Get this right.

Pick your first target carefully. Don't start with the hairiest module. Choose something with clear boundaries, manageable complexity, and real customer value. Authentication, reporting, or a specific feature module often work. Early wins build momentum.

Run both systems, compare outputs. For initial migrations, run old and new code in parallel. Serve from the old system while validating the new one matches. This catches edge cases your tests missed.

Measure everything. Track the percentage of requests hitting new vs. old code. Monitor performance and error rates. You need data to prove this isn't just an expensive engineering hobby.

The Organizational Reality

Your architecture mirrors your organization. If your legacy system is a monolith maintained by siloed teams, that's not an accident, that's how those teams were structured when they built it and how they evolved to support it.

Here's the part most purely technical approaches ignore - when you change the architecture, the organization has to change too.

You can't move from a monolith to distributed services while keeping the same team structures, communication patterns, and decision-making processes. The literal, personal tension between old organizational patterns and new architectural patterns from the people in the organization will kill the migration.

Strangler Fig can make this manageable because the organizational change, if managed properly, happens incrementally. As you migrate authentication to a new service, you can create a team (or person) who owns that boundary. As the facade layer forces conversations about routing and contracts, you're establishing new communication patterns. The organization evolves alongside the architecture, not in one traumatic disruption.

I acknowledge and manage this explicitly. Engineers who maintained monolithic systems need new skills and new working relationships. Teams that never had to coordinate across service boundaries suddenly do. Decision rights shift. This isn't a side effect of modernization, it's half the work.

In my experience, this is the primary reason why so many efforts like this fail or get stuck.

The Risk Continuum

This isn't binary. You're not choosing between "full strangler fig" or "do nothing." You're making risk/upside calls based on your specific constraints.

Michael Feathers, in Working Effectively with Legacy Code, talks about finding "seams". Seams are places where you can alter behaviour without editing the code itself.

Even with the gnarliest legacy system, you have options along a continuum:

  • Leave it completely alone. Sometimes the core is too risky to touch. The original developer is gone. Documentation doesn't exist. Tests? None. But it works, and it makes money. Fine. Don't touch it. Just accept the bus factor risk and build everything new around it.

  • Wrap without touching. Add new capabilities as separate services that call the legacy system through its existing interfaces. Build a modern API layer in front. Add new features in new code. The legacy core stays frozen, but you're reducing your dependency on it over time. You're finding seams—places where behaviour can change without rewriting the internals.

  • Selective strangler fig. Pick the least risky, highest-value modules to migrate. Maybe it's reporting because that's well-understood. Maybe it's authentication because you need modern security. Leave the complex pricing engine or the mission-critical transaction processor alone for now. You're making incremental bets based on risk and capability.

  • Full modernization. Eventually, if the system proves its value and you build out the full capability, you might replace everything. But even then, you're doing it incrementally.

The risk factors that inform where you land on this continuum:

  • Engineering capability. Do you have someone who can read the old code and architect the new system? If not, start with wrapping. Build capability while you build new features.

  • System complexity and coupling. Tightly coupled monoliths are harder to strangle, but you can still wrap them. The facade might be thicker, but it's still better than a big-bang rewrite or doing nothing.

  • Product discipline. Can leadership commit to building new in the new stack? If not, you'll drift back to the old codebase. But even partial commitments move you forward.

The Leverage Question

For PE operators managing long holds and CEOs managing long-lived startups, this isn't just technical strategy, it's financial strategy. You're protecting revenue while systematically eliminating technical debt and bus factor risk. You're building organizational capability to handle change.

Strangler Fig is about making better bets with better information. Instead of one big gamble, you're making dozens of smaller decisions, each informed by the last. That's how you build leverage, and how you actually ship.

Next Reading

Strangler Fig Pattern

Working with Legacy Code

Architecture and Change

0 comments

Sign upor login to leave a comment