The Strangler Fig Pattern: Modernizing .NET Monoliths Without Downtime
Back to Insights"Big bang" rewrites fail most of the time. They're expensive, risky, and pause business features for months. The Strangler Fig pattern offers a safer route: replacing the system piece by piece while it keeps running.
What Is the Strangler Fig Pattern?
Named after a tree that grows around a host tree and eventually replaces it, this pattern places an API gateway (Azure APIM, AWS API Gateway) in front of your legacy .NET Framework app.
The Process
- Intercept: route all traffic through the gateway. Initially, 100% of traffic still goes to the legacy app — nothing changes for users yet.
- Isolate: identify one module — say, "user profile" — with a clear boundary and low fan-out to the rest of the monolith. The best first candidate is rarely the most important module; it's the most self-contained one.
- Rewrite: build a new microservice, on the current .NET LTS release, for just that module. Its data access should own its own tables where possible, not reach back into the legacy schema.
- Route: update the gateway to send that module's traffic to the new service, while everything else still goes to legacy. Keep a fast rollback path — flip the route back if the new service misbehaves under real load.
- Repeat: continue until legacy handles 0% of traffic, then decommission it. This is usually a multi-quarter effort, not a single sprint.
Key Insight
This decouples modernization from business logic. You can ship new features in the new stack from day one, instead of waiting for the rewrite to finish.
Where This Pattern Doesn't Fit
The strangler fig pattern assumes the monolith has module boundaries worth extracting along. If the codebase is one tightly coupled ball of shared state — global variables, a single God object touched by every feature — there may be nothing clean to isolate yet, and the honest first step is a smaller internal refactor to create seams, not a gateway. It also assumes the business can tolerate running two systems side by side for months; if the legacy system is already failing under load or unsupported, a faster, more disruptive migration may be the safer call despite the downtime risk.