Multi-store governance on Shopify Plus

Start with the honest inventory, because a lot of multi-store planning assumes a level of central control that does not exist.

It gives you people. Organisation settings let you view and manage multiple stores from one place, administer users across them with role-based access, and — the part worth building a process around — create custom user groups that assign many users to a permission set in bulk. Combined with unlimited staff accounts, that means there is no financial reason to share logins, which removes the single most common access-control failure in a multi-store estate.

It gives you money and measurement. Billing information for every store in the organisation is visible in one place, and reporting spans the estate rather than stopping at each store boundary. That is enough to answer "what does this cost" and "how is region three doing" without a spreadsheet.

It does not give you sameness. Theme code, section settings, metafield definitions, product data, discount configuration, app installation and app configuration are per store. Nothing in the platform notices that store four is running a theme from eighteen months ago, or that "material" is a metafield on three stores and a tag on the other two. That is the drift that makes multi-store expensive, and there is no setting for it.

One cost correction while we are here, because it catches people out at budget time: the Plus plan includes nine expansion stores at no additional monthly cost, and Shopify documents that each live expansion store needs its own theme license. App charges are also made against a store, so an app your business depends on becomes a line item on every store that installs it. "No additional monthly cost" is about the plan fee, not about the estate.

This is the exercise that makes the difference, and it takes an afternoon with the right five people in the room. Take every category of thing that can be changed in a store, and assign it one of three labels. Write the result down somewhere people will find it.

Global means identical everywhere and changed in one place. Theme code, metafield definitions, the product taxonomy, checkout configuration, brand assets, the legal pages that are the same in every market. If someone can change a global artefact in a single store admin, it is not global — it is a convention, and conventions lose.

Regional means set by a region and consistent within it. Payment methods, delivery promises, tax treatment, the languages offered, the customer service hours in the footer. The person who owns a region owns these, and nobody outside it edits them.

Local means the store owns it outright and no one should try to standardise it. Campaign pages, local merchandising, homepage sequencing for a local season, the assortment where it genuinely diverges. Trying to centralise this is how head office ends up as a bottleneck for a sale that starts on Friday.

The classification matters more than the tooling you pick to enforce it, because the argument it settles — "can we just change this here?" — is the argument that produces drift. Most estates we audit have never had it, and the evidence is always visible in the theme: five stores whose sections folders diverged, not by design, but one urgent fix at a time.

Theme drift is annoying. Data drift is what breaks reporting, integrations and every project that arrives two years later.

Metafield definitions are the clearest case. If custom.material is a single-line text field on one store and a metaobject reference on another, then any integration, feed or template that reads it needs per-store handling for the rest of its life. Define them centrally, create them by API rather than by hand, and treat a definition change as a release rather than an admin task. The same argument applies to product taxonomy, tag vocabularies and the attributes your feeds depend on.

Product data itself usually wants a source outside Shopify once you pass two or three stores — a PIM, an ERP, or something more modest that nonetheless holds the canonical record. The rule to insist on is that the canonical field is edited in one system and syndicated, and that stores can add local fields but never override global ones. Without that, the question "what is this product's description" has several answers and no way to pick.

Customers and orders are the opposite case, and people get this backwards. Those records are genuinely per store — separate customer accounts, separate order sequences — and trying to unify them inside Shopify is a losing fight. Unify them downstream in a warehouse where a person who bought in two regions can be recognised as one person for reporting, and leave the stores alone.

Every estate eventually acquires a store whose purpose nobody can quite explain: a market test from three years ago, a pop-up for a collaboration, a store built for a wholesale programme that moved elsewhere. It still has customer data, it still has an SSL certificate to renew, it still shows up in search results, and it is still a way into your organisation.

Two habits fix most of this. First, name an owner for every store — a person, not a department — and review the list quarterly. A store without an owner is a store to close or to fold back into another. Second, run access through custom user groups rather than individual grants, so that a leaver is removed once rather than ten times and an audit is something you can produce in an afternoon.

Add to that a simple rule about API credentials: they belong to a service, are documented per store, and are rotated when the person who created them leaves. The most common security finding in a multi-store estate is not a vulnerability, it is a private app token created by a contractor in 2023 that still works.

The most useful outcome of a governance review is often a shorter list of stores. Shopify Markets covers per-market pricing, currency, catalogue availability and domains from one storefront, and it has kept absorbing reasons that used to justify a separate store. Meanwhile Shopify documents support for up to 200 locations, so multi-warehouse operations on their own almost never require a second store.

What still genuinely justifies one is a different catalogue, a different legal entity or a different fulfilment model — the same short list as when you first decided. Everything else is a store you are paying for in theme licenses, app subscriptions, deployment time and drift. If a store on your list cannot be defended against that test, consolidating it back is not a retreat; it is the cheapest performance improvement available to you, because every future change gets faster for the ones that remain.

We would rather build you four stores that stay in step than nine that do not. The governance work is what makes that a choice rather than an accident.

• Shopify Markets and international rollout
• Shopify Markets or a store per country?
• Product data governance: who is allowed to change what