What the strangler fig pattern actually is
In a rainforest, a strangler fig starts as a seed dropped high in a host tree. It sends roots down, wraps the trunk, and grows slowly while the old tree keeps standing. Years later the host is gone and the fig stands on its own, shaped like the tree it replaced.
Software people borrowed the image for a very practical reason. The strangler fig pattern is a way to replace an old system piece by piece while it keeps running, instead of switching it off on a single day and hoping the new one works. You build new functionality around the edges of the legacy application, route more and more traffic to it, and retire the old parts as they become unused.
If you run a business on software that is ten or fifteen years old, this is probably the most useful idea in modernization. It turns a scary, all-or-nothing rewrite into a series of small, reversible steps, each of which can be judged on its own results.
Why big-bang rewrites go wrong
The tempting alternative is the full rewrite: freeze the old system, build a brand-new one in a back room, and cut over when it is ready. It sounds clean. In practice it tends to fail in predictable ways.
- The old system keeps changing. Your business does not pause for 18 months. New rules, new customers and new integrations keep landing in the legacy code, and the rewrite is chasing a moving target.
- Hidden behavior gets lost. Old systems quietly do dozens of things nobody wrote down: a rounding rule, a nightly clean-up, an exception for one big customer. A rewrite only discovers these after launch.
- Nothing is delivered until everything is delivered. You pay for months of work before a single user benefits, and you cannot tell whether the project is truly on track.
- Cutover day is a cliff. If something is wrong, rolling back may mean losing days of new data.
None of this means rewrites never work. It means the risk is concentrated in one moment, and for a small or mid-sized company that moment can be very expensive. The strangler approach spreads the risk across many small moments instead.
How it works, in plain English
The pattern has three moving parts. You do not need to be technical to follow them.
- A routing layer in front. Think of a receptionist. Every request, whether a page view, an API call or a form submission, goes through one front door that decides whether the old system or the new one should handle it.
- New slices, one at a time. You pick one piece of functionality, such as customer login, quoting or invoicing, and rebuild just that piece as a modern service or module.
- Gradual cutover and retirement. You send a small share of traffic to the new slice, watch it, then send all of it. When nothing uses the old code for that piece anymore, you delete it.
Repeat until the old system has nothing left to do. At every point in the middle, the business is running normally, because the old system is still there as a safety net.
A simple example
Imagine a distribution company with a 12-year-old order system. Staff use it all day, customers email orders in, and a separate spreadsheet tracks shipping. Everyone agrees it is slow and brittle, but nobody wants to touch it.
Under a strangler approach, the first slice might not be the order system at all. It might be a simple customer portal where buyers can check order status, which today consumes hours of phone and email time. The portal reads data from the legacy system through a thin connector, so nothing in the old system has to change. Customers see value in the first release, and the team learns how the legacy data really behaves.
The second slice might be quoting. The routing layer sends quote requests to the new module and everything else to the old system. The third might be invoicing. Months later, the order screen itself is the last piece to move, and by then it is a small, well-understood job rather than a leap into the unknown.
This example is illustrative, not a specific client engagement, but the shape is typical of how modernization goes when it is done in slices.
Where to start: choosing the first slice
The first slice sets the tone for the whole project, so choose it deliberately. Good first candidates share a few traits.
- Clear edges. The feature has well-defined inputs and outputs and does not tangle with ten other parts of the system.
- Visible business value. Customers or staff will notice the improvement quickly, which builds trust and momentum.
- Low blast radius. If something goes wrong, the damage is limited and easy to reverse.
- Real pain today. It is slow, error-prone or costly to maintain, so the win is measurable.
Avoid starting with the most central, most tangled piece, usually the core data model. You will get to it eventually, but you want a few successes and a deeper understanding of the old system first.
The supporting techniques that make it safe
The routing layer is the headline, but a few quieter practices are what make the pattern work reliably.
Run old and new side by side
For critical flows, you can let the new slice process the same inputs as the old one in the background and compare the answers without showing them to anyone. Differences point to hidden rules you would otherwise find in production. It costs some extra effort, but for billing, payroll or inventory logic it is worth it.
Use feature flags and gradual rollout
A feature flag is simply an on/off switch for a behavior. With one in place, you can enable the new slice for your own staff first, then for a handful of friendly customers, then for everyone. If something looks wrong, you flip the switch back. That ability to reverse a decision in minutes is what makes small steps so much safer than a big launch.
Protect the data
Data is the hardest part of any migration. Sometimes the new slice can read from the legacy database directly. Sometimes it gets its own database and the two are kept in sync for a while. Either way, plan who owns each piece of data at each stage, so you never end up with two systems disagreeing about the truth.
Write down what the old system does
As each slice is replaced, capture its real behavior in simple documents and automated checks. By the end you have not just a new system but an accurate description of how your business actually runs, which is something most companies have never had.
What it costs and how long it takes
Honest answer: it depends on the size and condition of the legacy system, how well its data is understood, and how many integrations hang off it. What we can say is how the pattern changes the shape of the spend.
Instead of one large bill and a long wait, you fund a sequence of defined slices. Vadimages projects start at $5,000+, and a modernization effort can begin with a single well-scoped slice at that level, such as a customer portal or a reporting layer, rather than a multi-year commitment. Each slice has its own scope and price, so you can stop, pause or change direction between steps. You can see how we think about budgets on our pricing page.
There is usually also an overlap cost. For a while you are running and maintaining both the old and the new pieces. That is real, and worth planning for, but it is the price of never having a cliff-edge launch.
When the strangler fig pattern is not the right tool
It is a strong default, not a universal answer. A few situations call for something different.
- The system is small and simple. If the whole application can be rebuilt in a few weeks, a direct replacement may be cheaper than building a routing layer.
- There is no way to intercept traffic. Some very old or closed systems offer no clean point to put a front door. You may need to start with a connector or a data-level approach.
- The platform is being shut down. If a vendor is ending support on a fixed date, your timeline may force a faster path, and the plan should be built around that date.
- Nobody owns the decision. The pattern needs someone on your side who can prioritize slices and say yes or no. Without that, it drifts.
A good partner will tell you honestly which of these applies, even when the answer is less work for them.
Signs you are a good candidate
Businesses that benefit most usually recognize themselves in several of these:
- The software works, but changes take weeks and often break something unrelated.
- Only one or two people truly understand how it runs.
- You keep working around it with spreadsheets, email and manual re-keying.
- You have been told a rewrite is the only option and the price or timeline frightened you.
- You want to add things like a customer portal, integrations or better reporting but the old system makes each one painful.
If that list sounds familiar, you are likely paying a hidden tax every month already. The strangler approach lets you start reducing it without betting the company on a single launch. Our custom software and solutions pages describe the kinds of systems we build as the new slices, and our industries page shows where we see these legacy patterns most often.
How we run a strangler-style engagement
Every project is different, but the rhythm is consistent, and it matches what we describe on our how we work page.
- Discovery. We map the current system, its data and its integrations, and talk to the people who use it every day. The output is a plain-English picture of what exists and what hurts.
- Slice plan. Together we rank candidate slices by value, risk and dependency, then fix a scope and price for the first one.
- Build and release. We build the slice, route a small share of traffic to it, compare results, and widen the rollout when it behaves.
- Retire and repeat. We remove the old code that is no longer used, update the documentation, and move to the next slice.
You see working software early and often, and you decide at every step whether to continue. If you would like to see how modernization projects are typically structured, our case studies page is a good starting point.
The takeaway
The strangler fig pattern is not clever technology. It is a discipline: do not replace what you cannot yet replace safely, put a front door in place, move one slice at a time, and let the old system fade out when it is no longer needed. For most small and mid-sized businesses, that is a calmer, cheaper-to-start and far less risky way to escape an aging system than a rewrite.
If you are weighing a rewrite against living with what you have, there is a third path. Tell us what your current system does and where it hurts, and we will give you a straight answer on whether this approach fits and what a first slice could look like. Contact us to start the conversation.