The Strangler Fig Pattern: Modernising Without a Rewrite

The strangler fig pattern replaces a legacy system gradually, not in one rewrite that has to work all at once. A facade, one point that receives every request, decides whether the old system or a newly built slice answers it. A slice is one piece of the system, rebuilt and moved across on its own. A record of how the old system behaves now decides when each slice is ready.

The software author Martin Fowler named the approach after a fig he saw on a 2001 trip to Queensland’s rainforests. It germinates in a host tree’s canopy, sends roots down around the trunk, and in time stands in the tree’s place. He first called it “strangler application” in 2004, and in 2019 renamed it “strangler fig application” to keep the plant in the name.

Martin Fowler, “Strangler Fig”, on the name and the metaphor. martinfowler.com. Martin Fowler, “Original Strangler Fig Application”, for the 2004 post and the 2019 rename. martinfowler.com. On the facade and the routing: Microsoft, “Strangler Fig pattern”, Azure Architecture Center. learn.microsoft.com

One facade decides which system answers

The facade is what makes this safe. Users and other systems reach it the same way throughout, so they never know which system answered. Each slice gets its own small cutover, the moment its requests switch from the old system to the new one. If the slice misbehaves, the facade sends its requests back to the old system, which is still running.

A rewrite has one cutover for everything, so if it fails, it fails all at once. Here a failure hits one slice, on one day, with a way back. It also ends: the last stage retires the legacy system, and the way back goes with it.

Tests, not confidence, decide when a slice is safe

Before any slice moves, you need a way to tell whether a change broke something. The software engineer Michael Feathers wrote a book about that problem. His definition of legacy code is code without tests: code nobody can change safely, because nothing shows when a change breaks it.

His fix is the characterization test: a test that records what the code actually does today, bugs included, not what it is supposed to do. Run the system, capture its real behaviour on the inputs that matter, and treat that record as the baseline. Any later change that keeps those tests passing has not altered what the system does on those inputs, whatever moved underneath it.

Michael Feathers, Working Effectively with Legacy Code (Pearson, 2005); definition per Wikipedia, “Legacy system” and “Characterization test”.

A rewrite started without that record is a bet that the new team correctly guessed every case the old system quietly handled. With the record, the bet becomes a check you can run.

Three techniques let the new system work beside the old one

Once the facade is routing real traffic, the new system has to work alongside the old one, and three techniques make that safer. An anti-corruption layer translates between the two systems, so the new code isn’t built around the old system’s quirks. Change data capture lets the new system read the legacy database’s changes as they happen, instead of asking it directly. And before a slice answers anyone, it runs silently on real traffic and its answers are checked against the old system’s.

For engineersThe anti-corruption layer comes from Eric Evans' domain-driven design; change data capture reads the legacy database's write log instead of querying it; and shadow traffic compares the new and old answers before the new one is trusted.

Eric Evans described the anti-corruption layer in Domain-Driven Design. Microsoft’s architecture guidance frames it, for a migration, as a facade or adapter that translates between the new system’s model and the legacy one’s, so neither has to adopt the other’s conventions. learn.microsoft.com

Microsoft’s strangler-fig guidance describes change data capture as an alternative to having the legacy database call the new service directly: read its transaction log instead, and sync the new store from that stream. learn.microsoft.com

GitHub’s engineering team built a tool for the shadow-traffic case, called Scientist: both the old and new code run on the same real request, their results are compared, and only the old result is ever returned to the caller — “from the caller’s perspective, nothing has changed.” GitHub uses it only on read operations, because a candidate that writes data alongside the control is “dangerous and incorrect”. github.blog

The third technique applies the characterization test to live requests: the old system’s real answers are the standard the new one has to match.

A clean rebuild is the right call for a system where slicing it apart would cost more than starting again. Either way, the first step is the same. Write the tests that record what the system does now, then decide whether to replace it slice by slice or all at once.

Updated 26 Sep 2026: we cut the technical-debt surveys and the AI translation section to keep to one topic, and now credit Microsoft, not Fowler, for how the facade routes requests.