The strangler fig pattern for legacy commerce platforms: a practical migration roadmap
The younifyd team
July 1, 2026 · younifyd.com
Most commerce platform migrations fail in the same way. An engineering team identifies genuine problems with the legacy platform — a Magento or WooCommerce instance too slow to deploy against, or a custom monolith that's become unmaintainable — and decides to migrate to a composable architecture. They plan a phased rollout. Phase one takes longer than expected, phase two gets deprioritized when the roadmap fills up, and by phase three the business has lost patience with a migration that's consumed engineering capacity for eighteen months without visible progress. The project gets cancelled, and the legacy platform limps on for another three years. The strangler fig pattern exists to prevent that outcome. Named after the fig tree that grows around a host tree, gradually replacing it while the host keeps functioning, it extracts individual capabilities from a legacy platform one at a time, replaces each with a purpose-built service, and retires the legacy platform progressively rather than all at once. The system keeps running throughout, revenue is never at risk, and each extraction delivers value on its own rather than being one step on a road to a future state that may never arrive. What follows is a practical roadmap: what to extract first, how an orchestration layer makes the incremental approach possible, and the failure modes worth avoiding on purpose.
Why commerce monoliths are hard to migrate
Commerce platforms accumulate coupling in a way most applications don't. A Magento or WooCommerce installation built up over five years typically has custom modules that depend on each other in undocumented ways, pricing and tax logic spread across a dozen extension points, a product data model extended with custom attributes until the core schema is unrecognizable, and a checkout flow customized so many times that no single engineer understands the full path from add-to-cart to order-placed. That coupling makes extracting any one capability in isolation genuinely hard — pricing calls tax, tax reads the customer record, the customer record affects shipping eligibility. Pulling on one thread risks unraveling the whole system, which is the actual problem the strangler fig pattern solves: not just decomposing the monolith, but doing it without breaking the system while decomposition is in progress. The other complication is data: years of order history and configuration live in a database tightly coupled to the application, so the migration is a data migration as much as a code migration. The pattern defers that risk — the new service runs alongside the monolith, with the monolith's database as the source of truth, until the extraction is validated and data ownership transfers.
The orchestration layer as the migration enabler
The strangler fig pattern needs a routing layer that can send traffic to either the legacy system or a new service, per capability, per request. In a commerce migration that routing layer is the orchestration layer, sitting in front of both the legacy platform and the new composable services and deciding, for each request, which system is authoritative. Before the layer exists, every client — storefront, mobile app, partner API — calls the monolith directly. After it's introduced, every client calls the orchestration layer, which simply proxies to the monolith; behavior is unchanged, but the layer is now positioned to intercept individual requests and route them to new services as each capability is extracted, without the storefront ever knowing the difference. Only the routing logic changes as each phase completes — the client-facing contract stays exactly the same, which is what lets the migration proceed without dragging the storefront team's roadmap along with it. This is also where younifyd's workflow builder can act as that layer without becoming a new service to own: model a phase's routing decision as a workflow, expose it as a single API route through the gateway, and use the execution timeline to review every run while validating a newly extracted capability against the legacy path.
Choosing what to extract first
The order of extraction matters. A good first extraction has high business value, low coupling to other capabilities, a clear bounded interface, and an easy way back out if it fails. Tax calculation meets all four almost perfectly, which is why it's phase two in nearly every successful commerce strangler fig migration: send it a cart with line items, a shipping address, and a customer ID, and it returns tax amounts per line and in total. A dedicated tax service handles multi-jurisdiction rules and exemptions that most legacy platforms handle poorly, the monolith's tax module rarely writes to shared tables, and rolling back is just re-pointing the routing layer at the monolith again. Product catalogue is a reasonable second extraction — read-heavy, easier to migrate than anything write-heavy: populate a new catalogue service from the legacy database, keep it in sync while the storefront keeps reading through the monolith, and switch routing once verified complete and consistent. Order management, payment processing, and checkout should be extracted last — they're the capabilities most deeply coupled to the monolith's transactional state, and the risk scales directly with the revenue they touch.
The migration roadmap, phase by phase
The following timeline is realistic for a mid-size commerce platform — think £5M–£50M in revenue, 50k–500k SKUs, 3–5 engineers on the migration. Adjust the durations to your own coupling: a heavily customized Magento instance takes longer to untangle than a newer custom monolith. The phases are deliberately conservative — an extra eight weeks validating a phase properly is cheaper than a regression discovered in production. Phases 1 and 2 together take only eight weeks, and by the end of them the business is already running a purpose-built tax service — the pattern working as intended, since early phases pay for themselves instead of the migration sitting as a pure cost center.
Handling data ownership during the migration
Every extraction raises the same question: while the new service is being built and validated, which system is the source of truth? The answer has to be the legacy system until the extraction is complete — dual-writing to both databases at once creates a consistency problem harder to resolve than the original migration. The practical approach: build the new service to read from the legacy database first, through a read-only connection or a data-access layer that abstracts the legacy schema, rather than giving it its own database from day one. That keeps it working from the same data as the legacy platform, so validation is a direct comparison of outputs for the same input. Once the new service matches the legacy system consistently for a defined validation period — typically two to four weeks in production — routing switches over, the new service migrates to its own database, and the legacy tables go read-only, then get archived. A single authoritative source until the last possible moment is what removes the data-consistency risk.
Shadow mode: validating before you cut over
Shadow mode is the period when the routing layer calls both the legacy capability and the new service for every request, routes the live response from the legacy system, and logs any discrepancy from the new service — the customer always gets the legacy response, so you validate against real production traffic with zero customer-facing risk. It surfaces exactly the discrepancies integration testing misses: edge cases that only show up in real sessions, timing-dependent behavior, and subtle differences from data migration. For tax, it often reveals an exemption category the new service handles differently; for pricing, a promotional bundle rule it didn't replicate — caught safely instead of catastrophically. The discipline matters more than the tooling: someone reviews discrepancies daily and holds off switching traffic until the rate is at zero, or at an acceptable threshold for genuinely immaterial differences like currency rounding.
Five failure modes to avoid
Most commerce strangler fig migrations that fail do so for one of five reasons. Skipping the orchestration layer: routing traffic at the DNS or load-balancer level instead requires a client-side change for every extraction and ties the timeline to the storefront team's release schedule. Extracting checkout too early: it's the most coupled capability in any commerce monolith, and extracting it before the team has confidence in the routing layer is the most common cause of migration failure. Big-bang data migration: moving all product, customer, and order data to new databases in a single cutover weekend is a bigger risk than most teams admit, and insisting on 'doing it properly' up front routinely delays extraction by months. Losing shadow-mode discipline: running shadow mode for a week, seeing 'mostly similar' results, and switching traffic early is how teams discover the edge case they missed — after a real customer hits it. Treating the migration as a technology project instead of a business one: funded purely as an engineering initiative with no visible milestone, it gets cancelled the moment the business comes under pressure — framing each extraction as an outcome keeps it invested even when the customer-facing change is invisible.
When the strangler fig becomes the new platform
A successful strangler fig migration doesn't end with a single cutover event — it ends with the gradual realization that the legacy platform no longer handles any meaningful traffic. At some point the routing layer is sending 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 traffic left on the monolith is for whatever hasn't been extracted yet — a small fraction of original volume, retirable on a schedule that suits the business rather than an engineering deadline. Removing the last monolith route is a configuration change, not a migration project, because the routing layer already absorbed the complexity along the way. That layer doesn't disappear once the migration is done — it becomes the permanent orchestration layer for the composable platform, fanning out to services in parallel and giving you one place to see how every request behaved.
Start your migration without stopping the business
Model the routing layer as a workflow, expose it as an API route through the gateway, and start free — no credit card required.
Try for Free