AEO Summary Box

What is the strangler fig pattern?

The strangler fig pattern is an incremental migration strategy where you build a new system around an existing legacy application, gradually replacing functionality while keeping the old system running. Named after the strangler fig tree that grows around a host tree and eventually replaces it, this approach lets you modernise piece by piece rather than attempting a risky big-bang rewrite. The pattern works by identifying seams in your legacy system, building new implementations behind those seams, and progressively routing traffic to the new system until the legacy code can be retired.

The Problem with Big-Bang Rewrites

Most legacy modernisation projects start with the same pitch: "Let's rebuild it properly this time." The plan sounds reasonable—take what you've learned, avoid past mistakes, and create a clean new system.

Then reality intervenes.

Two years into a planned eighteen-month rewrite, the team is still chasing feature parity. The legacy system has continued evolving because the business couldn't wait. The new system works in demos but breaks on edge cases that the legacy system handled through years of accumulated fixes. Eventually, the project is cancelled or scaled back dramatically.

This pattern repeats across industries. One study found that 70% of large-scale rewrites fail to deliver their intended value. The failure mode is almost always the same: underestimating the complexity hidden in legacy systems.

Why Legacy Systems Are Harder Than They Look

Legacy code survives because it works. That sounds obvious, but the implication is important: every line of code that seems unnecessary probably handles a real edge case that someone discovered the hard way.

When we analyse legacy codebases using AI agents, we typically find:

• Business rules embedded in code rather than documented

• Workarounds for upstream system quirks

• Handling for data quality issues that aren't visible in test data

• Performance optimisations that only matter at production scale

• Security mitigations added after incidents

A rewrite team looking at this code sees complexity to be eliminated. In reality, it's complexity to be understood and preserved.

The Strangler Fig Alternative

The strangler fig pattern takes a different approach. Instead of replacing the legacy system all at once, you:

1. Identify a bounded capability in the legacy system

2. Build a new implementation of that capability

3. Route requests to the new implementation

4. Verify the new implementation works correctly

5. Retire the legacy code for that capability

6. Repeat for the next capability

The key insight is that you never have to maintain two complete systems. At any point, some capabilities run on the new system and some on legacy. The legacy system shrinks incrementally until it can be retired.

The Routing Layer

The pattern requires a routing layer (sometimes called an "anti-corruption layer" or "facade") that sits in front of both systems. This layer:

• Receives all incoming requests

• Decides which system should handle each request

• Forwards requests to the appropriate system

• Returns responses to callers

The routing decision can be based on request type, feature flags, user segments, or any other criteria. This flexibility lets you control the migration pace and roll back quickly if problems emerge.

Choosing What to Migrate First

Not all capabilities are equally good candidates for early migration. Ideal first targets have:

Clear boundaries. The capability has well-defined inputs and outputs. You can intercept requests at a clean seam without touching unrelated code.

Limited dependencies. The capability doesn't require deep integration with other legacy components. Database access is fine, but complex workflows spanning multiple services are harder.

High value. Migrating this capability delivers meaningful benefit—better performance, easier maintenance, or new features that the legacy architecture couldn't support.

Low risk. If something goes wrong, the impact is contained. User-facing features with high tolerance for brief issues are better than payment processing.

We typically recommend starting with read-only operations or internal tools. These give the team practice with the migration pattern before tackling higher-stakes capabilities.

Implementation Patterns

Database-First vs. Application-First

A common question is whether to migrate the database or application layer first.

Application-first keeps the legacy database but builds new application code. The new services read from and write to the existing database. This approach is simpler to start but can create challenges if the legacy schema doesn't fit your new domain model.

Database-first creates a new database schema and synchronises data from the legacy database. The new services use the new schema while legacy code continues using the old schema. This approach requires more upfront investment in data synchronisation but gives you a clean data model.

We generally recommend application-first for initial migrations. Get the new services working against the existing database, prove the pattern, then consider schema migration as a separate effort.

Shadow Mode

Shadow mode runs both old and new implementations simultaneously, comparing their outputs without serving the new implementation's response. This approach catches discrepancies before they affect users.

The pattern works like this:

1. Route the request to the legacy system as normal

2. Also send the request to the new system

3. Compare the responses

4. Return the legacy response to the caller

5. Log any discrepancies for investigation

