commercetools Migration: The Strangler Fig Approach

When Gadero moved its 20,000-product timber business from an outdated platform to commercetools, the new stack went live in Belgium first — the smaller market — then rolled to the Netherlands, Germany, and France after each round of fixes. When GOED put 120,000 healthcare products online, one category launched first and the rest followed in phases. Neither project had a cutover night. That is the strangler fig pattern doing its job, and this article is the playbook behind it.

Why big-bang replatforms go wrong

The failure mode is always the same three compounding problems:

1. The roadmap freezes. A twelve-month rebuild means twelve months where every business request gets the answer “after the migration.” The backlog that accumulates then destabilizes the launch it was waiting for.
2. All risk lands on one night. Every integration, every pricing rule, every edge case in ten years of order flows has to work simultaneously, at full traffic, on day one.
3. Search traffic falls off a cliff. URL structures, internal links, and page performance all change at once. If organic revenue matters, you find out what broke only after it stops converting.

The strangler fig pattern — Martin Fowler’s name for building the new system around the edges of the old one until the old one can be switched off — exists to break all three at once. Commerce platforms suit it unusually well, because commerce traffic decomposes naturally along lines customers never see.

Cut vertical slices, not horizontal layers

The first instinct is usually horizontal: “move the product pages to commercetools first, keep checkout on the monolith.” Resist it. A customer journey that renders its product page on the new stack but carts on the old one needs a bridge — session sharing, a cart-sync API, double-maintained promotion logic. That bridge is throwaway engineering, and it’s where these projects sink.

Vertical slices keep every request path on exactly one stack:

• By market, like Gadero: Belgium runs entirely on commercetools while the Netherlands runs entirely on the monolith. The routing decision is one hostname or geo rule at the edge.
• By category, like GOED: one product category, its search results, and its checkout live on the new platform; a path rule at the reverse proxy sends everything else to the legacy system.
• By brand or business unit, if you operate several — often the cleanest seam of all, since data rarely crosses it.

The routing seam itself is boring on purpose: a CDN rule, an edge worker, or a reverse proxy mapping paths and hostnames to stacks. Boring is what you want at the one component both systems depend on.

Pick the first slice for learning value, not revenue: small enough that an incident is survivable, real enough that it exercises pricing, payment, tax, and fulfilment end to end. Belgium-before-Germany is a strategy, not an accident.

The integration layer does the heavy lifting

During the strangling period — typically several quarters — both stacks must agree on products, prices, stock, and orders. The way to keep that sane is to make neither commerce platform the source of truth for anything:

With an event-driven integration layer fanning the same feeds out to both platforms (at Gadero this is CoreConnect, the group’s integration product), “two stacks” stops meaning “two catalogs to reconcile.” commercetools consumes the feeds through its import APIs and emits order events through subscriptions; the monolith keeps whatever plumbing it already had.

Two disciplines make this work in practice. First, stable IDs: the SKU is the join key across every system — never let either platform mint its own. Second, decide the customer-account question in week one, because “which stack does a returning customer log into during month four” is the question teams most often discover too late.

And migrate less than you think. Order history belongs in the old database behind a read-only lookup, not in commercetools; statutory retention doesn’t require re-importing a decade of orders into your new order model.

SEO through the transition

The phased model turns SEO from a launch-night gamble into a per-slice checklist:

• Per-slice 301 map. Every legacy URL in the slice redirects to its successor the moment the route flips — generated from data, not curated by hand.
• URL parity where cheap. If the new stack can keep /decking/oak-25mm/ unchanged, keep it; the best redirect is none.
• One canonical set. The routing seam must never serve the same product from both stacks under two URLs.
• Sitemaps that follow the routing. Each phase regenerates them; Search Console shows you the crawl moving over.
• Measure the slice, not the site. Belgium’s organic curve after cutover tells you whether Germany is safe to move. That feedback loop is the whole reason to sequence markets this way.

When to stop — and when not to start

The strangler period costs real money: two stacks, two skill sets, an integration layer running hot. It’s a bridge, not a destination, so give it a kill date. “The monolith serves no production traffic by Q3” is a plan; “we’ll migrate the rest eventually” is how companies end up running both forever. Track the retirement of legacy components as first-class roadmap items, and hold the routing layer until the old stack is actually off.

Equally: don’t strangle what you can simply replace. A few thousand SKUs, one market, standard checkout — a well-prepared direct replatform with a redirect map is cheaper than months of dual-running. The pattern earns its overhead when catalogs are deep, markets are multiple, and organic traffic is revenue — which is also roughly the profile where commercetools beats a SaaS suite in the first place.

The checklist

• Choose vertical slices (market, category, brand) — never split one journey across stacks
• Make the first slice small, real, and end-to-end
• Route at the edge; keep the seam boring
• PIM and ERP stay the sources of truth; both stacks subscribe through one integration layer
• SKUs are the universal join key; settle customer-account ownership in week one
• Archive order history read-only instead of migrating it
• Ship a generated 301 map with every slice; watch organic per slice before moving the next
• Put a kill date on the monolith and manage to it

This is the standing playbook of our commerce platform engineering practice — Gadero and GOED above are it running in production. If you’re staring at a monolith and a board that wants it gone, we’re happy to pressure-test your slicing plan.