What is Strangler Pattern? 

Every enterprise architecture team eventually hits the same wall: a core system that still runs the business but is too risky to touch, too expensive to leave alone, and too large to replace in one shot. The strangler fig pattern is the answer most teams reach for, and MuleSoft’s Anypoint Platform is one of the most common ways enterprises put it into practice.

Quick answer: The strangler fig pattern replaces a legacy system gradually by building new services alongside it and routing traffic away from the old system one piece at a time, until nothing is left to retire. MuleSoft implements this through API-led connectivity: System, Process, and Experience APIs, combined with Anypoint Flex Gateway to control which requests go where during the transition.

This guide updates our original take on the topic with where MuleSoft’s tooling actually stands today, including Universal API Management, Flex Gateway, CloudHub 2.0, and how the pattern now extends into Agentforce and AI agent integrations.

What Is the Strangler Fig Pattern?

The strangler fig pattern is a software migration approach named after the strangler fig tree, a plant that grows around a host tree and gradually takes over its structure until the original tree is gone. Martin Fowler popularized the term for software architecture, and the metaphor still holds: new services grow around a legacy application, take on its responsibilities piece by piece, and the legacy system is decommissioned once nothing depends on it anymore.

It is not a rewrite. A rewrite treats modernization as one project with one cutover date. The strangler fig pattern treats it as a series of small, reversible moves, with the legacy system and the new services running side by side for as long as the migration takes.

Why the Strangler Fig Pattern Still Matters for Legacy Modernization in 2026

Big-bang rewrites remain tempting because they look tidy on a roadmap, but the numbers keep telling a different story. Recent industry analysis puts the failure or underperformance rate of large modernization projects at roughly 68 to 79 percent, usually because of weak stakeholder alignment and incomplete system assessment rather than bad technology choices. Separate research on completed enterprise modernization programs has linked incremental, phased migrations to infrastructure cost reductions of 30 to 50 percent and development cycle time improvements of 20 to 30 percent.

The practical takeaway for architects: the pattern isn’t a nice-to-have risk-mitigation technique anymore, it’s closer to table stakes for any legacy migration with real production traffic and real business risk attached.

The Core Stages of a Strangler Fig Migration

Regardless of the tooling behind it, every strangler fig migration follows the same shape:

  1. Identify the slice. Pick a bounded piece of functionality in the legacy system, order processing, customer lookup, billing, that can be extracted with a clear boundary.
  2. Build the replacement. Develop a new service or API that replicates that functionality, ideally with room to improve on it.
  3. Introduce a routing layer. Put a facade, proxy, or API gateway in front of both systems so traffic can be redirected without the consumer noticing.
  4. Migrate and validate. Shift traffic to the new service in stages, watch for behavioral differences, and roll back through the same routing layer if something breaks.
  5. Retire the old slice. Once the new service has proven itself under real traffic, decommission the corresponding piece of the legacy system.
  6. Repeat. Move to the next slice until the legacy system has nothing left to do.

How MuleSoft Anypoint Platform Applies the Pattern

MuleSoft didn’t invent the strangler fig pattern, but its API-led connectivity model maps onto it almost exactly. Instead of one big facade, you get three purpose-built API layers plus a gateway that decides where traffic goes.

Step 1: Assess and Segment the Legacy System

Start by mapping what the legacy system actually does, order processing, customer records, billing, inventory, and which of those functions are safe to extract first. This assessment work is where most failed modernization efforts actually go wrong, so it deserves more time than teams usually give it.

Step 2: Expose Legacy Functionality Through System APIs

System APIs sit closest to the legacy system and core records. Build one that wraps the legacy application and exposes its data through a governed, documented interface, so nothing downstream talks to the legacy database or file system directly anymore.

#%RAML 1.0
title: Legacy Orders System API
baseUri: http://api.company.com/legacy
/orders:
  get:
    description: Fetch orders from the legacy order-management system
    responses:
      200:
        body:
          application/json:
            example: |
              [
                { "orderId": 1, "item": "Laptop", "quantity": 1 },
                { "orderId": 2, "item": "Smartphone", "quantity": 3 }
              ]

MuleSoft’s API design tooling supports both RAML and the OpenAPI Specification (OAS) today, so teams can standardize on whichever spec format fits their existing API governance model.

Step 3: Orchestrate Legacy and New Services with Process APIs

Process APIs combine the legacy System API with any new microservices you’ve already built, so consumers get one consistent interface regardless of which side is doing the actual work. This is the layer where business logic and orchestration live, and it’s what lets you swap out legacy pieces without touching every downstream consumer.

Step 4: Deliver Channel-Specific Experience APIs

Experience APIs shape data for specific consumers, a mobile app, a partner portal, an internal dashboard, so the complexity of the legacy-to-modern transition stays hidden from the people actually using the data.

