Strangler Fig Pattern for Legacy Commerce Platforms: A Practical Roadmap

Most commerce platform migrations fail in the same way. An engineering team identifies genuine problems with their legacy platform — Magento is slow to deploy, WooCommerce cannot handle their product catalogue complexity, a custom monolith has become unmaintainable — and decides to migrate to a composable architecture. They plan a phased migration. Phase one takes longer than expected. Phase two gets deprioritised when the roadmap fills up. By phase three, the business has lost patience with the migration that has consumed engineering capacity for eighteen months without visible progress. The project is cancelled, and the legacy platform continues for another three years.

The strangler fig pattern exists to prevent this outcome. Named after the fig tree that grows around an existing tree, gradually replacing it while the host continues to function, the pattern describes an incremental migration approach where individual capabilities are extracted from the legacy platform one at a time, replaced with purpose-built services, and the legacy platform is retired progressively rather than all at once. The platform continues functioning throughout. Revenue is never at risk. Each extraction delivers independent business value rather than being a step on a long road to a future state that may never arrive.

This post is a practical roadmap for applying the strangler fig pattern to a legacy commerce platform migration, with specific guidance on which capabilities to extract first, how an orchestration BFF enables the incremental approach, and the failure modes to actively avoid.

Why Commerce Monoliths Are Particularly Hard to Migrate

Commerce platforms accumulate coupling in a way that most other applications do not. A Magento or WooCommerce installation developed over five years typically has: custom modules that depend on each other in undocumented ways, pricing and tax logic that is spread across multiple extension points and cannot be understood without tracing through a dozen method calls, a product data model that has been extended with custom attributes to the point where the core schema is unrecognisable, and a checkout flow that has been customised for specific business rules so many times that no single engineer understands the full path a cart takes from "add to cart" to "order placed."

This coupling means that extracting one capability in isolation is genuinely difficult. The pricing logic calls the tax logic. The tax logic reads the customer record. The customer record affects shipping eligibility. Pulling on any single thread risks unravelling the whole system. This is the central challenge that the strangler fig pattern addresses: not just decomposing the system, but doing so incrementally without breaking the existing system while the decomposition is in progress.

The other complicating factor is data. Commerce monoliths typically have years of order history, customer data, product data, and configuration in a single database that is tightly coupled to the application. The migration is not just a code migration — it is a data migration, and data migrations in live commerce systems carry significant risk. The strangler fig pattern handles this by deferring the data migration to the last possible moment: the new service runs alongside the monolith, with the monolith's database as the source of truth, until the extraction is complete and validated. Only then does the data ownership transfer.

The Orchestration BFF as the Migration Enabler

The strangler fig pattern requires a routing layer that can direct traffic to either the legacy system or the new service for any given capability. In a commerce migration, this routing layer is the orchestration BFF. It sits in front of both the legacy platform and the new composable services, and it decides — for each request — which system is authoritative for each piece of data.

This is the architectural insight that makes the migration tractable. Before the BFF is introduced, every client (storefront, mobile app, partner API) calls the monolith directly. After the BFF is introduced, every client calls the BFF, which proxies to the monolith. At this point, the system behaviour is identical to before — the BFF is a transparent proxy. But now the BFF is in position to intercept individual requests and route them to new services as each capability is extracted.

The storefront never changes during the migration. It calls the same BFF endpoints throughout. The BFF's routing logic is the only thing that changes as each capability migrates. This decoupling between the client-facing API surface and the underlying system architecture is what allows the migration to proceed incrementally without disrupting the storefront development team's work.

The BFF also handles the parallel running period — the time between when a new service is deployed and when the legacy capability is disabled. During this period, the BFF can call both systems, compare the responses, log discrepancies, and only switch traffic to the new service once the responses are consistently equivalent. This shadow mode operation is essential for high-risk capabilities like checkout and payment, where a discrepancy between the legacy and new system means a lost or incorrect order.

Choosing What to Extract First

The order of extraction matters enormously. The criteria for a good first extraction are: high business value, low coupling to other capabilities, clear and bounded inputs and outputs, and easy reversibility if the extraction fails. Tax calculation meets all four criteria almost perfectly, which is why it appears as phase two in nearly every successful commerce strangler fig migration.

Tax calculation has a bounded interface: you send it a cart with line items, a shipping address, and a customer identifier, and it returns tax amounts per line and in total. The inputs and outputs are well-defined by tax service APIs like Avalara and Vertex. The monolith's tax calculation is typically a self-contained module — it does not write to shared tables or trigger side effects. Rolling back is straightforward: re-route the BFF to the monolith's tax calculation. And the business value is immediate: a purpose-built tax service handles multi-jurisdiction complexity, marketplace facilitator rules, and exemption certificates that most legacy platforms handle poorly.

Product catalogue is a good second extraction. The catalogue is read-heavy, making it easier to migrate than write-heavy systems. A new catalogue service can be populated from the legacy database and kept in sync via event streaming or periodic sync while the migration is in progress. The storefront continues reading from the monolith's catalogue (via the BFF) until the new catalogue is verified as complete and consistent, then the BFF switches the routing.

Capabilities to extract last are those that are deeply coupled to the monolith's transactional state: order management, payment processing, and the checkout flow itself. These should not be extracted until confidence in the BFF layer is high and the earlier extractions have been in production without incident for several months. The risk of extracting these capabilities incorrectly is directly proportional to the revenue they handle.

The Migration Roadmap: Phase by Phase

