PrestaShop multistore and Shopify Markets look like the same idea from a distance. One back office, several storefronts, different domains, different currencies. They are not the same idea, and the projects that go badly are the ones where somebody assumed a one-to-one mapping and only discovered the gaps in week five.
The useful question is not "how do I recreate my shop groups in Shopify". It is "which of my shops are genuinely separate businesses, and which are the same business speaking a different language". PrestaShop lets you avoid answering that. Shopify makes you answer it on day one.
What PrestaShop multistore actually gives you
A PrestaShop multistore install shares one product catalogue, one module set and one database across shops arranged into shop groups. Within that, almost everything can be overridden per shop: theme, domain or URL path, active languages, currencies, carriers, CMS pages, specific prices, category availability, and — depending on the shop group setting — whether customers and carts are shared or isolated.
That last one matters more than people remember. A shop group configured with separate customers means the same shopper has two accounts and two order histories. A shop group sharing customers means one account across storefronts. Whichever you picked years ago is now a fact about your data, and it decides how the customer import has to be shaped.
Markets, or separate stores
Shopify gives you two ways to run more than one storefront, and picking the wrong one is the expensive mistake on this migration.
Markets is one store serving several regions. Each market gets its own domain or subfolder, currency, price adjustments, language, catalogue inclusions and exclusions, and local payment methods. Inventory, products, orders, customers and apps are shared, because there is only one store underneath. Hreflang is emitted for you.
Expansion stores (a Shopify Plus entitlement) are genuinely separate stores with separate admin, separate inventory and separate apps, connected only by whatever you build between them.
The rule we apply when scoping these:
- If your PrestaShop shops differ only by country, language, currency, price or which subset of the catalogue is visible — that is Markets. One store. Do not fight it.
- If they differ by brand identity, legal entity, warehouse, fulfilment team or a catalogue with almost no overlap — that is separate stores.
The trap is the middle case: three shops that started as country sites and slowly grew their own product ranges, their own suppliers and their own merchandiser. On PrestaShop that drift costs nothing because everything lives in one database. On Shopify you have to decide, and the honest answer is usually still Markets, with catalogue exclusions doing the work the drift was doing.
Mapping the pieces
Once the shape is decided, the mapping is fairly mechanical. What follows is the checklist we work through before any data moves.
- Per-shop domains map to market domains or subfolders. Subfolders consolidate authority onto one domain and are the better default unless a country needs a ccTLD for trust or legal reasons.
- Per-shop category and product availability maps to market catalogues — publish or exclude products per market rather than duplicating them.
- Specific prices per shop map to market price adjustments for a percentage rule, or to explicit per-market pricing where the numbers are hand-set. If your PrestaShop specific prices are a tangle of overlapping rules by shop, group, country and quantity, flatten them into a spreadsheet before you migrate. Migrating a mess reproduces the mess.
- Per-shop carriers map to shipping profiles and zones. PrestaShop's carrier-per-shop model is more granular; expect to consolidate.
- Per-shop CMS pages become pages with market-specific visibility, or separate pages per language with the URL structure the market implies.
- Shop-isolated customers collapse into one customer record per email. Decide up front what happens when the same email exists in two shops with different addresses and different consent states — merge on email, keep the most recent address, and take the most restrictive marketing consent of the two. Not the most convenient one.
Combinations, features and attributes
PrestaShop separates attributes (which create combinations) from features (which are descriptive only). Shopify has options that create variants, and metafields for everything else. That sounds clean until you meet a catalogue where somebody used features for something shoppers filter on, or attributes for something that never should have created a combination.
Audit this before export. Every attribute that genuinely changes the thing being bought becomes a Shopify option. Everything else becomes a metafield, and your filtering is built on metafields rather than on variants. Getting this backwards produces either a variant explosion or a catalogue nobody can filter.
URLs and the redirect map
PrestaShop friendly URLs carry IDs — category paths like /12-category-name and product paths that vary with your route settings. None of that survives. Shopify uses /products/handle and /collections/handle, and no setting changes it.
So every indexed URL on every shop needs a 301 to its Shopify equivalent, and that redirect map has to be loaded before DNS moves. Once the domain resolves to Shopify, PrestaShop is not serving anything and cannot redirect anything. Pull sixteen months of Search Console data per domain, sort by clicks, and make sure the top of that list is mapped by hand rather than by pattern.
Multistore adds one more job: if two shops sold the same product on two domains, you had duplicate content that PrestaShop was not signalling well. Markets fixes that with hreflang and canonical handling, but only if the same product is one product with market variations rather than two products.
What does not come across
Be blunt with stakeholders about this list early:
- Multistore-only modules. Anything doing per-shop logic in PHP has no Shopify equivalent and has to be rebuilt as an app, a Shopify Function, or dropped.
- Customer passwords. Hashes never migrate to Shopify. Plan a reset campaign and expect a dip in logged-in sessions in the first fortnight.
- Order history as live orders. Imported orders are records. They are not refundable through the original gateway and they do not carry the payment relationship.
- Per-shop admin roles. Shopify staff permissions are store-wide within one store; per-market admin separation is not a thing on Markets.
The sequence that works
Decide the Markets-or-stores question first, on paper, with whoever owns each shop's P&L in the room. Then export and normalise the catalogue, including the attribute-versus-feature audit. Then build the market structure empty and confirm the pricing, tax and shipping behave per region before a single product is loaded. Then import products, then customers, then orders. Redirects go in before DNS. Nothing about that order is negotiable, and every project that has reordered it has paid for it.
If you are weighing Markets against expansion stores for a real catalogue, our Shopify migration page sets out how we scope this work, and a free audit will tell you which of your shops are genuinely separate and which are one store wearing three hats.