Open-source alternative to Shopify Markets for multi-country selling
If you sell into several countries from one Shopify Plus store and want market-level control without a hosted platform, the open-source replacement is a set of per-market structures you build and operate yourself. Saleor channels, Magento Open Source store views and websites, and Shopware sales channels each cover per-market currency, pricing, stock and domains, but they differ in how much of that is built in and how much you assemble. Shopify Markets groups audiences by location, customer group, retail location or sales channel, and lets you tailor each market's currency, language, pricing, theme content and domains. Reproducing that is a configuration and build problem, not a feature toggle: you define the market boundaries, map each one to a channel or store view, and then wire pricing, tax, stock allocation, storefront routing and checkout to match.
This section covers how the open-source platforms model markets and which of Shopify's market controls each one carries over. It does not decide which platform fits your catalog, which storefront framework you use, or how your tax, duty and payment obligations apply in each country, because those depend on your legal entities, payment providers and logistics. Before comparing platforms, confirm with your tax advisor and payment providers which currencies, price lists and gateways each market needs, and ask which of your markets share inventory. Review the Shopify Markets documentation in the Shopify Help Center so the market inventory you export matches the audiences you actually run today.
The practical risk is that market logic ends up split between the platform and your code. Saleor's channel model is built around per-channel pricing, currencies and warehouses, so most of that logic sits in the core data model, while Magento and Shopware require more deliberate setup of store views, websites or sales channels and their catalog, price and domain rules. Plan for a test matrix that covers each market's currency rounding, tax display, language fallback and domain redirects before any market goes live. Ask any implementation partner to deliver that matrix in writing as part of the agreed scope.
Which Shopify Markets capabilities map to which open-source option
This table maps each Shopify Markets capability to its closest scope in Saleor channels, Magento Open Source store views and websites, and Shopware sales channels. Where a platform's docs do not clearly confirm a capability, the cell says what to verify before you plan the build. The main takeaway is that per-market currency and pricing map well, while market-specific theme content and automatic market detection need custom work on every platform.
| Shopify Markets capability | Saleor channels | Magento Open Source | Shopware sales channels |
|---|---|---|---|
| Market definition by location or customer group | Channels scope products, prices and stock. Customer-group audiences need custom logic or a confirmed app. | Websites and store views scope catalog and content. Confirm how customer groups can drive market access. | Sales channels scope the storefront. Confirm whether customer-group rules are supported in your version. |
| Currency per market | Per-channel currencies are supported natively. | Currency is set at store scope. Confirm which scope applies in 2.4.9 before you design markets. | Confirm currency assignment per sales channel in current documentation. |
| Language per market | Channels do not render language. Your storefront must handle locale routing and translated content. | Each store view can serve one language. Confirm how many store views a single website can carry. | Confirm how languages are assigned to sales channels and whether the storefront switches them. |
| Pricing per market | Per-channel pricing is supported natively for products and variants. | Confirm catalog price scope and whether website-level pricing covers every market you sell in. | Confirm pricing lists or rules per sales channel in your installed version. |
| Stock per market | Multi-warehouse stock can be assigned to channels for per-market availability. | Confirm how Multi-Source Inventory assigns sources to store scope in your setup. | Confirm how warehouses and stock are linked to sales channels. |
| Theme content per market | Gap: a headless storefront must be built or adapted per market. No theme-level equivalent exists. | Gap or partial: store view and CMS content can differ, but theme variation per market needs confirmation. | Gap or partial: confirm whether each sales channel can use its own theme and content. |
| Domains and URLs per market | Storefront domains and hreflang are set by your frontend deployment, not by Saleor. | Base URLs are set per website. Plan hreflang and redirects yourself. | Confirm domain mapping per sales channel and how canonical URLs are handled. |
| Automatic market detection | Gap: detection by location or visitor signals is not built in. Plan geo-routing in your frontend or edge layer. | Gap: confirm whether any built-in redirect or detection exists in your version. | Gap: confirm whether automatic market selection is included or needs a plugin. |
Choosing between Saleor, Magento Open Source and Shopware for markets
Each option can serve several markets from one installation, but they differ in how they model channels, how much storefront work you take on and who carries the operating load. The cards set out the fit and trade-offs of each platform, followed by the stack every self-hosted choice inherits. Use them to shortlist, then test your own market rules against each platform.
Saleor for channel-based markets
Saleor is BSD-3-Clause licensed and built on Python, Django, GraphQL and PostgreSQL. Each market can map to a channel with its own pricing, currency and stock drawn from specific warehouses, so one catalog can serve several countries. You build the storefront yourself against the GraphQL API, which makes the theme, checkout interface and locale content your engineering work. Check whether your team can own a headless frontend and whether your market rules fit channel-level configuration.
Magento Open Source for store-view markets
Magento Open Source is licensed under OSL-3.0, with AFL 3.0 also included in the distribution. Markets are usually modeled with websites and store views that separate currency, language and catalog scope, but cross-market pricing and stock rules need deliberate design and testing. Code contributions fall under Adobe's Contributor License Agreement, and Adobe Commerce is the separate commercial edition. Plan for Varnish full-page caching, OpenSearch and a message queue, and confirm the support window for the release line you choose.
Shopware 6 for sales-channel markets
Shopware 6 is MIT licensed and organizes storefronts into sales channels that can carry their own currency, language and domain settings. The Community Edition is free only while linked shops stay below the revenue threshold on the Community Edition, measured over the preceding 365 days. Above that level a paid plan is required, and Shopware states that its pricing depends on gross merchandise value and other factors. Confirm which market features you need in the free edition and what each paid plan includes before you commit.
Operating load every option inherits
Running any of the three means owning the hosting, patching, backups and PCI scope that a hosted Shopify Markets setup currently absorbs. Saleor needs its API, Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, so each market environment adds components to run. Magento and Shopware bring their own search, cache and queue dependencies. Ask each vendor or partner for a reference architecture, then price the on-call rota, patch cycle and restore testing for every environment you plan to run.
How each platform models a market
In Saleor, a channel is the unit that carries a market's commercial rules. Each channel sets its own currency and default country, holds its own product pricing, and is linked to the warehouses that fulfill orders for that market. Products and variants are defined once in the shared catalog, and the channel decides whether each product is listed and at what price. Everything is reached through the Saleor GraphQL API, so a storefront requests a specific channel with each call.
- Currency and pricing: each channel has its own currency and per-variant channel listing prices.
- Warehouses: warehouses are assigned to channels, so stock for one market can come from a local location or a shared one.
- Shared catalog: products, attributes and categories are maintained once and published to the channels that need them.
- Domains and language: domains are not part of the channel model. Your storefront maps hostnames and locales to channel identifiers, and translation handling should be confirmed for your Saleor version.
Before migrating, check which channels your storefront can request and whether every product sold in a market has a channel listing with a price.
Magento Open Source organizes multi-market stores in a hierarchy. A website sits at the top and usually corresponds to one market or region, with store groups and store views beneath it for languages or presentation variants. Configuration such as currency, locale and tax can be set at global, website or store view scope, and catalog and price scope settings decide whether products and prices are shared across websites or kept separate. Confirm the exact scope options in the Magento Open Source version you target.
- Websites: the top-level unit that holds domains and usually one currency per market.
- Store views: language or storefront variants under a website, each able to carry its own content and theme settings.
- Config scope: currency, locale and tax settings are chosen per scope, so each market can differ without separate installations.
- Price scope: determines whether prices are global or per website, which affects every market's price list and is difficult to change once prices exist.
- Inventory sources: multi-source inventory can be assigned to websites, so confirm how sources and stock rules map to each market in your version.
Before building, decide the price scope and the website layout on paper, because these choices shape the catalog data and the indexing you run later.
In Shopware 6, a sales channel is the storefront unit for a market. It is attached to one or more domains, and each domain carries its language and locale settings. Customers, carts and orders are linked to the sales channel they came from, which makes reporting and fulfillment rules per market possible. Shopware also provides a storefront per sales channel that can be configured separately. Confirm the exact configuration hierarchy and pricing options in the version you plan to run.
- Domains: a sales channel is connected to domains, and each domain sets the language and locale shown to shoppers.
- Currency and pricing: currencies and price settings are configured for the sales channel; confirm whether prices can differ per channel or need rule-based pricing.
- Catalog visibility: the product catalog is shared, while product visibility and availability can be set per sales channel.
- Storefront: each channel can have its own theme and page content, which the storefront team manages and tests separately.
- Licensing threshold: Shopware's pricing page says shops above 1 million euros in gross merchandise value over the preceding 365 days need a paid plan, so combined volume across markets affects licensing.
Ask Shopware which sales channel and domain limits apply to the edition you choose, and whether the revenue threshold is measured across all channels together.
Across all three models, master product data is usually shared while commercial rules are separated by market. The design choice that matters most is where each market's currency, price list, stock location, language and domain are stored, because that determines how many configurations you maintain and how many storefront variants you test. Shopify Markets bundles these settings per market, so each target platform will split them differently and some fields will not have a one-to-one match.
- Shared: product master data, categories, media and most attributes live once in each option, which keeps the catalog a single source of truth.
- Separated: currency, price lists, stock locations, languages and domains are set per market in each model.
- Storefront work: Saleor needs a storefront that understands channels, while Magento and Shopware ship storefront frameworks with per-scope or per-channel theming that still require customization.
- Operations: tax, shipping and payment rules often need per-market setup, and each new market adds configuration to test.
- Mapping: Shopify's market fields rarely map cleanly, so document the translation before migration begins.
Ask for a worked mapping of each market's currency, price list, stock locations, languages and domains into the chosen model before estimating build and testing effort.
What you must build that Shopify Markets gave you
Shopify Markets bundles several jobs that you will have to assign to named owners after leaving Shopify Plus. Market detection and redirects, localized theme content, per-market tax and duty setup, payment routing by currency, translation workflows and search indexing per market all sit inside one admin screen today. On a self-hosted stack, the platform covers only part of that list. Saleor provides channels with their own currency, pricing, stock and products, which gives you the data model for each market. Magento Open Source and Shopware provide multi-store configuration with separate base URLs, currencies and locales. Everything that decides which visitor sees which market, and what happens at checkout, has to be designed and built by your team or a partner.
Split the work into three buckets before you choose the extension and custom code budget. Platform-native work includes channel and currency configuration, per-channel product availability and the store-view or channel structure itself. Extension or app work includes translation management, tax calculation engines and payment gateway plugins that support multiple currencies, which you must confirm for each gateway in your shortlist. Custom code usually covers geo detection and redirect rules, the storefront logic that switches language and theme content, and search index routing so each market queries its own catalog. Mark every item with an owner, such as a commerce lead for channel design, a finance lead for tax and duty, a localization manager for translations and a developer for redirects and indexing.
Ask each owner for a written test plan before go-live, because the failures are regional and easy to miss. A checkout that charges the right currency in one market can silently fail in another if a gateway rule or tax setting is missing. Ask for test orders in every market, with a check on the displayed price, tax line, payment method and confirmation email language. Confirm how redirects handle shoppers who arrive on the wrong domain and how search results behave when a product has no stock in a given channel. Some of these behaviors depend on the specific extension or Saleor version you select, so confirm them in writing with the vendor or your partner rather than assuming parity with Shopify Markets.
Running a market platform alongside your existing stack
A multi-market store rarely runs alone. ERP, tax, payment providers, translation tools and analytics keep operating around the commerce platform, and each link becomes an API contract, a webhook you must receive reliably, or a credential someone must own. The cards below cover the parts that usually stay and what to review before cutover.
ERP and stock feeds
Your ERP usually remains the system of record for inventory, cost and purchase orders, while Saleor holds per-warehouse stock for each channel. Decide which side owns allocation and how often stock is pushed, using the GraphQL API for writes and webhooks for order events. Check how a failed sync is detected and replayed, and which service account can change stock levels. Ask your ERP vendor which integration pattern it supports before designing the feed.
Tax engine integration
Each market may need its own tax calculation, rounding and invoice rules, and a tax service often sits between checkout and your accounting system. Confirm whether the tax provider is called synchronously during checkout or after order placement, because that changes latency and failure behavior. Review who can change tax configuration per channel, and log every rate change. Your tax advisor should confirm the rules for each country before go-live.
Payment provider connections
Payment gateways hold card data or tokens, and multi-gateway setups multiply the credentials you must store. Keep provider keys in a secrets manager, scope each key to one channel, and restrict who can rotate them. Check that webhook signatures are verified for every gateway, and document which gateway serves which market. Confirm with each provider which of your setups keep card data out of your environment and how that affects your PCI scope.
PIM and translation tools
A product information management system or translation service often supplies descriptions and localized attributes for each market. Map its identifiers to Saleor product and channel listings so translated content lands on the right storefront. Decide whether translations flow in through the API on a schedule or on publish events, and who approves changes before they go live. Check that translator accounts cannot change prices or stock.
Analytics and event pipelines
Analytics tools receive order, cart and consent events tagged with the market, currency and channel. Route them through a server-side collector you control where possible, so you can filter personal data before it reaches third parties. Check consent handling per country, because the same event may be lawful in one market and restricted in another. Review which write keys are embedded in storefront code, since anything in the browser is public.
Middleware and automation layer
Middleware such as an integration platform or workflow engine often connects these systems, and it becomes a privileged component holding tokens for every one of them. Keep its credentials separate per integration, enable audit logs for runs, and define retry and dead-letter handling for failed webhooks. Confirm that Saleor webhook deliveries are authenticated and that your receiver rejects unsigned requests. Review this layer as carefully as the commerce platform itself.
Moving market settings, catalog and customers into a new platform
This sequence moves each Shopify Markets setting into a channel-based model in the new platform, carries the catalog and customer records across without losing images or market logic, and cuts over one market at a time while the original store stays live.
Inventory every market and its rules
List each Shopify market with its audience definition (location, customer group, retail location or sales channel), currency, language, price adjustments, theme content and domains. Export the market settings from the Shopify admin and record which products, collections and discounts are limited to which markets. The merchant owns this list, and the output is a signed-off market register that the rest of the sequence uses as its checklist. Ask your implementation partner to confirm which rules exist only in apps or metafields, since those need the Admin API to extract.
Map currencies and price lists to channels
Translate each Shopify market into a Saleor channel, or into the equivalent market or store structure in Magento Open Source or Shopware. For each channel, define the currency, price list, tax settings, warehouses and language. Check every market's price rules against the target model, because Shopify's market-level pricing does not translate automatically. The output is a channel map that a reviewer has checked line by line against the market register.
Export products, variants and image sources
Export the product CSV from the Shopify admin, which does not include images, and separately collect the public image URLs for every product and variant. Extract metafields and any market-specific product data through the Admin API, since the CSV does not carry them. Keep the original store live until the new platform has imported the images from those public URLs. The check is a record count reconciliation between the export and the target catalog, plus a sample of image links that load.
Import customers within the file size limit
Export customers from Shopify as CSV files. Each file is limited to 15 MB, so split large exports into batches before import. Tags and supported metafields come across in the export, but confirm which fields your target platform needs to hold preferred market, language and currency. Customer records must be checked for duplicates and marketing consent before they are loaded into a new market channel. The output is a reconciled customer count per market.
Rebuild domains and redirects per market
Recreate each market's domain or subdirectory structure on the new platform, then build a URL redirect table that maps every indexed Shopify product, collection and page to its new address for that market. Check that hreflang or language tags point to the right market pages. The check is a crawl of the old URLs against the redirect table, with every legacy URL returning a single redirect to a live page, not a chain.
Run parallel testing for each market
Run the new storefront for one market at a time, with test orders placed in each currency and payment method, and compare prices, taxes, shipping options and stock levels against the live Shopify store. Verify that market-restricted products and discounts behave correctly for each audience. Testing is complete when a sign-off record shows every market's pricing, stock and checkout result matches the register from step one.
Cut over one market at a time
Switch DNS and payment routing for a single market, monitor orders, refunds and inventory sync for that market, and only then move the next one. Keep the Shopify store available as a fallback until the last market is live and its order history has been exported. The output is a cutover log for each market with the date, the owner who approved the switch and the first-week reconciliation result.
What do merchants ask before replacing Shopify Markets?
How much work and cost sits in each component of a multi-market build?
The build cost splits across hosting, storefront, tax, payments and translation, and each has a different payer. Hosting and the platform's services recur every month, and you pay them to your cloud provider or data center. Storefront work (one or more themes or a headless frontend per market) is mostly one-time build effort, paid to your developers or an implementation partner. Tax and payments are ongoing: you pay gateways and tax data providers, and your team or partner maintains the integrations. Translation is a recurring content cost that grows with each language. Ask any quote to list these components separately, with one-time and recurring amounts shown apart, so you can see which drivers move the total.
How long does a multi-market rebuild take, and what drives the duration?
Duration depends on the number of markets, how much each market differs in currency, language, price and legal requirements, and how complete your product data is. A rebuild that mainly adds channels and currencies on one catalog moves faster than one that needs separate storefronts, tax rules and payment methods per country. Other drivers are the number of apps you replace with platform features or custom modules, how clean your product and customer exports are, and how much testing each market needs. Ask a partner for a written schedule tied to a fixed scope, and confirm which market and integration work is included.
Can an in-house team run a multi-market store on its own?
An in-house team can run it if it already has skills in the chosen stack, on-call coverage and a way to handle upgrades. Saleor uses a GraphQL API, Python, Django and PostgreSQL, and needs its API, Dashboard, PostgreSQL, Valkey or Redis, and Celery workers running. Magento Open Source requires a multi-service stack, and Adobe publishes a list of supported versions for each line. Ask yourself who applies security patches, who monitors uptime, who handles PCI scope for payments and who tests a release before it goes live. If those answers are unclear, a retainer with an implementation partner may fit better than building the team first.
What should I ask a partner for in a quote?
Ask for a written scope that lists each market, currency, language and payment method, plus the data you will migrate and the integrations to rebuild. The quote should separate platform setup, hosting configuration, storefront build, tax and payment integration, translation support, testing and documentation. Ask what is fixed-scope and what is billed separately if requirements change, and who owns the deliverables at the end. DeployOpen plans and implements self-hosted platforms in your own cloud accounts or data centers, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask about ongoing support and upgrades as a separate retainer.
Does the platform license limit the number of markets or my revenue?
It depends on the platform, so check each license and edition before you commit. Saleor and Sylius are BSD-3-Clause and MIT licensed, and Magento Open Source uses OSL-3.0 with AFL 3.0 in its distribution. None of those supplied facts limits market count. Shopware is MIT licensed, but its pricing page says shops linked to an account with more than 1 million euros in gross merchandise value over the preceding 365 days need a paid plan instead of the free Community Edition. Medusa's core is MIT, but its role-based Enterprise features need a commercial agreement with MedusaJS, Inc. Confirm the current terms in writing with the vendor before you plan around them.
How long will Magento Open Source receive support for the version I choose?
Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability. The published end-of-support dates are August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Adobe's release schedule says a full patch for the 2.4.x LTS line ships annually in May, and security patches ship at least annually for all supported lines. Plan upgrades around those dates, and confirm the current version and support window on Adobe's released versions page before you sign a scope.
What hosting and security work moves to my team when Shopify Markets is replaced?
Shopify Markets runs inside a hosted platform, so you do not operate the storefront infrastructure, its uptime or its base security patching. After migration, your team or partner handles hosting, caching, search, queues, database backups, operating system and runtime updates, and content security policy settings. Adobe documents Varnish as the full-page cache for self-managed installations. For payments, the PCI scope you carry depends on how your checkout and card data flow are designed, so ask your assessor to review the design before launch. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any report.
What a multi-market open-source setup costs over several years
The largest multi-year cost in a multi-market setup is the work of building and maintaining one storefront experience per market. Separate one-time costs from recurring ones. One-time work covers the initial build of channels, currencies, price lists, tax and shipping rules, translations and the migration itself. Recurring work covers hosting for the application, database, cache, queue workers and search, a CDN serving each region, storefront maintenance, payment and tax integrations that charge their own fees, and security patching. Ask every vendor and partner to split the quote into these lines, because a single platform fee hides most of the recurring load.
Several drivers push these costs up or down. Each added market adds translation, tax registration checks, payment method setup and storefront testing. Each added currency or stock location adds reconciliation work in orders and inventory. Saleor's channel model keeps one catalog and one API across markets, which moves cost toward channel configuration, while Magento Open Source and Shopware multi-store setups each need their own theme and content upkeep. On licensing, Shopware's pricing page says shops above 1 million euros in gross merchandise value over 365 days need a paid plan, and lists Rise at 600 euros per month and Evolve at 2,400 euros per month, with Beyond priced on request. The same page says plan pricing depends on gross merchandise value and other factors, so confirm which plan your volume and market count would require.
Size the recurring infrastructure before you ask for a quote. The Saleor Docker Compose setup asks for at least 5 GB of memory for Docker, which describes a starting point for testing, so production capacity needs its own estimate from your hosting team. Self-managed Magento adds OpenSearch, Redis or Valkey, RabbitMQ and Varnish, and Adobe documents Varnish as the cache accelerator for self-managed installations, so the cache tier is a separate line item. Plan for upgrades as a recurring cost too: Adobe gives each 2.4.x release three years of standard support, with regular support for 2.4.9 ending on May 31, 2029. Medusa's role-based Enterprise features require a commercial agreement, and Sylius Plus is the paid support route, so confirm whether access control and support are in the quote. Request an annual run-rate by line item and a written statement of who patches the storefront and each extension.
How DeployOpen scopes and delivers a multi-market replacement
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a multi-market replacement, we start by mapping your markets, currencies, price lists, stock locations and domains to the platform you choose before any build work begins.
How we scope
- Inventory every market, its currency, language, price lists, tax rules and domain as they exist in Shopify Markets today.
- Agree in writing which channels, warehouses and stock rules the new platform must replicate, and which ones will be simplified.
- Confirm with your team which integrations, payment gateways and fulfillment partners each market depends on before fixed-scope work starts.
How we build
- Model channels, per-channel pricing and currencies in the chosen platform, then test them against a sample of real order flows from each market.
- Configure domains, language routing and storefront logic per market, and document every configuration key and environment variable used.
- Run security testing on the storefronts, APIs and integrations, and record the findings and fixes in a shared report.
How we hand over
- Deliver architecture notes, runbooks for each market's configuration, and the backup and restore procedures your team will operate.
- Walk your operations and engineering staff through pricing, stock and channel changes so they can make routine updates themselves.
- Provide compliance-readiness evidence for your own assessors, while independent auditors and certification bodies issue any formal reports.
How we support
- Ongoing support, platform upgrades and continuous testing are available as retainers after handover.
- Ask us to confirm the upgrade calendar and security patch policy of the platform you select, since these change over time.
- Plan each upgrade with a staging copy of every market so currency, pricing and domain changes are checked before going live.