The following roadmap is a realistic timeline for a mid-size commerce platform (£5M–£50M revenue, 50k–500k SKUs, 3–5 engineers on the migration). Adjust the durations based on your platform's specific coupling complexity — Magento with heavy customisation takes longer than a newer custom monolith. The phases are deliberately conservative: it is better to take eight weeks on a phase and validate it thoroughly than to rush and introduce a regression in production.

Notice that phases 1 and 2 together take only eight weeks and the business is already running a purpose-built tax service. This is the strangler fig pattern working correctly: early phases deliver business value independently, so the migration project is not a pure cost centre waiting for a future payoff.

Handling Data Ownership During the Migration

Every capability extraction has a data question: while the new service is being built and validated, which system is the source of truth for that data? The answer must be the legacy system until the extraction is complete. Dual-writing to both systems during the migration — updating the legacy database and the new service's database simultaneously — creates a consistency problem that is harder to resolve than the original migration.

The practical pattern is: build the new service to read from the legacy database initially. The new service does not have its own database yet — it queries the monolith's database through a read-only connection or a data access layer that abstracts the legacy schema. This approach means the new service is working with the same data as the legacy platform, making comparison validation simple: the BFF can call both the legacy capability and the new service with the same input and compare the outputs directly.

Once the new service's outputs are consistent with the legacy system for a defined validation period (typically two to four weeks of shadow mode in production), the BFF switches routing to the new service and the new service migrates to its own database. The legacy tables become read-only, then are archived. This "strangler fig" data migration approach removes the risk of data inconsistency by keeping a single authoritative source until the last possible moment.

Shadow Mode: Running Both Systems in Parallel

Shadow mode is the period during which the BFF calls both the legacy capability and the new service for every request, compares the results, and routes the live response from the legacy system while logging any discrepancies from the new service. The client receives the legacy response; the new service's response is discarded. This lets you validate the new service against real production traffic without any risk to the customer experience.

Shadow mode reveals the categories of discrepancy that integration testing always misses: edge cases in the data that only appear in real customer sessions, timing-dependent behaviours, and data that was migrated with subtle differences from the source. For tax calculation, shadow mode typically reveals that the new service handles a specific customer exemption category differently. For pricing, it might reveal that a promotional rule applies to a specific product bundle in a way the new service did not replicate. These discrepancies are caught safely in shadow mode rather than catastrophically in live production.

The BFF's execution logs are the shadow mode tooling. Every request in shadow mode generates a log entry with the legacy response, the new service response, and a diff of any differences. The migration team monitors these logs daily during the shadow period, investigates discrepancies, and updates the new service until the discrepancy rate reaches zero (or an acceptable threshold for genuinely acceptable differences, such as rounding in currency conversion).

The Five Failure Modes to Actively Avoid

Most commerce strangler fig migrations that fail do so for one of five reasons. Understanding these in advance is more valuable than any roadmap.

Skipping the BFF introduction. Some teams try to extract services directly from the monolith without introducing an orchestration layer first, routing traffic at the DNS or load balancer level instead. This approach requires client-side changes for every extraction, couples the migration timeline to the storefront team's deployment schedule, and makes rollback harder. The BFF introduction is not optional — it is the mechanism that makes everything else possible.

Extracting checkout too early. Checkout is the most coupled capability in any commerce monolith. Extracting it in the first few phases — before the team has built confidence in the BFF layer and the new service deployment patterns — is the most common cause of migration failure. The revenue impact of a checkout bug is immediate and visible. Defer checkout extraction until phases 1 through 4 have been in production without incident.

Big-bang data migration. Migrating all product data, customer data, and order history to new databases on a single cutover weekend is a high-risk operation that many teams underestimate. The strangler fig approach defers data migration by having new services read from the legacy database initially. Teams that cannot resist the temptation to "do the data migration properly" up front often delay the extraction by months while the data migration is debugged, and the migration project loses momentum.

Losing shadow mode discipline. Shadow mode requires monitoring discrepancies daily, investigating every one, and not switching live traffic until the discrepancy rate is satisfactory. Teams that run shadow mode for a week, see "mostly similar" results, and switch traffic early inevitably discover the discrepancy they missed when a real customer hits the edge case. Shadow mode is not a checkbox — it is a validation process that takes as long as it takes.

Treating the migration as a technology project rather than a business project. Migrations that are funded as engineering initiatives without visible business milestones get cancelled when the business faces pressure. Frame each extraction as a business outcome: "we moved to a purpose-built tax service, which gives us accurate multi-jurisdiction tax calculation and removes our dependency on the legacy platform for tax compliance." This framing keeps the business invested in the migration even when the immediate customer-facing change is invisible.

When the Strangler Fig Becomes the New Platform

The endpoint of a successful strangler fig migration is not a single cutover event — it is a gradual realisation that the legacy platform is no longer handling any meaningful traffic. At some point in the migration, the BFF is routing all product requests to the new catalogue service, all tax requests to the new tax service, all pricing requests to the new pricing engine, and the only remaining monolith traffic is for capabilities not yet extracted. At that point the legacy platform is already a legacy system in the true sense: it handles a small fraction of the original traffic and can be retired on a schedule that suits the business.

The final retirement of the legacy platform is straightforward compared to the earlier extraction phases, precisely because the BFF has absorbed all the routing complexity. Removing the last monolith route from the BFF is a configuration change, not a migration project. The strangler fig pattern has done its work: the new tree has grown around the old one, and the old one can be removed safely.

The orchestration BFF that enabled the migration does not go away when the migration is complete. It becomes the permanent orchestration layer for the composable platform: the component that fans out to multiple composable services in parallel, composes responses for each client channel, handles caching and failure policies, and provides the unified observability that a multi-service composable platform requires. The investment in the BFF layer pays off both during the migration and indefinitely after it.