The Strangler Fig Pattern for C# Developers

Sat, 05 Sep 2026 00:00:00 -0400

Rewriting a legacy system in one big push almost always goes badly. The scope creeps, the business can’t freeze feature work for as long as the rewrite takes, and by the time you ship, the requirements have changed again. The Strangler Fig pattern offers a different path: build the replacement incrementally around the edges of the old system, redirecting a little more traffic to it with every release, until the legacy system has nothing left to do and you can turn it off.

Let’s Define the Pattern

The name comes from the strangler fig, a vine that germinates in the branches of a host tree. It grows downward, wrapping around the trunk and drawing nutrients until it reaches the ground and becomes self-sufficient. Eventually the host tree dies and rots away, leaving the fig standing in its place—same silhouette, entirely new structure. Martin Fowler borrowed the metaphor in 2004 to describe a style of legacy modernization where a new system is built up around an old one, taking over its responsibilities piece by piece.

Architecturally, the pattern relies on a façade (also called a router or a proxy) that sits between clients and the systems doing the work. The façade intercepts every incoming request and decides, feature by feature, whether the legacy system or the new system should handle it. Early on, almost everything goes to the legacy system. As you migrate functionality, you flip more routes over to the new system. Clients never know the difference—they keep hitting the same façade throughout the whole migration.

This is not a GoF pattern in the classic sense—there’s no single class diagram to memorize. It’s an architectural strategy, and in C# it’s usually implemented with routing middleware, a reverse proxy, or a feature-flag-driven dispatcher rather than a small set of cooperating objects.

The Problem It Solves

Imagine a monolithic ASP.NET application, LegacyOrderSystem, that has handled order creation, invoicing, and shipping for a decade. It’s slow to change, tightly coupled to an aging database schema, and everyone is afraid to touch it. Leadership wants it replaced with a modern set of services.

Option 1: Big bang rewrite

Freeze the legacy system, spend a year building NewOrderSystem from scratch, then cut over all at once. This sounds clean on a slide, but in practice:

The business can’t accept a year without new features or bug fixes to the system still generating revenue.
Nobody fully remembers every edge case the legacy system handles, so the rewrite is guaranteed to miss behavior—some of it undocumented but load-bearing.
The cutover is a single high-risk event. If something’s wrong, you’re rolling back a year of work under pressure.

Option 2: Strangler Fig migration

Introduce a façade in front of LegacyOrderSystem. Move one capability—say, invoicing—into a new service. Update the façade to route invoicing requests to the new service while everything else still goes to the legacy system. Ship it, watch it work in production, then repeat for the next capability.

// Before: clients call the legacy system directly
public class OrderController : ControllerBase
{
private readonly LegacyOrderSystem _legacySystem;
[HttpPost("invoices")]
public IActionResult CreateInvoice(InvoiceRequest request)
=> Ok(_legacySystem.CreateInvoice(request));
}

// After: a façade decides who handles the request
public class OrderController : ControllerBase
{
private readonly IOrderRequestRouter _router;
public OrderController(IOrderRequestRouter router) => _router = router;
[HttpPost("invoices")]
public async Task<IActionResult> CreateInvoice(InvoiceRequest request)
=> Ok(await _router.RouteInvoiceCreationAsync(request));
}

The controller no longer knows or cares which system ultimately handles the request. That decision lives in the router, which means the migration can proceed feature by feature without touching every call site each time.

Core Structure and Roles

The pattern has three participants:

Legacy system: The existing application. It keeps running and keeps serving whatever functionality hasn’t been migrated yet.

New system: The replacement, built incrementally. Early on it might handle only one narrow capability; eventually it handles everything.

Façade (router): The single entry point clients talk to. It inspects each request and decides where it goes.

public interface IOrderRequestRouter
{
Task<InvoiceResult> RouteInvoiceCreationAsync(InvoiceRequest request);
}
public class OrderRequestRouter : IOrderRequestRouter
{
private readonly LegacyOrderSystem _legacySystem;
private readonly IInvoiceService _newInvoiceService;
private readonly IMigrationFlags _flags;
public OrderRequestRouter(
LegacyOrderSystem legacySystem,
IInvoiceService newInvoiceService,
IMigrationFlags flags)
{
_legacySystem = legacySystem;
_newInvoiceService = newInvoiceService;
_flags = flags;
}
public async Task<InvoiceResult> RouteInvoiceCreationAsync(InvoiceRequest request)
{
if (_flags.IsMigrated(MigrationFeature.Invoicing))
{
return await _newInvoiceService.CreateInvoiceAsync(request);
}
return _legacySystem.CreateInvoice(request);
}
}

IMigrationFlags is deliberately simple here—a lookup of which capabilities have been cut over. In a real system this might be backed by configuration, a feature-flag service, or a percentage-based rollout so you can shift traffic gradually rather than as an on/off switch.

Implementing the Façade

For HTTP-based systems, the façade is often implemented as middleware or a reverse proxy rather than in-process routing logic. .NET’s YARP (Yet Another Reverse Proxy) is commonly used for exactly this: you configure routes that send some paths to the legacy application and others to new services, all behind a single public endpoint.

// Program.cs - routing configured declaratively
builder.Services.AddReverseProxy()
.LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));
app.MapReverseProxy();

{
"ReverseProxy": {
"Routes": {
"invoicing-new": {
"ClusterId": "new-invoice-service",
"Match": { "Path": "/api/invoices/{**catch-all}" }
},
"everything-else": {
"ClusterId": "legacy-order-system",
"Match": { "Path": "/{**catch-all}" }
}
},
"Clusters": {
"new-invoice-service": {
"Destinations": { "d1": { "Address": "https://invoices.internal/" } }
},
"legacy-order-system": {
"Destinations": { "d1": { "Address": "https://legacy.internal/" } }
}
}
}
}

