Strangler Pattern

An incremental software migration strategy that builds a new system around — and gradually alongside — a legacy system, routing traffic component by component to the new system until the legacy can be decommissioned entirely. Named after the Queensland strangler fig tree, which germinates in the upper branches of a host tree, works its way down, and eventually envelops and replaces the host. In ecommerce, it is the dominant alternative to a "big bang" re-platforming cutover, and the primary technical approach for migrating monolithic commerce platforms to Composable Commerce / MACH|composable or Headless Commerce|headless architecture.

---

Origin

The term was coined by Martin Fowler after observing Queensland strangler figs during a trip to Australia. The original article — "Strangler Fig Application" — was published on martinfowler.com approximately 2004 and updated on 22 August 2024. Fowler renamed the pattern from "Strangler Application" to "Strangler Fig Application" to emphasise the botanical (non-violent) metaphor. (Source: Martin Fowler, martinfowler.com/bliki/StranglerFigApplication.html, updated 2024-08-22)

Fowler's 2024 update incorporates the "Patterns of Legacy Displacement" framework (Cartwright, Horn, Lewis), which expands the pattern into four high-level activities:

1. Understand the outcomes you want to achieve
2. Decide how to break the problem up into smaller parts
3. Successfully deliver the parts
4. Change the organisation to allow this to happen on an ongoing basis

The fourth activity is explicitly non-technical: "If there's no change in organizational culture and leadership, the new systems will end up in a similar mess." (Source: Martin Fowler, 2024-08-22)

---

How It Works in Ecommerce

