What can and cannot be copied between Shopify stores
Shopify has no native way to clone a store. Every tool that offers one, ours included, is working through the same Admin API — so the interesting question is not which app copies the most, it is what the API refuses to write at all. This page answers that resource by resource.
These rows are read from the engine that runs the copies, not written by hand, so this page cannot claim something the product does not do. Each limit is given twice: what it means for you, and the API behaviour that causes it.
- 1Copies in full
- 12Copies, with a caveat
Resource by resource
Products
Copies, with a caveat
It moves, but something is lost or reshaped. What that is, is named.
Files are created from the source URL; the destination assigns its own CDN URLs. Anything referencing an old URL — theme code, metafield values, external links — needs rewriting.
Media is copied by handing the destination the source's own URL, and `FileSetInput.originalSource` says videos and 3D models require a staged upload instead — which means moving the bytes through us, and is not built. Externally hosted video is not carried across either: Shopify would accept its URL, but nothing in this version reads the embed. The alternative was worse and was what this app used to do: every media item was serialized from its preview image, so a video arrived as its poster frame and was reported as copied.
A media item that has not finished processing exposes no URL at all, and `productSet` rejects a file entry without an `originalSource` — which fails the whole product rather than the one image. Omitting it is what keeps the rest of the product copying.
A publication only exists if the corresponding channel app is installed. Channels the destination lacks are reported as skipped rather than silently dropped.
Shopify's replace semantics would delete every custom field not in our list — including ones belonging to other apps installed on the destination. Leaving a stale field behind is recoverable; deleting another app's configuration is not.
Collections
Copies, with a caveat
It moves, but something is lost or reshaped. What that is, is named.
Membership is derived by Shopify from the rules, so results legitimately differ if the destination's products differ.
Shopify's replace semantics would delete every custom field not in our list — including ones belonging to other apps installed on the destination. Leaving a stale field behind is recoverable; deleting another app's configuration is not.
Files
Copies, with a caveat
It moves, but something is lost or reshaped. What that is, is named.
Files are created from the source URL; the destination assigns its own CDN URLs. Anything referencing an old URL — theme code, metafield values, external links — needs rewriting.
`fileCreate` fetches `originalSource` server-side rather than receiving bytes. Copying from a store that has closed, or from an archive whose store has moved on, creates files the destination cannot fetch — which is the concrete version of "an archive is not a standalone backup".
Locations
Copies, with a caveat
It moves, but something is lost or reshaped. What that is, is named.
`locationAdd` has no field for activation state, so there is no way to create one already deactivated. Deactivate it on the destination afterwards if that matters.
Shopify creates that location for the fulfillment app when it installs, and only that app can create one. `locationAdd` would make an ordinary location carrying the same name and nothing behind it — which is worse than skipping, because the inventory copy would then write real stock into it and every count would look right.
Pages
Copies, with a caveat
It moves, but something is lost or reshaped. What that is, is named.
Shopify's replace semantics would delete every custom field not in our list — including ones belonging to other apps installed on the destination. Leaving a stale field behind is recoverable; deleting another app's configuration is not.
Blogs
Copies, with a caveat
It moves, but something is lost or reshaped. What that is, is named.
Shopify's replace semantics would delete every custom field not in our list — including ones belonging to other apps installed on the destination. Leaving a stale field behind is recoverable; deleting another app's configuration is not.
Articles
Copies, with a caveat
It moves, but something is lost or reshaped. What that is, is named.
The author can be given as a name or as a staff `userId`, and a staff id from one store means nothing in another. The name travels; the account link does not.
The image is a separate upload with its own CDN URL on the destination, and this version does not re-upload it. The article arrives without it.
Shopify's replace semantics would delete every custom field not in our list — including ones belonging to other apps installed on the destination. Leaving a stale field behind is recoverable; deleting another app's configuration is not.
URL redirects
Copies in full
Readable and writable. A faithful copy is achievable.
Metafield definitions
Copies, with a caveat
It moves, but something is lost or reshaped. What that is, is named.
Definitions in the `shopify` namespace are Shopify's category metafields, tied to the Standard Product Taxonomy, and no app may create them whatever scopes it holds. The product's category is copied, which is the part an app controls; the fields themselves are Shopify's, and where the destination does not already have them they have to be added from its admin.
Namespaces like `descriptors`, `facts` and `reviews` are reserved for definitions Shopify has already designed, so `metafieldDefinitionCreate` refuses them. They are switched on with `standardMetafieldDefinitionEnable` instead, and Shopify keeps ownership of their shape - name, description and validations stay as Shopify defines them rather than as the source store had them.
Metaobject definitions
Copies, with a caveat
It moves, but something is lost or reshaped. What that is, is named.
A definition whose type is prefixed `$app:` is reserved to the app that created it, so no other app can recreate it.
Metaobjects
Copies, with a caveat
It moves, but something is lost or reshaped. What that is, is named.
A definition whose type is prefixed `$app:` is reserved to the app that created it, so no other app can recreate it.
A field whose value is a reference — or a list of them — has a knowable position to rewrite, and those are remapped. A reference embedded in free-form JSON or rich text does not: nothing in the value says which of its strings are ids, and rewriting by pattern would corrupt the field. Leaving it untouched is the recoverable failure; a mangled value is not.
Navigation menus
Copies, with a caveat
It moves, but something is lost or reshaped. What that is, is named.
Those resources are created by Shopify and cannot be recreated by an app, so their links cannot be repointed. Replacing the destination's working menu with one whose links go nowhere would be worse than not copying it.
Inventory levels
Copies, with a caveat
It moves, but something is lost or reshaped. What that is, is named.
Inventory writes are compare-and-set; a concurrent order can change the quantity between read and write.
Shopify generates the adjustment ledger from our writes; it cannot be authored. A restored store shows the restore, not the original history.
Shopify creates that location for the fulfillment app when it installs, and only that app can create it — `locationAdd` makes an ordinary location, which would be a warehouse with nothing behind it. There is no safe fallback either: an inventory item held at a fulfillment service location cannot be stocked anywhere else at the same time, so moving it to another location is a different answer, not a gentler one. Installing the same fulfillment app on the destination is the real fix: Shopify creates the location there, and HyperSync matches it by name.
What no app can copy, ours included
These are not gaps in our engine. They are things the Admin API does not expose or does not let anything write, so every tool in this category has the same answer — whether or not it says so before you buy.
Inventory adjustment history
Shopify generates the adjustment ledger from writes; it cannot be authored. A restored store shows the restore, not the original history.
Customer passwords
Never exposed by the API. Customers moved to another store have to reset.
Gift card codes
Codes cannot be read back out of a store once issued.
Original order and customer dates
The creation date cannot be set on an order, a draft order or a customer, so copies date to the day they were copied rather than to the original.
Orders older than 60 days
Readable only with Shopify's approved access to all orders, which is granted per app and per use case.
Payment and gateway history
A refund record can be recreated; the money movement behind it cannot.
If this is the workflow you have
HyperSync copies these resources between two Shopify stores you control — clone production into a staging store, work there, copy back what you want to keep. It runs as a background job that survives a closed tab, and re-running it updates what is already there instead of creating duplicates.