# Strangler Fig Pattern

URL: https://softwaredictionary.org/terms/strangler-fig-pattern
Category: Software Architecture
Last updated: 2026-09-30
In Turkish: Strangler Fig Deseni

In short: The strangler fig pattern is a way to replace a legacy system gradually by routing features to new code one at a time until the old system can be retired.

## What is the strangler fig pattern?

The strangler fig pattern is a strategy for modernizing an old application, often called a legacy system, without a risky big-bang rewrite. Instead of building a complete replacement and switching over in one day, you build new functionality piece by piece next to the old system and move traffic over gradually. Martin Fowler named it in 2004 after strangler fig trees, which grow around a host tree until they replace it.

It usually works by putting a routing layer, such as a reverse proxy or API gateway, in front of the legacy system. At first, everything goes to the old code. As each feature, for example user profiles or invoicing, is rebuilt in the new system, the router sends those requests to the new implementation while everything else still goes to the old one. Once no traffic reaches the legacy code, it can be switched off.

Think of renovating a house room by room while still living in it, instead of moving out and demolishing it. Each finished room is usable right away, and if something goes wrong you only have to fix one room. The pattern is widely used to break a monolith into microservices, move applications to the cloud, or replace an outdated framework.

The strangler fig pattern is often confused with a full rewrite, which builds the whole new system before switching and pushes all the value and risk to a single cutover day. It also differs from refactoring, which improves code structure inside the existing system rather than replacing it. The main challenges are keeping data consistent while both systems run and avoiding a migration that stalls halfway, leaving the team maintaining two systems indefinitely.

## Key takeaways

- Replace a legacy system gradually, one feature at a time, instead of in a single rewrite.
- A routing layer, such as a proxy or API gateway, decides which system handles each request.
- Each migrated piece delivers value early and can be rolled back on its own.
- Shared data and a stalled, half-finished migration are the main risks.
- It is a common way to move from a monolith to microservices.

## Example: Routing migrated features to new services

```yaml
# Routing layer in front of both systems (illustrative gateway config)
routes:
  # Already migrated: handled by the new services
  - path: /api/profiles
    target: http://profile-service:8080
  - path: /api/invoices
    target: http://billing-service:8080
  # Everything else still goes to the legacy monolith
  - path: /
    target: http://legacy-app:8000
```

## Frequently asked questions

**Why is it called the strangler fig pattern?**

Martin Fowler named it after strangler fig trees, which sprout on a host tree, grow around it over many years, and eventually replace it. The new system similarly grows around the old one until the old one can be removed.

**When should you use the strangler fig pattern?**

Use it when a large, business-critical system must be replaced but can't be frozen or switched off for a long rewrite. It works best when requests can be intercepted and routed, as with web applications and APIs.

**What is the difference between the strangler fig pattern and a rewrite?**

A rewrite builds a complete replacement and switches over all at once, which concentrates risk at the end. The strangler fig pattern migrates piece by piece, so each part goes live, gets feedback, and can be rolled back independently.

---

Software Dictionary: https://softwaredictionary.org/ · https://softwaredictionary.org/llms.txt