The pattern operates through a routing facade — an API gateway, CDN-level proxy, or middleware layer — that intercepts all traffic and forwards it to either the legacy system or the new replacement service, depending on which component has been migrated. End-users see no seam. (Source: commercetools blog, 2025-04-03; Conn's HomePlus / MACH Alliance, 2023-01-27; Agile Commerce, 2026-07-24)

Standard migration loop

1. Find a seam — identify a bounded domain in the legacy system (e.g. promotions engine, product catalog, checkout) where behaviour can be isolated. "In a well-designed system, these seams would already exist. But such systems are unicorns." (Fowler, 2024)
2. Introduce the routing facade — deploy an API gateway or CDN layer in front of both systems. Initially all traffic passes through to legacy (transparent proxy).
3. Build new service — develop the replacement component alongside the legacy, independently deployable with its own data store and CI/CD pipeline.
4. Canary routing — route a small traffic percentage (e.g. 5–10%) to the new service. Use Feature Flags and user-segment stickiness to prevent split-session errors.
5. Reconcile — run automated comparison of outputs from both systems. Define kill criteria (e.g. four consecutive weeks of zero mismatches) before decommission.
6. Decommission — once kill criteria are met, retire the legacy component.
7. Iterate — pick the next seam and repeat.

(Sources: Thoughtworks, 2023-10-25; 4Geeks, 2025-12 / 2026-06; Conn's HomePlus / MACH Alliance, 2023-01-27; Software Modernization Intelligence, 2026-02-15)

Routing implementations in ecommerce

• API gateway (Kong, AWS API Gateway) — routes at the service/endpoint level. Standard for backend component extraction. (Source: Agile Commerce, 2026-08-10; 4Geeks, 2025-12)
• CDN-level routing (Akamai Audience Segmentation Cloudlet) — routes entire page-type or user-segment traffic at the edge; preferred over A/B test tools to avoid page-refresh redirect issues on slow connections. Used by Conn's HomePlus. (Source: Conn's HomePlus / MACH Alliance, 2023-01-27)
• Edge Middleware (Vercel) — used to proxy traffic from Salesforce Commerce Cloud to a new Next.js frontend; the SFCC backend is preserved while the rendering layer is strangled. (Source: Vercel case study, 2025-01)
• Frontend-as-facade (PWA headless layer) — headless frontend (e.g. Alokai) sits in front of legacy, pulls data from both old and new APIs, and routes rendering incrementally. Enables immediate UX improvements while backend migration proceeds separately. (Source: Alokai blog, 2024-06 / 2026-01)
• NGINX passthrough — lower-cost reverse proxy implementation for simpler systems; automatic fallback to legacy if new service fails is architecturally non-negotiable for high-availability migration. (Source: 4Geeks, 2025-12)

---

Ecommerce-Specific Starting Points

commercetools (2025-04-03) identifies five possible entry points for a strangler migration:

1. Product catalog / PIM — lowest risk, high data volume, isolated domain
2. Buying journeys or customer groups — useful for driving conversion improvement early
3. Pilot project / MVP — new geography, new brand, or acquisition (limits blast radius)
4. Frontend-first / front-to-back — recommended for SAP Spartacus users; decouples storefront without touching transactional core
5. Checkout first — highest ROI but highest complexity; recommended for B2B with complex pricing

(Source: commercetools blog, 2025-04-03)

---

Case Studies

Conn's HomePlus — Magento → BigCommerce (as-of 2023-01-27)

$1.5B retailer, 160+ stores. Migration from Magento 2.4.3 (AWS) to BigCommerce SaaS. Stack additions: Klevu search, Cloudinary DAM, Signifyd fraud. CDN: Akamai.

• Decomposed by waves (function) and traffic throttle (% of users): Wave 1 = homepage + PLP browse (high traffic, low transaction complexity); Wave 2 = PDP + cart + checkout + My Account
• Used Akamai Audience Segmentation Cloudlet to route traffic by segment (random, state, device, or custom parameter)
• Maintained identical URL structure on both platforms to preserve SEO; all search bots directed to old platform during migration
• ~1,000 automated test cases run on every change; FullStory and QuantumMetrics for session replay
• Timeline: MVP (homepage) in 3 months; full migration complete in ~9 months total
• Outcome: "modest increase in conversion and revenue-per-visitor metrics during and post-migration" (no specific % disclosed)

(Source: Prasad Tangirala, VP eCommerce Engineering, Conn's HomePlus; MACH Alliance / machalliance.org, 2023-01-27)

Unnamed global sportswear brand — SFCC → Next.js on Vercel (as-of 2025-01)

Used Vercel Edge Middleware as the strangler routing proxy in front of Salesforce Commerce Cloud.

• LCP: 4.0s → 2.4s (−40%) (as-of 2025-01)
• TTFB: 2.0s → 0.8s (−60%) (as-of 2025-01)
• Cart abandonment: −28% (as-of 2025-01)
• Mobile conversion: +15% (as-of 2025-01)
• Incremental quarterly revenue: +$10M (as-of 2025-01)
• New architecture 10× faster than SFCC alone in load testing
• Migration timeline compressed from 5 months to 2 months after homepage pilot proved results
• Zero downtime during Black Friday with 125k+ concurrent users

(Source: Vercel case study / Netguru legacy modernization guide citing Vercel, 2025-01)

[!unverified] Brand identity not disclosed. Stats cited from Vercel case study via secondary source (Netguru, 2026-07). Vercel is a vendor; case study metrics are not independently verified.

Moonpig (UK) — Homegrown monolith → composable (as-of 2025-04)

UK greeting cards and gifts retailer. Broke down homegrown monolith into composable components using strangler pattern. Stack: commercetools (B2C), Adyen (payments), Contentful (CMS). Approach: identify in-house differentiators vs. best-of-breed commodities, build/buy accordingly. (Source: commercetools blog, 2025-04-03, referencing commercetools customer story page)

Unnamed multi-billion-dollar retailer — Promotions engine (as-of 2025-04)

Migrated legacy promotions engine first, using strangler pattern. New API-driven promotions engine delivered in under 4 months with zero downtime. Cart, checkout, and account modules then implemented in parallel on separate development tracks. (Source: Broadleaf Commerce blog, Brad Buhl, 2025-04-22)

PLUS Supermarkets (Netherlands) — Big-bang counter-example (as-of 2025-04)

Chose big-bang migration, not strangler. Scope expanded to rethink all customer journeys. Go-live executed in a 24-hour window. Total timeline: 3 years. (Source: commercetools blog, 2025-04-03)

SoundCloud — 8-year migration (non-ecommerce reference, as-of 2022-05)

Rails monolith → Backend-For-Frontend (BFF) architecture. Duration: 8 years (2014–2022). The migration was "motivated by immediate need rather than planning for a future free of the public API monolith." After initial adoption, both the strangler and the original monolith were "left largely unmaintained" — a prolonged fallow period during which code duplication, inconsistent API behaviours, and security risks accumulated. The final migration phase required adding telemetry to discover which endpoints were still live. Shadow-testing was used: incoming requests executed both code paths simultaneously, responses compared. (Source: InfoQ / SoundCloud Engineering Blog, 2022-05)

---

Data and Benchmarks

• Strangler success rate: 76% (22/29 projects) vs big-bang success rate: 50% (6/12 projects) (as-of 2026-02-15)
• Stall rate: 68% of strangler projects stalled before 90 days, never replacing their first monolith component (as-of 2026-02-15)
• Early velocity predictor: projects extracting less than 5% of monolith functionality in first 90 days had a 92% failure rate (as-of 2026-02-15)
• Median successful strangler timeline: 16.2 months; median cost: $1.8M (as-of 2026-02-15)
• Median failed project sunk cost: $2.1M (as-of 2026-02-15)
• Average enterprise replatforming cost: $2–5M (Forrester, cited by Getfastr, 2026-06) — does not include opportunity cost of 12–18 months roadmap deprioritisation

---

Anti-Patterns and Failure Modes

Analysis of 28 failed/stalled strangler projects (Software Modernization Intelligence, 2026-02-15):

Anti-pattern 1 — UI-first without owning backend logic (39% of failures) New React/frontend admin panel built, but it made 47 API calls to legacy monolith per page load. $680K sunk before abandonment. "UI is the tip of the iceberg. Strangling a UI without owning backend logic creates a distributed frontend — worst of both worlds." Median time to stall: 68 days.

Anti-pattern 2 — No stable semantic boundary / scope creep (32% of failures) A "Customer Service" extraction expanded by week 8 to depend on six domains (Orders, Fulfillment, Returns, etc.); project reset. Median time to stall: 72 days.

Anti-pattern 3 — Dual-write without automated reconciliation (18% of failures) Dual-write without reconciliation: 12% success rate, 38 incidents/month. Automated reconciliation: 87% success rate, 0.4 incidents/month. "Shared databases and translation adapters are acceptable migration tools, but they're not the destination. If they become permanent, you've built a permanent diplomatic border between two systems that dislike each other." (Software Modernization Intelligence, 2026-02-15)

Anti-pattern 4 — Microservice proliferation Broadleaf Commerce (2025-04-22) explicitly warns against conflating strangler pattern with wholesale migration to hundreds of microservices: "The proliferation of microservices comes with its own operational cost. Modular with orchestration is what makes real-world composability achievable."

Anti-pattern 5 — Fallow period The strangler works well enough initially to deprioritise completion. The legacy was supposed to be temporary; it becomes permanent. SoundCloud maintained two systems for 8 years. Getfastr (2026-06) describes "consistent enough to be structural, not anecdotal" disillusionment at 12 months post-headless launch. Leadership abandonment is the most cited failure mode in practitioner sources.

Anti-pattern 6 — Preserving a bad data model Classic strangler pattern requires maintaining existing API contracts throughout — you change the technology but not the data structures or behaviours. "If you have data model debt, strangler pattern will preserve it, not fix it." (McComb / Dataversity, 2026-06)

---

Prerequisites (9 Non-Negotiables)

From comparison of 13 successful vs 28 failed strangler projects (Software Modernization Intelligence, 2026-02-15):

Prerequisite	% of successes	% of failures
Comprehensive test coverage for legacy	100%	18%
Stable semantic boundary (DDD)	100%	25%
Data ownership plan documented	100%	21%
Interception point identified	100%	32%
Stakeholder buy-in for dual operations	92%	11%
Single accountable owner	92%	14%
Reconciliation strategy designed	92%	4%
Robust monitoring already in place	85%	7%
Kill-switch / instant rollback defined	85%	11%

Projects missing more than 2 prerequisites: 94% failure rate (as-of 2026-02-15).

Additional prerequisites from Netguru (2026-07) and 4Geeks (2026-06):

• Feature flag infrastructure (required for canary releases, not optional)
• Blue-green deployment (handles infrastructure-level switchover alongside feature-flag routing)
• Rollback trigger criteria defined pre-launch (e.g. error rate threshold, p95 latency spike, add-to-cart conversion drop vs baseline)
• Change Data Capture (CDC) via tools like Debezium + Kafka for database synchronisation during transition — the most underestimated step

---

Data Synchronisation (The Hardest Problem)

Every technical source names the shared database as the primary implementation challenge. The sequence required (4Geeks, 2026-06; Thoughtworks, 2023-10-25):

1. Deploy routing facade (passthrough initially)
2. Build new service alongside legacy
3. Implement Change Data Capture (CDC) to stream row-level changes from legacy DB to new service's DB — gives eventual consistency without modifying the monolith's write path
4. Separate databases fully once CDC is stable
5. Decommission legacy component

Most teams plan steps 1 and 5; they underestimate 2–4. "When you move the application logic to a new service, you often cannot immediately migrate the database due to foreign key constraints and shared data usage in the monolith." (4Geeks, 2025-12 / 2026-06)

---

What Practitioners Report

Counter-narrative — performance regression risk: "I've watched brands spend $3M on a headless migration and see page load time go from 2.1s to 3.8s on mobile post-launch." Cause: "five or six API calls on every page load, client-side rendering as default, unoptimised third-party scripts." Headless frontend performance requires SSR optimisation, edge caching, and bundle management expertise that most ecommerce teams don't have. (Getfastr, John Murdock, 2022 / updated 2026-06)

[!unverified] Getfastr is a DXP vendor with commercial interest in positioning headless migration as high-risk. The LCP regression figure is attributed to an unnamed brand and not independently verified. The structural critique (client-side rendering defaults, API overhead) is consistent with Core Web Vitals literature.

Counter-narrative — SEO risk underweighted: Replatforms that skip redirect mapping "routinely lose 20–50% of organic traffic in the months after cutover." Requires full crawl of legacy URL inventory, deliberate 410 responses for dead URLs, and post-launch crawl budget monitoring. (Netguru, 2026-07)

[!unverified] "20–50%" figure is from a single source without citation to primary data.

Practitioner consensus on management commitment: Management commitment is the most cited non-technical failure factor. "Successful projects suggest remaining consistent and ensuring your management team commits to the long-term project." (Fabric / dev.to, James Konik, 2021) Getfastr (2026-06): "I've watched talented commerce leaders leave companies mid-migration because the project consumed everything."

---

Key Terms

Term	Meaning
Strangler facade	The routing layer (API gateway, CDN proxy, edge middleware) that intercepts traffic and directs it to old or new system
Seam	A boundary in the legacy system where behaviour can be isolated and extracted independently
Thin slice	A small, self-contained, independently deliverable piece of functionality — the unit of a strangler migration
Canary routing	Sending a small traffic percentage (e.g. 5–10%) to the new service before full cutover
Reconciliation loop	Automated comparison of outputs from old and new systems running in parallel; used to define kill criteria
Kill criteria	Pre-defined conditions (e.g. zero mismatches for 4 consecutive weeks) that trigger legacy decommission
Fallow period	The gap between initial strangler adoption and eventual completion — highest risk for permanent hybrid state
Branch by Abstraction	Alternative to routing-facade strangler: old and new implementations coexist behind one abstraction layer inside the codebase
Change Data Capture (CDC)	Technology (e.g. Debezium + Kafka) used to stream database changes from legacy to new service during transition
Domain-Driven Design (DDD)	Design approach used to define the semantic boundaries (bounded contexts) that make a strangler migration possible

---

Related Concepts

• MACH Architecture — strangler pattern is the primary adoption path for MACH; see Composable Commerce / MACH
• Composable Regret — what happens when strangler migrations stall or over-engineer
• Pragmatic Composability — VTEX's alternative framing; argues for selective composability rather than full decomposition
• Packaged Business Capabilities (PBCs) — the unit of composable architecture that strangler migrations typically extract
• Headless Commerce — often the immediate output of a strangler frontend extraction
• Feature Flags — prerequisite infrastructure for canary routing in strangler migrations
• Digital Experience Platform (DXP) — some vendors (Magnolia, Emporix) position their DXP as a permanent "facade" layer rather than a migration vehicle