Strangler Fig Pattern: Modernizing Monoliths Without the Big Bang

The strangler fig is a tropical tree that grows around a host tree, gradually replacing it. The host tree continues to function while the fig grows. Eventually, the fig has replaced the host entirely, and the original tree can be removed. No dramatic felling. No moment of crisis. Just a gradual, continuous transition from old to new.

Martin Fowler named the software modernization pattern after this tree for exactly this reason. The strangler fig pattern replaces a monolithic application incrementally, one capability at a time, without requiring a big bang rewrite that disrupts the business, consumes the engineering team, and fails 70% of the time.

Why Big Bang Rewrites Fail

The big bang rewrite is the most intuitive approach to modernization and the most dangerous. The plan sounds simple: build the new system, migrate the data, cut over, and retire the old system. The reality is that the rewrite takes twice as long as estimated (because the team discovers business logic embedded in the monolith that nobody documented), costs three times the budget (because scope creeps as edge cases emerge), delivers no business value until it is complete (the new system is not production-ready until everything is rebuilt), and carries enormous risk at cutover (a single failure can revert the entire migration).

"The strangler fig pattern eliminates these risks by delivering value incrementally, maintaining the existing system throughout, and allowing the organization to stop, adjust, or reverse direction at any point."

- Martin Fowler, Author, and Software Consultant

How the Pattern Works

1. Intercept. Place a routing layer (an API gateway, reverse proxy, or service mesh) in front of the monolith. All traffic flows through this layer. Initially, 100% of requests are routed to the monolith. Nothing changes for users.
2. Extract. Identify the first capability to extract from the monolith. Build it as a new, independent service. The new service handles its own data, has its own deployment pipeline, and can be developed and deployed independently.
3. Redirect. Update the routing layer to send requests for that capability to the new service instead of the monolith. The monolith continues to handle everything else. Users experience no disruption; the routing is transparent.
4. Repeat. Extract the next capability, build, redirect. Each extraction reduces the monolith's scope and increases the new architecture's coverage. Over months or years, the monolith shrinks from "the application" to "a few legacy functions" to "nothing."

Choosing What to Extract First

Not all capabilities are equally good candidates for extraction. The ideal first extraction has these characteristics: it is well-bounded (clear inputs and outputs, limited dependencies on other parts of the monolith), it is high-value (extracting it delivers measurable business value, creating momentum and executive support for the program), it is well-understood (the business logic is documented or at least understood by the current team), and it has clean data boundaries (the data it needs can be separated from the monolith's database without creating complex synchronization requirements).

Capability	Characteristics
Authentication and Authorization	Well-bounded, broadly impactful
Search	High-value, clean interface
Notifications	Loosely coupled, event-driven
Reporting/Analytics	Read-only, can operate on a replicated dataset

Managing the Transition Period

The hardest part of the strangler fig pattern is not the extraction itself. It is managing the period when some capabilities live in the new architecture and some live in the monolith. During this period, you must maintain data consistency (some data may need to exist in both systems temporarily), manage cross-system transactions (a business process may span both the monolith and the new services), and support two operational models (monitoring, alerting, and incident response for both architectures).

This transitional complexity is real. It is also temporary. And it is far less risky than the alternative: stopping all feature development for 18 months while a rewrite team builds a system that may never ship.

"The strangler fig pattern is not glamorous. There is no launch day, no press release, no dramatic before-and-after. There is just continuous, incremental improvement that eventually produces a fully modernized architecture without the organization ever having to bet the business on a single cutover."

- Flynaut Modernization Insights

Ready to modernize without the big bang? Talk to Flynaut about incremental modernization strategy at flynaut.com.