Engineers first. Everything verified.

Shopify2Shopify began as an internal toolkit built to migrate our own commerce brands between Shopify stores — with a hard rule the off-the-shelf tools couldn't meet: every run must be re-runnable, and a second run must change nothing. That idempotency rule is what makes migrations safe: it means we can prove completeness instead of promising it.

The toolkit grew until it covered everything Shopify's APIs expose — 21 entity types, from metaobjects to market price lists — and generated an honest checklist for the handful of things no API can move. Then we productized it.

How a migration actually runs

Every importer is an upsert keyed on a natural key — a handle, a SKU, an email, a namespace. That sounds like an implementation detail and it is the whole design: it means the migration can be run again safely. So we run it twice. The second pass has to create nothing, and the counts either match your source store or we have found a problem before you cut over rather than after.

Order matters more than speed. Files are uploaded before the metafields that reference them; locations exist before the shipping profiles and inventory that key off their names; markets exist before their catalogs. Get that sequence wrong and a store still looks migrated while the sections your theme renders from are silently empty — which is the failure mode behind most of the rescue jobs we get called into.

What makes us different

• The zero-created proof — every migration runs twice; the second pass must create nothing.
• Fixed pricing — your record count is a scheduling detail, not a billing meter.
• No passwords, ever — revocable API tokens, encrypted at rest.
• Named gaps — what can't move (gift card codes, app installs) is itemized, never hidden.

Talk to a migration engineer →