Magento 2 websites vs Shopify Markets: the inversion that shapes a migration

Partway through a Magento 2 to Shopify Plus migration, I noticed that every awkward scoping conversation was really the same conversation. Someone would ask where a setting had gone — payment methods for the EU storefront, the Swiss price list, tax display for the UK — and the question always took the same form: on Magento we set that per website. Where does it live now?

The truthful answer is that it doesn't live anywhere, because Shopify has no equivalent of the website ID. It has a different organising idea entirely, and until everyone in the project has internalised that, the migration plan reads like a feature-gap list when it's actually a translation exercise.

How Magento thinks: the merchant dictates

Magento 2's configuration hierarchy is one of the genuinely good ideas the platform has, and it's the thing experienced Magento teams miss most.

Global
└── Website          ← base currency, payment methods, tax config,
    │                  price scope, customer accounts
    └── Store         ← catalogue root categories
        └── Store view ← language, display currency, localised content

The website is the axis of commercial control. Base currency scopes to the website, and with catalog price scope set to Website, so does every price in the catalogue. Payment methods are enabled per website. Tax configuration hangs off the website. Customer accounts can be isolated per website.

The consequence: you dictate the trading rules, and the customer receives them. A German website prices in euros with VAT baked in, offers PayPal and a local PSP, applies German tax rules — because you configured it that way. A French customer browsing that German website gets German terms. Their location changes nothing unless you've built geo-redirection on top. The model is deterministic, and every rule has an owner: the merchant.

How Shopify thinks: the destination dictates

Shopify Plus runs your international trade from one store through Markets. A market is a group of destination countries. Attach a catalogue to it — Shopify calls them catalogs — and that catalogue controls which products are available there and what they cost, either as fixed per-product prices or a percentage adjustment over base.

Notice what's absent from that description: nowhere did you configure a storefront. The chain of decisions runs the other way.

In Magento you configure storefronts and customers arrive at them. In Shopify you describe destinations and the storefront assembles itself around wherever the order is going.

The shipping destination selects the market. The market selects the catalogue. The catalogue and the market's currency produce the price. Change the delivery country at checkout and the currency and prices change with it, mid-session, because the order now belongs to a different market. You can set catalogue prices in whatever currency you like; the customer browses and pays in the currency of their market regardless.

The same logic runs through tax and payments. You don't build tax rules; you register for VAT where you're liable and hand Shopify the registrations, and it applies the right treatment per destination — including dynamic tax display, which shows VAT-inclusive prices to a British customer and tax-exclusive prices to an American one from the same product record. Payment methods, similarly, are largely resolved for you: Shopify Payments surfaces local methods based on the buyer, with per-market toggles if you want to suppress something. Since the multi-entity work landed you can map markets to separate legal entities, each with its own Shopify Payments account, local payout currency and domestic payment methods — iDEAL for the Dutch entity, Bancontact for the Belgian one.

The translation table

That last two rows are where migrations get scoped wrong, so they deserve the detail.

Where the destination model bites

Two price lists in the same country. On Magento, nothing stops you running a retail website and a trade website for the same territory, each with its own prices, payment methods and customer base. Markets can't express that — a destination maps to one market. The Shopify answers are B2B catalogues (genuinely good on Plus now) or a separate expansion store. Decide which before anyone estimates the build.

Regional payment providers. If a territory depends on a third-party gateway — a local PSP with better rates, a market where Shopify Payments doesn't operate — understand that third-party gateways attach to the store, not the market. Every market sees the same third-party checkout options. Shopify Payments is what makes the per-market behaviour work, and the multi-entity setup only deepens that dependency. For most brands this is fine and the local-method coverage is honestly better than what their Magento PSP config achieved. For some it's the reason a region keeps its own store.

Anything regulatory or structural. Region-specific subscription rules, restricted catalogues with legal weight behind them, deep B2B with company-specific pricing and EDI — these still push towards expansion stores. The trade-off is real duplication: apps licensed per store, themes QA'd per store, integrations built per store. Vervaunt's consolidation guide puts the cost of running three expansion stores at six figures a year before anyone ships a feature. Markets exists precisely to make that spend unnecessary for the ordinary cases.

The questions that scope the migration

If you're planning this move, work through these before estimating anything:

1. Export every setting scoped to a website ID and label each one: derived from destination on Shopify, per-market toggle, B2B catalogue, or expansion store. That labelled list is the international scope of your migration.
2. Look for one country with two commercial treatments. Trade and retail, staff store, regional exclusives with separate pricing. Each one is a B2B-or-expansion-store decision, and they're the expensive kind to discover late.
3. Audit gateways against Shopify Payments coverage. If a region can't run on Shopify Payments, its market will behave like a second-class citizen at checkout. Decide whether that's acceptable or whether the region justifies its own store.
4. Collect tax registrations, not tax rules. Your Magento tax matrix doesn't migrate — and mostly shouldn't. What Shopify needs is the list of jurisdictions where you're registered. If that list is shorter than your Magento rules implied, you've found a compliance conversation, not a platform gap.
5. Confirm your apps understand Markets. Plenty still assume one currency and one price list. An app that writes prices or builds feeds needs checking against per-market pricing specifically.

The reflective bit, since this piece is meant to be one: I expected to miss the website ID and mostly didn't. Magento's model hands you total control and the maintenance bill that comes with it — every rule the merchant dictates is a rule someone has to keep true as the business changes underneath it. Letting the destination drive turns a room full of configuration into a short list of registrations and catalogues, and for a catalogue-led brand selling the same products everywhere, that trade is worth taking twice. You feel the loss only at the edges — and now you know which edges, you can scope them on day one instead of discovering them in UAT.