Whether you route in-process (as with IOrderRequestRouter) or at the network edge (as with YARP) depends on your architecture. In-process routing is simpler when the new and old code share a process and a deployment. A reverse proxy is a better fit once the new system is a genuinely separate service.

Strangler Fig vs Similar Patterns

Strangler Fig vs Big Bang Rewrite: A big bang rewrite replaces the whole system in one cutover. Strangler Fig replaces it incrementally, with the old and new systems coexisting throughout. Use Strangler Fig whenever the legacy system is too large, too risky, or too business-critical to freeze for the length of a full rewrite.

Strangler Fig vs Branch by Abstraction: Branch by Abstraction introduces an abstraction layer inside a single codebase so you can swap an implementation without long-lived branches. Strangler Fig operates at a system or service boundary, often across process and deployment boundaries. They’re complementary—you might use Branch by Abstraction inside the new system while using Strangler Fig to migrate traffic to it.

Strangler Fig vs Anti-Corruption Layer: An Anti-Corruption Layer translates requests and models between two systems that need to talk to each other without leaking one system’s assumptions into the other. Strangler Fig often uses an anti-corruption layer internally—the new system needs one to call unmigrated legacy functionality without absorbing legacy quirks into its own domain model.

Strangler Fig vs Feature Toggles: A feature toggle turns functionality on or off within a single deployed system. Strangler Fig uses similar mechanics (a flag or rule deciding what happens) but the two branches are entirely separate systems, not two code paths in the same codebase.

Testing

The router is the highest-value thing to test, because it encodes your migration state. You want confidence that flipping a flag actually changes which system handles a request, and that the two systems produce compatible results while both are live.

[Fact]
public async Task RouteInvoiceCreationAsync_WhenNotMigrated_UsesLegacyGateway()
{
var legacyGateway = new Mock<ILegacyOrderGateway>();
var newService = new Mock<IInvoiceService>();
var flags = new Mock<IMigrationFlags>();
flags.Setup(f => f.IsMigrated(MigrationFeature.Invoicing)).Returns(false);
var router = new OrderRequestRouter(legacyGateway.Object, newService.Object, flags.Object);
await router.RouteInvoiceCreationAsync(new InvoiceRequest());
legacyGateway.Verify(g => g.CreateInvoice(It.IsAny<InvoiceRequest>()), Times.Once);
newService.Verify(s => s.CreateInvoiceAsync(It.IsAny<InvoiceRequest>()), Times.Never);
}
[Fact]
public async Task RouteInvoiceCreationAsync_WhenMigrated_UsesNewService()
{
var legacyGateway = new Mock<ILegacyOrderGateway>();
var newService = new Mock<IInvoiceService>();
var flags = new Mock<IMigrationFlags>();
flags.Setup(f => f.IsMigrated(MigrationFeature.Invoicing)).Returns(true);
var router = new OrderRequestRouter(legacyGateway.Object, newService.Object, flags.Object);
await router.RouteInvoiceCreationAsync(new InvoiceRequest());
newService.Verify(s => s.CreateInvoiceAsync(It.IsAny<InvoiceRequest>()), Times.Once);
legacyGateway.Verify(g => g.CreateInvoice(It.IsAny<InvoiceRequest>()), Times.Never);
}

If both systems can run side by side against the same inputs, it’s also worth writing comparison tests—call both, compare the results, and log any divergence in production before you fully cut over. This “shadow traffic” approach catches mismatches long before real users depend on the new system.

Common Pitfalls and Code Smells

Never removing the façade: The façade is transitional architecture. Once the legacy system is fully decommissioned, the router should be removed and clients should call the new system directly. Leaving it in place forever adds a permanent layer of indirection and a permanent single point of failure.

No rollback path: If flipping a migration flag can’t be reversed quickly, you’ve turned every cutover into a big-bang risk again, just spread out over more releases. Keep the old code path alive and working until you’re confident the new one has proven itself.

Letting the legacy system keep growing: If new features keep landing in the legacy system because “it’s easier for now,” the strangling process runs backward—the host tree keeps getting bigger instead of shrinking. New functionality should go into the new system, even before the migration is finished.

Ignoring shared data: If both systems read and write the same database, you need a clear answer for who owns which tables during the transition. Splitting data ownership badly is one of the most common ways these migrations stall out.

Treating the façade as free: A router or reverse proxy adds latency and becomes a dependency every request goes through. Monitor it like any other production service—it can become a bottleneck or a single point of failure if it’s an afterthought.

When to Use It

Reach for Strangler Fig when:

The legacy system is large, business-critical, and can’t be frozen for the duration of a full rewrite.
You can intercept requests to the legacy system (you have access to its source, its network boundary, or both).
You’re comfortable running two systems in parallel for an extended period.

It’s probably not worth it when:

The system is small enough that a full rewrite is genuinely low-risk.
You can’t intercept traffic to the legacy system at all (no source access, no proxy point).
Leadership needs the legacy system fully decommissioned on a short timeline that doesn’t allow for incremental validation.

Practical Guidelines

Wrap the legacy system behind an interface immediately. It makes the router testable and gives you a clean seam to delete later.
Migrate in small, independently shippable slices. Pick a single capability, migrate it, validate it in production, then move to the next one.
Make the routing decision reversible. A flag, a percentage rollout, or a config value—whatever it is, be able to flip it back without a deployment.
Plan for the façade’s removal from day one. It’s a means to an end, not permanent infrastructure.
Watch for shared state. Decide early who owns which data while both systems are live, and keep that ownership boundary explicit.
Treat the migration as a project with an end date, not an open-ended architectural aspiration. Strangler Fig works because it’s incremental and visible—not because it’s slow for its own sake.

Strangler Fig Pattern | Alan P. Barber