We touched on the Strangler Fig in our previous blog post about composable architecture and thought it warranted its own post. In this blog we will explore what the Strangler Fig Pattern is, where it got its name, how it’s applied in real-world legacy migrations, its potential risks and rewards, and best practices for using it effectively.

What is the Strangler Fig Pattern?

Coined by software thought leader Martin Fowler, the Strangler Fig Pattern is a strategy for incrementally replacing legacy systems with modern architectures.

Just like the strangler fig tree grows around and eventually replaces its host tree, in this pattern, new system components gradually “strangle” the old system, replacing one feature at a time until the legacy code is phased out entirely.

How the Patterns Are Applied

Here’s a simplified approach to how teams can implement the pattern in their legacy environments:

1. Introduce a Facade or API Gateway
   Use a proxy layer interface to intercept user requests and route them to the legacy system, usually through a software factory.
2. Identify Replaceable Features
   Start with isolated, high-impact modules (like reporting, authentication, or search).
3. Develop New Services Alongside Legacy
   Build replacement functionality using modern tech stacks. Deploy in parallel, not on top of the legacy system.
4. Redirect Traffic Gradually
   Route requests from the old system to the new as features go live. This reduces risk and enables real-world testing. Old and new parts of the system can be toggled through the factory.
5. Decommission Legacy Code
   Once all legacy functionality has been replaced, the old system can be safely retired.

Recommendations

The simplest recommendation is to continue with the existing technology languages and operating systems that your legacy system currently runs on. If JAVA or C/C++, an argument can be made to build the new software in the same language, using newer features and turning the code to a modern, modular, and elegant product to carry you into the future.

COBOL, Pascal, Fortran, Objective-C, and Microsoft VB1-VB6, are just a few examples of dead or dying computer languages. COBOL has been dying for at least three decades now, yet remains. If working with a dead or dying technology stack, then this is where REST, SOAP, or Native APIs supply the glue between old and new technologies. Assuming SOAP or REST calls, the new APIs can be written on most languages that your team is proficient with, provided that the business need can be met with available libraries.

If using a native API, the new code stack will likely need to meet a C type interface, JNI on JAVA, P/Invoke from dotNET, COM, or other, that each can use effectively. This will mean having a strategy for memory management across these systems.

We discuss additional recommendations in more detail in our downloadable 5 Step Guide to Legacy Migration which will be available on our website in late August 2025.

When Is It Risky to Use?

While the Strangler Fig Pattern is ideal for many scenarios, there are some environments where it’s less suitable:

• Highly Entangled Monoliths
  If your system has deeply interdependent modules with no clear separation of concerns, it can be hard to isolate functions to strangle.
• Lack of Observability
  If your team can’t measure usage, performance, or dependencies, it’s difficult to safely reroute traffic.
• No Proxy Layer
  If you’re unable to introduce a routing layer (due to security, compliance, or technical constraints), implementing this pattern becomes complex.
• Time-Sensitive Business Operations
  Industries like healthcare or aviation with real-time systems may require extra validation, sandbox environments, or staged rollouts before applying this method.

Financial Implications

The financial benefits of using the Strangler Fig Pattern can be significant—especially when compared to full rewrites or “rip-and-replace” approaches.

Cost Benefits

• Lower Upfront Investment: Pay for incremental improvements, not a massive overhaul.
• Reduced Business Disruption: Avoid downtime and the revenue loss associated with system outages.
• Smaller Team Footprint: You can use agile sprints to modernize component-by-component.

Ongoing Cost Considerations

• Dual Infrastructure Costs: You may need to temporarily support both old and new systems.
• Technical Overhead: Routing logic and monitoring need to be maintained until full migration is complete.
• Training/Skill Development: Team members may need to learn both the legacy stack and a modern one.
• Staff Augmentation: If your team is limited on bandwidth or skillset accessing a third-party vendor who offers staff augmentation services may be a cost-effective alternative.

Potential Pitfalls

1. Inconsistent User Experience
   If changing technologies and the UI and logic are partially split between systems, users may notice inconsistencies or bugs.
2. Complexity in Routing Logic
   Improper routing between legacy and modern systems can lead to data loss, duplication, or logic errors.
3. Overlong Migration Timelines
   Teams that fail to plan clearly may end up in “perpetual hybrid” mode, never completing the migration.
4. Insufficient Testing
   Skipping proper end-to-end testing between old and new systems can introduce regressions that are hard to trace.

Alternative Names & Concepts

While “Strangler Fig Pattern” is the most well-known term, similar approaches include:

• Incremental Re-Architecture
• Modular Migration
• Parallel Modernization
• Facade + Proxy Modernization
• Sidecar Refactoring (common in microservices)

These are conceptually similar: all focus on evolving a system gradually rather than rewriting it all at once.

Best Practices for Success

• Start with Low-Risk Features
  Choose functionality that’s easy to isolate and won’t disrupt critical operations.
• Use Feature Toggles
  Gradually switch users over without full redeploys.
• Automate Monitoring & Rollbacks
  Integrate health checks, usage metrics, and rollback capabilities into each new component.
• Document Dependencies & Interfaces
  Thorough documentation prevents teams from recreating legacy issues in modern code.
• Create a Sunset Plan
  Establish deadlines and goals for fully decommissioning legacy systems to avoid hybrid system fatigue.

In Summary

The Strangler Fig Pattern offers a smart, flexible approach to legacy system modernization—reducing risk, limiting or avoiding downtime, and aligning with modern DevOps and cloud-native practices. When implemented correctly, it can dramatically improve agility and reduce the long-term costs of supporting outdated technologies.

Apply with caution as it’s not a silver bullet. Organizations must carefully assess their infrastructure, business requirements, and available resources before committing. With the right tools, skilled teams, and strategic planning, the Strangler Fig Pattern can turn even the most stubborn monolith into a scalable, modern system—without cutting down the business tree it supports.

Need help assessing if the Strangler Fig Pattern is right for your legacy systems?

Let’s talk about your infrastructure, risks, and how to modernize—on your terms. Reach out to our Advisory Team to get started.

The post Modernizing Legacy Systems with the Strangler Fig Pattern: Best Practices, Risks & Financial Implications first appeared on STEP Software.