Shopify to Shopify migration: merging stores, expansion stores and moving to Plus

A Shopify to Shopify migration is one of three projects: merging several Shopify stores into one, splitting one store into Shopify Plus expansion stores, or simply moving to Plus, which is a plan upgrade rather than a migration. The data is already in Shopify's format, so the risks are different: duplicated customers, apps and integrations that must be reconnected per store, and redirects between domains.

Moving to Shopify Plus: not a migration

Upgrading to Plus happens on your existing store. Products, customers, orders, themes and apps stay put. The work after upgrading is about using what Plus unlocks:

• checkout UI extensions on the information, shipping and payment steps (see Checkout UI extensions);
• custom apps containing Shopify Functions;
• Launchpad for scheduled events;
• the Plus-only parts of B2B: unlimited catalogs, direct catalog assignment, partial payments and deposits;
• expansion stores in your organization.

Merging stores into one

Common reasons: separate stores per country that Markets could now handle in one store, or a D2C store and a wholesale store that could be one store with B2B.

What to decide

• Surviving store: usually the one with the most history, apps and SEO.
• Catalog: are the products the same (merge by SKU) or different (copy across)? Resolve handle collisions before importing.
• Customers: merge by email. The same person may exist in both stores with different addresses and marketing consent. Keep the stricter consent status.
• Orders: history from the retired store can be imported as archived orders with the orderCreate mutation, without notifications or inventory changes, or kept in an export for reference.
• Markets: countries, currencies, languages and prices that the retired store served become Markets in the surviving store.
• B2B: wholesale customers become companies with catalogs and payment terms.

What to redirect

The retired store's domain points to the surviving store, and each of its URLs redirects to the matching product, collection or page. Because both stores use the same URL structure, the mapping is mostly by handle, plus a check for renamed handles.

Splitting into expansion stores

Separate stores make sense when regions or business units need different catalogs, legal entities, pricing strategies, apps or teams. When creating an expansion store in a Plus organization, Shopify lets you import products, variants, their metafields and files from an existing store.

What still needs work:

• apps: each store installs and configures its own apps. A custom app can be installed on every store in the organization;
• integrations: ERP, accounting and 3PL connections per store, often with a store-level field on each record;
• ongoing sync: if products stay shared, you need a sync, from a PIM or ERP or from a primary store, rather than a one-off copy;
• reporting: consolidated sales across stores;
• customers: accounts are per store.

Custom apps across several stores

The right way to run shared logic across stores is one custom app deployed to each store in your organization, with per-store configuration in metafields: the same Functions, checkout extensions and integration code everywhere, and one codebase to maintain. It is far easier than copying code or maintaining separate apps.

Keeping several stores in sync

If you choose several stores, decide how shared data stays consistent after the initial copy:

A sync between stores is a small integration in its own right: products are matched by SKU or a shared metafield, changes flow from webhooks, and a nightly comparison catches drift.

Worked example: merging a wholesale store into the main store

A merchant runs a D2C store and a separate wholesale store with a tag-based wholesale app. Merging them:

1. Wholesale customers become companies with locations and contacts in the main store.
2. Wholesale prices become B2B catalogs. With a few price levels this fits within non-Plus limits. Per-customer prices need Plus.
3. Wholesale minimums become quantity rules, or a validation Function.
4. Net terms become payment terms on each company location.
5. The wholesale store's domain redirects to the main store. Buyers sign in with their email and see their prices.
6. The ERP integration is pointed at one store instead of two, with B2B orders identified by their company.

Step-by-step plan

1. Decide the target structure: one store with Markets, or several stores.
2. Inventory products, customers, orders, apps, integrations, content, domains and URLs in each store.
3. Resolve conflicts: duplicate handles, SKUs and customers.
4. Copy or sync the catalog. Import customers with merged consent.
5. Import order history if needed, without notifications.
6. Install and configure apps. Reconnect integrations.
7. Set up domain and URL redirects.
8. Test orders per market and customer type, then switch.

Pre-launch checklist

• No duplicate products or customers after the merge.
• Marketing consent is correct for merged customers.
• Every retired URL redirects to its match in the surviving store.
• Apps and integrations are configured in every store that needs them.
• Imported orders didn't send emails or change stock.
• Reporting still gives a consolidated view.