Consolidation, ownership transfer and market restructures. The catalogue moves easily; metafields, application data, subscriptions and payment history do not.
Which is exactly why these projects get underestimated.
Moving products, customers and orders between two Shopify stores is well-trodden. The reason a store-to-store project takes real work is that almost nothing else transfers as cleanly, and the expectation set by the catalogue is misleading.
Metafields and metaobjects are the first. The values can be moved, but the definitions, their structure and everything in the theme that reads them have to be recreated deliberately. A store with a mature metafield model has a genuine content architecture, and moving it is a modelling exercise.
Application data is the second. Reviews, loyalty, subscriptions, bundles and product configurators hold their data in the application rather than in Shopify. Each one has to be treated as its own small migration, and some of them, subscriptions especially, cannot carry stored payment methods to a new store at all.
The third is the reason for the move. Consolidating several stores into one, splitting one into markets, transferring ownership after an acquisition and rebuilding on a different plan are four different projects with the same summary. What has to survive differs in each case.
Same platform does not mean same behaviour.
| Entity | Normally transfers | Where a decision is needed |
|---|---|---|
| Products and variants | Yes, cleanly | Handle collisions when two catalogues merge into one store |
| Collections | Yes | Automated collection rules that depend on tags or metafields being recreated first |
| Metafield values | Yes, once the definitions exist on the destination | Definitions, types and validations have to be rebuilt deliberately |
| Metaobjects | With planning | References between metaobjects, which need recreating in the right order |
| Customers | Yes, without passwords | Merging duplicate customers where two stores shared buyers |
| Orders | As historical records | How much history to bring, and how refunds are represented |
| Discount codes | Rules recreated rather than copied | Live campaigns that must not break at cutover |
| Application data | Per application, and not always | Reviews usually import; loyalty balances and subscriptions usually do not |
Payments, payouts and financial history belong to the store that took the orders. They stay there, and the accounting treatment of the split is worth agreeing with your accountant early.
None of them appear in a catalogue export.
Subscription contracts are bound to the store and the payment provider that created them. They do not move to a new store, so existing subscribers have to be re-established with their consent. That is a customer communication project as much as a technical one.
Every application has to be installed, configured and, where supported, populated with its historical data. Configuration is rarely exportable, so this is manual work proportional to how many applications the store runs.
Where the move exists to restructure markets, the destination architecture has to be decided first: one store with markets, separate expansion stores, or a mixture. Domains, currencies, tax and localised content all follow that decision.
On an acquisition or a separation, the account, billing, domains, payment provider, applications and staff access all need transferring properly. It is administrative rather than technical, and it is where these projects most often stall.
Plan the applications and the subscriptions before the catalogue.
Handles usually survive. Domains and collection paths are the risk.
A store-to-store move can preserve most routes exactly, which makes the exceptions the entire job.
Where a domain is being retired, it needs to stay registered and serving redirects long enough for the link equity to transfer. Letting it lapse is the most common self-inflicted loss in these projects.
Same platform, same operational risk as any other replatform.
Swipe the parts
Design
A theme can be copied between stores, but its settings, content and metafield references cannot come with it unaided. Copying and then repairing is often slower than implementing deliberately.
Systems
Every integration points at a specific store’s API. Credentials, webhooks and endpoints all change, and each connected system needs updating on a coordinated schedule.
Proof
Metafield-driven content is where errors hide, because a missing definition produces a blank space rather than an error. Validation targets that specifically.
Switch
A delta run, a coordinated domain switch, and the source store kept on a reduced plan while it serves redirects and remains the rollback.
Applications, metafields and structure. Rarely the catalogue.
A store-to-store project is priced from everything that is not a product.
Consolidations, subscription businesses and market restructures route to manual scoping. The estimator is built for a single-source move, not for a portfolio decision.
Published starting figures in GBP and USD, excluding VAT.
Scoped after reviewing both stores
Data only
From £1,000From $1,300
Products, customers, orders and content mapped into a Shopify store that already exists or is priced separately. Fixed once source access and a sample migration are reviewed.
Starting price · scoped after discovery
Migration and build
From £5,000From $6,500
Moving to Shopify and building the store in one project, so the data and the storefront land together rather than in two disconnected pieces of work.
Starting price
Plus, B2B, multi-market
From £8,000From $10,500
Shopify Plus, B2B, multi-market, multi-language, custom integrations or headless work. These configurations are sized after discovery, not instant-priced.
Starting price · scoped after discovery
Both stores are reviewed before a fixed scope, because the destination’s existing configuration matters as much as the source’s data.
Where the requirement is only a change of ownership, transferring the existing store is usually simpler and cheaper than migrating. Migration is the right answer when catalogues are merging, the market structure is changing or the destination store already exists.
Subscription contracts are tied to the store and the payment provider that created them, so they do not transfer. Subscribers have to be re-established with their consent, which makes this a customer communication project first and a data project second.
The values move once the definitions exist on the destination. The definitions, their types and validations, and every place in the theme that reads them have to be recreated deliberately. On a store with a mature metafield model this is a substantial part of the work.
It should stay registered and serving one-hop redirects for a good while after the move. Letting it lapse discards the link equity the business paid to build, and it is the most common avoidable loss in a store consolidation.
Consolidation, ownership change and a market restructure are three different projects behind the same sentence.
