Walking through a dense rainforest in Queensland, Australia. You might spot a massive, hollow tree with an intricate lattice of roots. This is the Strangler Fig. It has a unique way of growing. It does not start on the ground. Instead, it begins as a seed dropped in the branches of a host tree. Slowly, it sends roots down toward the earth, gradually wrapping around the host. Over many years, the fig takes over the structure, and the original tree eventually fades away, leaving the fig standing strong in its place.
Now, let’s leave the rainforest and descend into the basement of a busy city hospital.
Down here, past the laundry chutes and the backup generators, sits a row of humming, beige server racks from the late 90s. This is the hospital’s “host tree.” It runs the legacy software that manages patient records, billing, and prescriptions. It is old, it is clunky, and it is vital. If you simply pulled the plug to install a modern system, the hospital would grind to a halt.
This is where software engineers look to nature for a solution. We call it the Strangler Fig Pattern.
Evolution Over Revolution
In the early days of software, when a system became outdated, companies would often attempt a “Big Bang Rewrite.” This meant freezing the old system and spending years building a shiny new replacement from scratch. This approach is risky. It is expensive. It often fails because, by the time the new system is finished, the business needs have changed.
The Strangler Fig pattern offers a different path. It focuses on gradual evolution rather than sudden revolution.
Here is how it works. You do not touch the old system in the hospital basement. Instead, you build a new, modern application right next to it. You identify one small, specific function to move over. Perhaps it is just the “Patient Check-In” feature.
You create a digital traffic cop, known as an API gateway or proxy, that sits between the users and the systems. When a patient checks in, the traffic cop sends that specific request to the new system. For everything else, like billing or lab results, the traffic cop sends the request to the old system in the basement.
To the user, nothing has changed. The transition is seamless. But behind the scenes, the new system is slowly taking over the load, root by root.
From Hospitals to Banks
While our hospital basement is a perfect visual, this story plays out in almost every industry.
Consider the world of finance. When you log into your sleek mobile banking app to transfer money, you are likely interacting with a Strangler Fig. The core banking systems that hold the actual money and ledgers were often written in the 1970s or 80s using a language called COBOL. These systems are incredibly stable, but they are hard to update.
Banks cannot risk shutting down their core ledgers to rewrite them. Instead, they build modern layers around them. The mobile app (the Fig) handles the user interface, identity verification, and budget tracking. It only talks to the old mainframe (the Host) when it absolutely has to. Over time, the bank can rewrite those core functions one by one, retiring pieces of the old mainframe without ever taking the bank offline.
Why Grow a Fig?
Why do engineers prefer this slow, creeping method over a quick fix? The answer lies in safety and value.
1. Reduced Risk
If you launch a massive new system all at once and it crashes, it is a disaster. With the Strangler Fig, you are only launching one small piece at a time. If the new “Patient Check-In” feature has a bug, you simply switch the traffic cop back to the old system while you fix it. The hospital keeps running.
2. Immediate Value
A full rewrite might take two years before anyone sees a benefit. With this pattern, the hospital staff gets a better check-in experience in a few weeks. Then, a month later, they get a better billing system. The improvements are continuous.
3. preserving Knowledge
Old systems are full of “business logic,” which are the specific rules about how the hospital runs. These rules are often not written down anywhere but in the old code. By replacing the system piece by piece, you ensure you capture all these hidden details.
The Thorns in the Process
Of course, growing a Strangler Fig is not without challenges.
The biggest hurdle is complexity. For a long time, you have to manage two systems at once. You are paying for the electricity in the basement for the old server while paying for the cloud hosting of the new system. It requires a disciplined team to ensure the old system is actually being retired and not just ignored.
There is also the human element. Change is hard. Staff members might be used to the quirks of the old green-screen monitors. Introducing a new workflow requires patience and training.
How to Overcome the Challenges
Success with this pattern comes down to a clear roadmap. You must identify which “roots” to plant first. Usually, it is best to start with a feature that is low-risk but high-value. This gives the team a quick win and builds confidence.
Communication is also key. Developers need to talk to the doctors, nurses, or bank tellers. They need to explain that while the interface might look different, the data underneath is safe.
Embracing the Slow Growth
The Strangler Fig teaches us that the best way to improve complex systems is not to destroy them, but to embrace them and slowly make them better. Whether you are a software engineer dealing with legacy code, or a manager trying to modernize a business process, the lesson is the same.
Do not try to change everything overnight. Identify the most critical area that needs improvement. Build a solution for that specific part. Let it take root. Then, move to the next part.
By the time you are done, the old, creaky system in the basement will be gone, replaced by something strong, modern, and ready for the future.
Have you ever seen a “Big Bang” rewrite fail? Or have you successfully used a gradual approach to solve a problem?