Strangler pattern

The strangler pattern, named after the strangler fig that grows around a host tree, is a way to modernize a system without a big-bang cutover. You place a facade or routing layer in front of the legacy application. At first every request passes straight through. Then, one capability at a time, you build a replacement service, point the facade at it, and retire the corresponding legacy code. Users never see a switch; they see the same URL, screen or API.

The routing layer is the key piece. It may be an API gateway, a reverse proxy, a feature flag inside the application, or a database-level trigger that mirrors writes. Choosing which capability to strangle first matters: pick something with a clear boundary, moderate risk and visible value, such as reporting or notifications, rather than the core ledger.

It is not a rewrite in disguise. If you build the new system in full before routing any traffic, you have simply added a facade to a rewrite. The pattern only reduces risk if each slice goes live independently and the old code for that slice is actually removed.

• CTO / Head of Engineering: it lets the team ship modernized slices every few weeks instead of betting everything on a single cutover date.
• Product manager: new features can be built in the new stack immediately, rather than waiting for the migration to finish.
• CFO: spend is spread and each phase has a visible deliverable, which is easier to approve than a year-long rewrite with nothing to show until the end.
• Operations head: business processes keep running; if a new slice misbehaves, routing flips back to the old code in minutes.

Big-bang replacements of business systems fail often enough that the industry needed a safer alternative. The problem is hidden scope: legacy systems encode years of exceptions that nobody documented, and a full rewrite only discovers them at cutover. The strangler pattern exists so that discovery happens one slice at a time, with a rollback path. The trade-off is that you run two systems in parallel for months, need a routing layer you trust, and must be strict about which system owns each piece of data, or you end up maintaining both forever.

• Moving a lender's loan-origination screens to a new web app one workflow at a time while the legacy core still books the loans.
• Extracting order management from a retailer's monolith into a service that the storefront and WhatsApp channel both call.
• Replacing the reporting module of a hospital information system with a new analytics service before touching clinical modules.
• Retiring a university ERP's fee-collection module first, because it has the clearest boundary and the most visible pain.
• Introducing an AI document-processing service behind the same endpoint the old manual data-entry screen used.

Technique / practiceAn architectural pattern engineers apply, not a tool you buy. It is the backbone of Eazyware's Legacy-to-AI Modernization work, combined with characterisation tests and an API layer over the monolith.

Eazyware service that covers it: Legacy-to-AI Modernization Program. Starting prices are on the pricing page.