All WorkCase Study · Multi-Store Program
Type
Replatform → Multi-Store Program
Platform
Shopify Plus · 6 expansion stores
Markets
FR · DE · PL · NL · SI · UK
Client
Under NDA — happy to name it on a technical call
Services
ReplatformingStore TopologyCatalog SyncLaunch Engineering
Stack
Shopify Plus · Admin GraphQL 2026-07 · Cloudflare Workers + D1 · Python · Liquid / OS 2.0 · Playwright + BrowserStack · Translations API
The Challenge
Shopify Markets can serve six countries from one store. This business could not be served by one store.
A European D2C + B2B brand on PrestaShop 1.7 needed Shopify Plus without losing its multilingual catalog or three languages of accumulated SEO equity. Then the scope changed underneath the replatform: six European markets, each with its own VAT registration, its own ERP and 3PL, and its own payment expectations.
Markets was the default answer and the operational structure ruled it out. Separate VAT registrations mean each market’s orders have to terminate in their own compliant invoicing setup. Each market’s ERP — not Shopify — owns what is in the warehouse, so a single inventory ledger would have to reconcile six regional systems that do not know about each other. One store could not model any of that, so the architecture became a fleet.
264
Redirects, generated from three PrestaShop market subfolders
6
Markets — one catalog source of truth, five expansion stores
5
Locales, registered create-then-translate and intersected per store
70
Sync-worker tests covering fan-out, idempotency, the never-write boundary
The Approach
A sync boundary the architecture enforces, so no future developer has to remember it.
01
Catalog flows down, commerce never flows back
Catalog, content, and translations fan out from the main store to the five children over a Cloudflare Workers + D1 sync worker. Inventory, orders, and customers are never written — not rate-limited, not opt-in, but structurally impossible, because the app never requests those scopes. Each country’s ERP keeps ownership of its commercial records.
02
A taxonomy designed backwards from what replicates
Only tag-rule smart collections survive the trip to a child store — metafield-based rules reference definitions local to each store. That one platform constraint dictated the entire collection taxonomy, and the tagging vocabulary became a governed part of the catalog rather than an afterthought.
03
One theme repo, six deploy targets
A Liquid / Online Store 2.0 theme in a single GitHub-integrated repo deploys to every store in the fleet, verified by Playwright across 30+ real browser and device combinations on BrowserStack with axe-core WCAG 2.1 AA scans on every major flow.
04
The IA restructure landed before cutover, on purpose
New collection taxonomy, new menus, and 264 redirects went live on the existing main store ahead of DNS cutover. Search Console starts accumulating baselines against the final information architecture, and indexing problems surface while the old platform still carries the traffic.
Where It Stands
Delivered — activations roll through Q4 2026
Migration, theme, QA and sync are done and verified. Six markets stand ready to activate.
Every expansion store is fully staged: ERP integration wired to its local stock source, and the per-store setup matrix worked through and signed off — menus, search filters and app installs sit deliberately outside the sync worker’s scope, so each one was hand-configured and verified as a checklist item. Activation is now the client’s move: they bring each market live on their own commercial calendar through Q4 2026, with DNS cutover as the gate they control. The engineering side of that gate is done — a verified redirect map, green E2E runs against every store, and a signed-off setup matrix per market.
The multi-store content model was designed backwards from what Shopify allows to move between stores. Discovering those limits after building the taxonomy would have meant rebuilding it; discovering them first meant the taxonomy was portable from day one.
