The Strangler Fig Pattern: Growing Around Legacy

The Leaning Tower of Pisa shouldn’t exist today. The real story behind why it’s still standing is the perfect setup for modern software engineering.

When construction began in 1173, the tower started leaning by the time the third floor was built. This wasn't because medieval engineers were sloppy, but because the ground beneath one side was soft clay. The more they built, the more it tilted. By the late 1900s, the tilt reached 5.5 degrees. That’s past the point of no return. If gravity had its way, the tower was done.

But the world didn’t lose it. Instead, teams of engineers across decades pulled off something remarkable: they stopped the lean without stopping the tower.

They removed soil from underneath the high side, millimeter by millimeter. They anchored the base. They installed steel braces just long enough to stabilize, then removed them. They froze the structure in place and slowly coaxed it back by 40 centimeters.

Not once did they shut it down and rebuild. The tower survived because every fix happened while it was still standing.

Pisa isn’t the only place where this logic shows up. Look at a rainforest. Nothing gets a clean reboot there, either. No tree wakes up one morning and says, “This trunk is messy, let’s start from scratch.” Life builds on top of life.

Pisa teaches you how hard systems survive. The rainforest teaches you how living systems evolve.

Put them together and you get the real insight: resilient systems don’t rebuild; they regenerate while staying alive. This is the perfect doorway into one of my favorite patterns in software: The Strangler Fig.

The Pattern

In nature, a strangler fig starts as a small sapling attached to a host tree. It doesn’t kill the host immediately. It wraps around it, grows stronger, forms its own trunk, and eventually, the old tree becomes irrelevant. The forest never pauses. The transformation is silent, incremental, and inevitable.

That’s exactly how modern software should replace itself.

Martin Fowler described this beautifully years ago. But the magic isn’t in the metaphor; it’s in the mindset. Instead of tearing down a legacy system, you place an interception layer in front of it. You carve out small pieces, build new components around them, reroute traffic, and slowly retire the old parts.

It sounds elegant. In practice, it’s often the only path that keeps your product alive while everything around it changes.

When to use it: The moments that make founders sweat

You don’t use this approach when things are simple. You use it when touching your own codebase feels like defusing a bomb.

Apply this logic when:

1. The system is live. Uptime isn’t a technical requirement; it’s a revenue line. You can’t switch the engine off mid-flight.
2. The logic is lost. The business logic is too tangled for anyone to claim they understand everything. Engineers whisper in Slack, “Who wrote this?” and the answer is always “No idea.”
3. You need speed. You’re moving to the cloud, but a full migration would freeze feature development for months. No startup survives months of stillness.
4. You are resource-constrained. You can’t afford a parallel rewrite team. That’s a luxury for large, slow companies.

How to apply it: Reliability, Cost, and Operations

Here’s how to make it work in the real world. This isn't just about writing new features; it is the ultimate form of refactoring legacy code—not by changing lines within a file, but by changing components within an architecture.

1. Reliability: Shrink the blast radius
Most founders overestimate the reliability of rewrites and underestimate the reliability of gradual transitions.

• Start small. Pick a reporting endpoint or a pricing rule. Never start with checkout or login.
• Shadow traffic. Before you switch users over, route 0% of real users but 100% of "shadow" requests. Compare the logs. Does the new service return the same data as the old one?
• The 1% Toggle. Shift 1% of traffic. Monitor. Stress test. Gradually scale to 100%.

2. Cost Optimization: Solve the problem, don't re-architect the world
A rewrite burns time, money, and team morale. Incremental migration burns only the parts that hurt.

• Move CPU-heavy workloads first. Shift them to managed cloud services. The old system remains untouched, but your infrastructure bill starts dropping immediately.
• Retire expensive code paths. Once a new slice is stable, kill the old one. That’s real cost savings with minimal risk.

3. Operational Excellence: The new system trains the team
Teams that adopt this pattern accidentally become better. They design cleaner interfaces because every new component must stand alone. They learn rollback discipline because each migration is effectively a mini-launch.

Legacy to Cloud: The Myth of the "Big Bang"

Cloud migration is where the difference between theory and reality becomes painful. In theory, you lift and shift. In reality, you lift and crash.

The giants we admire didn’t move to the cloud; they grew into it.

• Netflix didn’t flip a switch to leave the data center; they evaporated their monolith slowly, function by function, until the data center was empty.
• Swiggy didn’t pause operations to build a new pricing engine; they carved it out while millions of orders flowed through.

They understood a fundamental truth: Data gravity is heavy. You cannot move a massive, entangled database to the cloud in a weekend. You have to move the application logic first, redirect the flow, and let the data follow naturally.

The "Big Bang" migration is a myth. A successful cloud transformation is just a thousand small, boring deployments that happened while no one was looking.

Why Builders Must Become Gardeners

We are trained to be architects. We love blueprints, clean lines, and fresh foundations. But the reality of a successful startup is much closer to a rainforest than a construction site.

A rewrite is an attempt to impose order on chaos. It fails because the market is chaos. By the time you finish your perfect rewrite, the market has moved, and your new system is already obsolete.

As I wrote in Why Rewrites Fail and Ugly Code Survives, the "ugly" legacy code you want to delete is actually a record of every problem your business has ever solved. When you rewrite, you lose that knowledge.

The Strangler Fig pattern works because it is humble.

• It respects the code that pays the bills today.
• It accepts that we cannot predict the future.
• It allows us to change direction mid-flight.

If you are looking at your legacy codebase and dreaming of a bulldozer, stop. Look at Pisa. Look at the forest. The strongest things in the world aren't built in a day, and they aren't fixed in a day. They are nudged, grafted, and guided.

Don't replace your system. Let it grow.