Skip to main content
Contact

The strangler pattern on a live product, and where it stops

The strangler pattern replaces a live system one piece at a time, so the old one keeps working until nothing depends on it. Martin Fowler described it in 2004, after the strangler fig, a vine that grows around a host tree until it stands on its own. Many write-ups call it the strangler fig pattern.

Teams reach for it when a product people pay for has outgrown its code, and a legacy system cannot simply be switched off for a rebuild. It also has a limit. Some parts cannot move a piece at a time, and those need one switch, planned with care.

By
Pravash Karki
Published
10 November 2026
Reading time
4 min read
Share

What the strangler pattern is

  • A new system grows around the old one. Each release moves one function across incrementally: a screen, a feature, an integration.
  • A façade sends each request to the old system or the new. It sits in front of both, so requests are routed without customers seeing the join.
  • The old system shrinks. When nothing depends on it any more, it is switched off.
  • Its opposite is the big-bang rewrite. Build everything new, then switch over on one day.

Piece by piece, or one switch

Piece by pieceOne switch
FitsParts that can be split: pages, features, servicesData or a format that every part shares
RiskSpread over many small releasesGathered on one day
NeedsA way to route between old and newA full move of the data, checked, and the old system kept

A project may need both. The skill is knowing which parts are which before the work starts.

How we did it on an email builder

DynamicXX sells email templates. Its customers edit them in a drag-and-drop builder, then send them or export them to their email platform. The builder was already live: the Web Archive shows its sign-in page in 2015.

Its core had a limit. A template had to carry special tags before the builder could edit it. We took the product on in October 2018 and used a staged replacement: screens and features first, then the core.

  1. The screens customers touch, from October 2018. A brief and a seven-week timeline. We rebuilt the sign-in pages, the templates page and the editors for text, backgrounds and buttons, then template editing, copying and preview.
  2. What customers pay for, February to July 2019. Sprints, each with a report. Exports to Mailchimp and Campaign Monitor, purchase codes for paid templates, template bundles and premade modules. This went live in July 2019, on the old core.
  3. The core, October 2019 to January 2020. A new core that needs no special tags. It went live on 24 January 2020.
Three stacks of three blocks: screens, paid features and core. October 2018: all three old. July 2019: screens and paid features rebuilt, the old core still running. 24 January 2020: all three rebuilt, the core in one switch, with the old builder kept on its server until November 2020.
The DynamicXX builder at each stage, from the project's task lists.

Where the pattern stopped

The core held every customer's templates, and every screen read them. We moved that part in one switch. Everything came across from the old builder, server to server, so customers opened the same templates in the new one.

The old builder stayed on its server until November 2020, nearly ten months after the switch.

The year before the switch is what made one switch reasonable. By then we knew which features earned money and which screens customers used every day. A first week cannot give a team that knowledge.

Three questions buyers ask about it

  • Does it need microservices? No. Most write-ups show a monolith broken into microservices, but the order works for any architecture. The new DynamicXX builder was still one Laravel application.
  • How is the data migrated? The pattern says least about this. Decide from the dependencies. DynamicXX used one checked migration; other systems may move data in stages.
  • How long does it take? As long as the parts take. On DynamicXX it was 15 months from the first rebuilt screen to the new core.

After the switch

We stayed on until July 2021: fixes to the editors, exports and test sends, and new modules. In all, the two projects hold more than 230 tasks across nearly three years. Support after the switch ran for 18 months.

Five questions before you replace a live core

  1. Which parts can move one at a time? Screens and features usually can.
  2. Which part has to move in one switch? Check shared data and formats before deciding.
  3. Do you know what the core carries? List the features that earn money and the screens customers use daily.
  4. How does every customer's work come across? Decide who checks it, and how, before the day.
  5. How long does the old one stay? Agree a rollback period and what must be verified before retiring it.

If you are still deciding whether to rebuild at all, refactor or rewrite a running website covers that choice. Our product engineering page covers the work we do on products already in use.

The strangler pattern is usually told as a way to avoid one big switch. On a live product, its better use is to earn the switch you cannot avoid.

Related work

The builder editing a template named Gravity: a menu of modules, premade modules, preview, export and send on the left, the template in the middle, and rename, undo, redo and reset at the top.

DynamicXX

A drag-and-drop email template builder, rebuilt in stages and later rewritten while customers continued using the product. The work ran from 2018 to 2021.

Public story

Has your product outgrown its code while customers still use it?

Tell us what it does and what it runs on. We will say which parts can move one at a time, and which will need one switch.

Talk to us about your product