Step 5: Route Traffic with Anypoint Flex Gateway and Universal API Management

This is where the pattern’s facade concept becomes concrete. MuleSoft’s Universal API Management (UAPIM) and Anypoint Flex Gateway let a team manage and secure Mule and non-Mule APIs from a single control plane, regardless of where each service runs. In practice, that means the gateway decides, request by request, whether traffic goes to the legacy System API or the new service that has replaced it, and that decision can change without redeploying anything downstream. Flex Gateway is available fully managed on CloudHub 2.0 or self-managed for Kubernetes, on-premises, and edge environments, so the routing layer can live wherever the legacy system actually runs.

Step 6: Automate Delivery with Anypoint Platform CI/CD

Anypoint Platform integrates with CI/CD tooling such as Git, Jenkins, and Maven, and Anypoint Code Builder gives teams an IDE-based workflow for building and testing APIs faster than the older Studio-only approach. Deploying new slices should be routine by the time you’re a few iterations into the migration, not an event.

Step 7: Monitor and Govern the Migration with Anypoint Monitoring

Anypoint Monitoring and API Governance track performance and policy conformance across every layer, which is how teams know when a slice is genuinely ready to have its legacy counterpart switched off, rather than guessing.

How the Strangler Fig Pattern Connects to Agentforce and AI Agents

The strangler fig pattern used to be a purely human decision about which legacy function to replace next. That’s changing. MuleSoft is the connectivity layer behind Agentforce, and Salesforce has published guidance on exposing MuleSoft-built services as Model Context Protocol (MCP) tools that Agentforce agents can call directly, using the same HTTP listener and OAuth 2.0 patterns that already secure System and Process APIs.

Practically, this means the System APIs you build to wrap a legacy application during a strangler fig migration don’t just serve human-facing apps anymore. They can become tools an AI agent calls to check an order status, pull a customer record, or trigger a billing update, without anyone writing custom code to bridge Salesforce and the legacy backend. Read more about how MuleSoft Agent Fabric secures enterprise AI integration if agent-driven automation is on your roadmap alongside the migration itself.

Strangler Fig Pattern Risks and Common Pitfalls

  • Shared databases. If the new service and the legacy system both write to the same database, you’ve built a strangler in name only. Keep data ownership separate and sync deliberately.
  • Scope creep at the facade. The routing layer should route, not accumulate business logic. Let that discipline slip and the facade becomes its own legacy problem.
  • No clear “done” per slice. Define what “fully migrated” means for each slice before you start, or the legacy system quietly stays half-alive indefinitely.
  • Treating governance as an afterthought. Without API governance and monitoring in place from the first slice, teams lose visibility into which parts of the legacy system are actually safe to retire.

Cloud Odyssey’s Point of View on Strangler Fig Migrations

Most strangler fig write-ups stop at the mechanics: build the facade, route the traffic, retire the old code. What we’ve seen across MuleSoft engagements is that the harder call is almost never technical, it’s deciding which slice to strangle first and holding that decision when priorities shift mid-project. Teams that treat the migration as a governed backlog, with an owner, a target state, and a rollback plan per slice, get through it. Teams that treat it as a side project alongside business-as-usual work tend to end up running two systems indefinitely, which is the one outcome the pattern was supposed to prevent.

The other shift worth planning for now: the APIs you build during a legacy migration increasingly double as the tools your AI agents will call later. Designing System and Process APIs with that second consumer in mind, not just the human-facing app you’re building today, saves a second round of API work once Agentforce or another agent framework enters the picture. If you’re weighing where to start, our MuleSoft integration services team can walk through your legacy estate and map out a sequencing plan before you commit to a slice.

Frequently Asked Questions

The strangler fig pattern is a migration approach where new services are built alongside a legacy system and gradually take over its responsibilities, until the legacy system can be fully retired. It avoids a single high-risk cutover by keeping both systems running throughout the transition.

A rewrite replaces the entire legacy system in one project with one cutover date, which puts the whole business at risk if something goes wrong. The strangler fig pattern migrates one bounded piece of functionality at a time, so the legacy system keeps serving traffic for everything that hasn’t been migrated yet.

MuleSoft’s API-led connectivity model provides the three layers a strangler fig migration needs: System APIs to wrap the legacy system, Process APIs to orchestrate between old and new, and Experience APIs to serve each channel. Anypoint Flex Gateway acts as the routing layer that decides which system handles each request.

The most common risks are shared databases between the legacy and new systems, business logic creeping into the routing layer, and migrations that stall indefinitely because there’s no clear definition of “done” for each slice. Strong API governance and monitoring from day one reduce all three.

Timelines depend on how many functions need to be extracted, how tightly coupled the legacy system is, and how much of the estate is already exposed through APIs. Most enterprise migrations run in phases over several quarters rather than as a single project, which is the point of using the pattern in the first place.