Use Shopify Markets within one store when countries share a brand, catalogue, operating team and core commerce stack, and differences can be handled through market-level language, currency, pricing, domains, duties and content. Use separate stores when markets require independent legal entities, catalogues, checkout or app behaviour, release schedules, data boundaries, teams or integrations.
The choice should follow operating-model differences, not country count. One store reduces duplication; multiple stores increase autonomy and isolation.
What Shopify Markets centralises
Markets lets a merchant define country or region audiences and configure currency, language, domains or subfolders, pricing, product availability, duties and taxes, and selected experience customisations. It keeps products, orders, themes, apps and reporting closer to one administrative core.
Centralisation is valuable when the same team wants consistent releases and inventory while presenting local experiences.
What separate stores provide
Each store has independent configuration, applications, data, catalogue, theme, checkout settings and integrations. Shopify Plus expansion stores can support eligible international, B2B or specialised experiences under an organisation, subject to Shopify’s criteria and commercial terms.
Separate stores create strong boundaries, but every boundary adds synchronisation and governance work.
Decision one: legal entities and payments
If markets trade through different entities, bank accounts, tax registrations or merchant-of-record arrangements, verify whether the plan supports the required business-entity configuration. Separate stores may simplify legal and financial separation.
Map order ownership, invoicing, refunds, chargebacks, payouts, tax evidence and accounting before choosing architecture.
Decision two: catalogue and pricing
Markets works well when products are mostly shared with controlled availability and local pricing. Separate stores are stronger when assortments, merchandising, product data, bundles or release calendars differ substantially.
Do not underestimate catalogue governance. Duplicated products can drift across stores, while one global catalogue can become overloaded with market-specific logic.
Decision three: inventory and fulfilment
Model inventory locations, sourcing, reservations, split shipments, returns and warehouse routing. Community reports show that incorrect market and location configuration can route orders across regions and destroy margin.
Test each destination with real fulfilment scenarios, not only storefront previews. Decide which system is authoritative for inventory and promises.
Decision four: localisation
Markets can support languages, local domains, currencies and content customisation, but deep market-specific journeys may require theme logic and app support. Separate stores give local teams freedom to build different experiences.
Localisation includes product claims, sizes, address formats, payments, promotions, service messages and customer support, not only translation.
Decision five: SEO
One store with subfolders can consolidate domain authority and simplify governance. Country-code domains can strengthen local signals but require separate SEO management. Multiple stores create duplication, hreflang, canonical and migration risks.
Choose URL architecture early. Preserve stable paths, implement hreflang correctly, localise substantive content and monitor indexing by market.
Decision six: apps and integrations
Confirm whether every app supports Markets, local currencies, catalogues and market-aware behaviour. One-store architecture can be constrained by an app that assumes one country. Multiple stores may require repeated subscriptions and duplicated configuration.
For ERP, PIM, CRM, OMS, tax and marketing platforms, document store and market identifiers and master-data ownership.
Decision seven: analytics and advertising
One store simplifies consolidated commerce data but market reporting and advertising connectors may have limitations. Multiple stores create separate datasets and pixels that require central warehousing and identity strategy.
Define contribution, currency conversion, consent and channel-account structure before launch. Never assume a connector supports the desired multi-market setup.
Operating-cost comparison
One store reduces theme, app, product and release duplication. Its complexity appears in conditions, permissions and shared change risk. Multiple stores increase subscription, development, QA, catalogue, reporting and support effort but isolate changes.
Build a three-year cost model including licences, apps, integrations, localisation, content, QA, analytics, operations and future migration.
Migration roadmap
Map current markets and operating differences. Classify requirements as native, configurable, custom or unsupported. Prototype the hardest market. Establish product, price and inventory masters. Build URL and redirect plans. Test tax, payment, fulfilment, returns and analytics. Launch one controlled market before scaling.
Keep rollback and order-support procedures for the launch window.
Architecture scorecard
Score legal-entity fit, catalogue divergence, pricing, inventory, fulfilment, localisation, checkout, apps, data, SEO, analytics, team autonomy and release independence. Weight each market, because Germany and the UAE may have different operational needs.
One store wins when shared capabilities dominate. Multiple stores win when local independence is material and sustainable. A close score suggests piloting the hardest market before committing.
Data ownership model
Define master systems for product, customer, price, inventory, order, fulfilment, promotion and consent. In one store, market configuration must not become an undocumented second master. In multiple stores, use durable global IDs so central systems can reconcile entities.
Document create, update and delete flows. Test delayed and duplicate messages. International commerce failures often begin as master-data ambiguity.
International SEO migration checklist
Inventory every current URL and its market purpose. Select domains, subdomains or subfolders. Map redirects one to one. Configure canonicals and hreflang. Localise titles, content and structured data. Preserve valuable backlinks. Submit sitemaps and monitor indexing, traffic and conversion by country.
Do not redirect every retired local page to the global home page. Maintain equivalent intent wherever possible.
QA matrix
Test location detection, language, currency, price, product eligibility, promotions, payment, address, tax, duty, shipping, inventory source, confirmation, notification, analytics, cancellation, return and refund for each market. Include VPN-independent test methods and known traveller scenarios.
Run desktop and mobile, guest and signed-in, new and returning customer paths. Record expected legal entity and fulfilment location for every test order.
Operating governance after launch
Assign global ownership for platform, brand, catalogue standards and data. Assign local ownership for content, commercial calendar, compliance input and customer operations. Use a change board only for shared high-risk capabilities; allow local autonomy within guardrails.
Review market profitability including duties, fulfilment, returns, payment and support, not revenue alone. Architecture should make true contribution visible.
Detailed execution checklist
Market requirements
Document entity, language, currency, catalogue, price, promotion, payment, tax, duty, fulfilment, return and support differences for every country.
Plan capability
Verify current Shopify plan requirements for business entities, checkout customisation, B2B catalogues, expansion stores and reporting. Platform capabilities change, so record the research date.
Domain strategy
Choose domain, subdomain or subfolder with brand, SEO and operational ownership in mind. Register and secure domains centrally.
Catalogue governance
Define global and local product ownership, durable identifiers, translation, media and availability. Prevent market conditions from becoming untestable theme logic.
Pricing governance
Decide base prices, local prices, rounding, discounts, tax inclusion and exchange-rate handling. Test margin after duty, fulfilment, payment and returns.
Inventory routing
Map locations and priority by market. Test shortages, split fulfilment, preorder, return and cancellation. Monitor orders fulfilled from the wrong region.
Checkout and payments
Test local payment methods, address formats, fraud, tax, duty and legal entity. Confirm settlement and refund accounting.
App compatibility
Create a market-capability matrix for every app. Verify customer-facing output and data integration rather than relying on marketplace claims.
ERP and PIM integration
Pass market, entity, currency and catalogue identifiers consistently. Define replay and reconciliation for failed messages.
Marketing technology
Design feeds, pixels, consent, email, attribution and advertising accounts by market. One store does not automatically create correct market measurement.
Customer identity
Decide whether accounts and consent are global or market-specific. Handle privacy requests and communication preferences across systems.
SEO operations
Own hreflang, canonicals, localisation, redirects, sitemaps and indexing monitoring. Avoid thin machine-translated country pages.
Release governance
Test shared changes against every active market. Use flags and staged rollout. Separate stores need a controlled mechanism to propagate safe global changes.
Support readiness
Prepare local policies, service hours, returns and escalation. Customer experience after checkout often determines whether expansion is profitable.
Financial reconciliation
Reconcile orders, payouts, taxes, refunds and currency effects by entity and market before executive reporting.
Exit path
Document how a market can be separated, consolidated or closed. Preserve global identifiers and exportable data.
Practitioner planning workbook
Country business case
For country business case, validate demand, margin, service level, returns and compliance before architecture. Record the current state, target state, accountable owner, dependencies and evidence required for approval. Test the assumption using production-like information, and define the failure signal that would stop or redirect the work.
Entity structure
The entity structure workstream should map seller, payout, invoice, tax, refund and accounting ownership. Convert the decision into measurable acceptance criteria, an owner and a review date. Include normal operation, edge conditions and recovery, because a design that works only in the happy path is not production-ready.
Market grouping
Treat market grouping as an operating control: combine countries only when commercial and operational rules genuinely align. Preserve the supporting artefacts, unresolved questions and agreed exceptions. Recheck the control after launch so temporary migration choices do not become permanent unmanaged risk.
Plan features
For plan features, verify current Markets, entity, checkout, catalogue and expansion-store capability. Record the current state, target state, accountable owner, dependencies and evidence required for approval. Test the assumption using production-like information, and define the failure signal that would stop or redirect the work.
URL design
The url design workstream should select domain, subdomain or subfolder and define SEO ownership. Convert the decision into measurable acceptance criteria, an owner and a review date. Include normal operation, edge conditions and recovery, because a design that works only in the happy path is not production-ready.
Language model
Treat language model as an operating control: govern translation, review, glossary, content freshness and fallback. Preserve the supporting artefacts, unresolved questions and agreed exceptions. Recheck the control after launch so temporary migration choices do not become permanent unmanaged risk.
Price model
For price model, control local lists, FX, rounding, discount, tax and margin. Record the current state, target state, accountable owner, dependencies and evidence required for approval. Test the assumption using production-like information, and define the failure signal that would stop or redirect the work.
Catalogue model
The catalogue model workstream should define global products, local assortment, identifiers, bundles and releases. Convert the decision into measurable acceptance criteria, an owner and a review date. Include normal operation, edge conditions and recovery, because a design that works only in the happy path is not production-ready.
Inventory model
Treat inventory model as an operating control: test locations, priority, shortages, split orders and safety stock. Preserve the supporting artefacts, unresolved questions and agreed exceptions. Recheck the control after launch so temporary migration choices do not become permanent unmanaged risk.
Fulfilment model
For fulfilment model, route warehouse, carrier, duty, delivery promise and return correctly. Record the current state, target state, accountable owner, dependencies and evidence required for approval. Test the assumption using production-like information, and define the failure signal that would stop or redirect the work.
Payment model
The payment model workstream should validate local methods, fraud, settlement, refunds and chargebacks. Convert the decision into measurable acceptance criteria, an owner and a review date. Include normal operation, edge conditions and recovery, because a design that works only in the happy path is not production-ready.
Tax and duty
Treat tax and duty as an operating control: confirm display, collection, evidence and post-order adjustment with specialists. Preserve the supporting artefacts, unresolved questions and agreed exceptions. Recheck the control after launch so temporary migration choices do not become permanent unmanaged risk.
App matrix
For app matrix, test every customer-facing and back-office app by market. Record the current state, target state, accountable owner, dependencies and evidence required for approval. Test the assumption using production-like information, and define the failure signal that would stop or redirect the work.
Integration contract
The integration contract workstream should pass store, market, entity, currency and global IDs through systems. Convert the decision into measurable acceptance criteria, an owner and a review date. Include normal operation, edge conditions and recovery, because a design that works only in the happy path is not production-ready.
Analytics plan
Treat analytics plan as an operating control: design consent, attribution, channel accounts and consolidated reporting. Preserve the supporting artefacts, unresolved questions and agreed exceptions. Recheck the control after launch so temporary migration choices do not become permanent unmanaged risk.
SEO launch
For seo launch, implement localisation, hreflang, canonicals, redirects and sitemaps. Record the current state, target state, accountable owner, dependencies and evidence required for approval. Test the assumption using production-like information, and define the failure signal that would stop or redirect the work.
QA coverage
The qa coverage workstream should execute end-to-end orders for representative customer and failure paths. Convert the decision into measurable acceptance criteria, an owner and a review date. Include normal operation, edge conditions and recovery, because a design that works only in the happy path is not production-ready.
Local operations
Treat local operations as an operating control: prepare support, returns, merchandising and incident ownership. Preserve the supporting artefacts, unresolved questions and agreed exceptions. Recheck the control after launch so temporary migration choices do not become permanent unmanaged risk.
Release controls
For release controls, use flags, staged rollout and regression across shared markets. Record the current state, target state, accountable owner, dependencies and evidence required for approval. Test the assumption using production-like information, and define the failure signal that would stop or redirect the work.
Profitability review
The profitability review workstream should measure contribution after fulfilment, returns, payments, tax and support. Convert the decision into measurable acceptance criteria, an owner and a review date. Include normal operation, edge conditions and recovery, because a design that works only in the happy path is not production-ready.