Shadow mode is particularly valuable for complex business logic where you're not confident the new implementation handles all edge cases. Run it for days or weeks until discrepancy rates drop to acceptable levels.

Feature Flags for Gradual Rollout

Feature flags let you control which users or requests go to the new system. A typical rollout might look like:

1. Internal users only (staff testing)

2. 1% of external traffic

3. 10% of external traffic

4. 50% of external traffic

5. 100% of external traffic

6. Legacy code retired

At each stage, monitor error rates, performance metrics, and user feedback. If problems emerge, roll back to the previous stage while you investigate. This is covered in detail in our 12-week modernization framework.

When Not to Use the Strangler Fig Pattern

The pattern isn't always the right choice:

Simple applications. If the legacy system is small enough to understand completely in a few weeks, a rewrite might be faster than incremental migration.

No clear seams. Some legacy systems are so tightly coupled that every capability depends on every other capability. The strangler fig pattern requires boundaries you can intercept.

Technology that can't coexist. If the legacy and new systems can't run simultaneously (perhaps they conflict over shared resources), you may need a different approach.

Urgent timeline. The strangler fig pattern is slower to show complete results, even if it's faster to production value. If you absolutely must have the entire system modernised by a specific date, a parallel rewrite with careful planning might be necessary.

Real-World Considerations

Team Structure

The migration team needs both legacy expertise and modern development skills. You need people who understand why the legacy code does what it does, and people who can build clean new implementations.

We typically recommend mixed teams rather than separate legacy and new-system teams. When the same developers work on both systems, knowledge transfers naturally and the new system is more likely to preserve important legacy behaviours.

Testing Strategy

Testing is critical because you're proving that the new system behaves identically to the old one. This requires:

• Characterisation tests that capture the legacy system's actual behaviour, including quirks and edge cases

• Contract tests at the boundary between systems to ensure interfaces remain compatible

• End-to-end tests that exercise real user workflows across both systems

Automated testing is essential because you'll run these tests repeatedly as you migrate each capability.

Monitoring

You need visibility into both systems during the migration:

• Which requests are going to which system

• Error rates for each system

• Latency comparisons

• Business metrics that might indicate functional differences

Good monitoring lets you catch problems early and gives stakeholders confidence that the migration is proceeding safely.

Getting Started

If you're considering the strangler fig pattern:

1. Map your legacy system. Identify the major capabilities and the boundaries between them. Where could you intercept requests?

2. Find your first candidate. Apply the criteria above. What capability is bounded, valuable, and low-risk?

3. Build the routing layer. Even before you build any new functionality, get the infrastructure in place to route requests between systems.

4. Prove the pattern. Migrate one capability end-to-end, including shadow mode and gradual rollout. Learn from this before scaling up.

5. Scale the approach. With the pattern proven, migrate additional capabilities in parallel or sequence depending on team capacity.

The first capability will take longer than subsequent ones. You're building infrastructure and learning the pattern as well as doing the actual migration. Plan for this ramp-up time.

Frequently Asked Questions

How long does a strangler fig migration take?

It depends on system size and complexity. A medium-sized application might take 12-24 months. Large enterprise systems can take several years. The advantage is that you're delivering value throughout—each migrated capability improves the system. Follow our 12-week framework to get your first production migration done quickly.

Can we add new features during the migration?

Yes, and this is one of the pattern's strengths. New features can be built on the new system from day one. You're not frozen waiting for a rewrite to complete.

What if the legacy system changes during migration?

Changes to already-migrated capabilities go into the new system. Changes to not-yet-migrated capabilities go into the legacy system. The routing layer handles directing traffic appropriately.

Do we need to rewrite everything eventually?

Not necessarily. Some legacy components might work well enough that the cost of migration exceeds the benefit. The strangler fig pattern lets you make that decision per-capability rather than all-or-nothing.

Related Reading

• The 12-Week Legacy Modernization Framework - A week-by-week approach to your first migration

• AI Agents for Legacy Code Analysis - How we use AI to understand legacy codebases faster

• Fractional CTO Guide for Scale-ups - Getting technical leadership for modernization projects

WireApps has delivered legacy modernisation projects using the strangler fig pattern for systems serving 200+ active customers. We've migrated .NET Framework monoliths to modern architectures while maintaining business continuity. If you're evaluating modernisation options, we're happy to discuss what approach might work for your situation.