What to migrate to Shopify — and what to leave behind

Every migration kickoff starts with the same question: how much of our old store can we bring across? It sounds like a capacity question, but it is really a question about purpose. Before anything is exported, every group of records should be assigned a job for after launch — support lookups, returns and warranty, subscription continuity, finance reconciliation, or email segmentation. If a set of records has no job after cutover, it should not become live data by default.

That reframing matters because Shopify will accept a lot, and accepting a lot is not the same as moving well. Old orders with incomplete line items, records tied to products you are retiring, and years of custom fields from plugins nobody remembers are noise. Clean data the team trusts beats a complete import nobody can read. The rest belongs in an archive with a documented lookup path, not in the admin.

Products, variants, images, collections, and metafields come across well, whether through Shopify's CSV tools or a migration app that carries metafields natively. Customer records are just as cooperative: names, emails, phone numbers, addresses, tags, and marketing consent all import in one pass. Keep the consent flag honest — Shopify respects it, and your customers will notice if you do not. One plain email before cutover, explaining that the site is moving and that their history comes with them, removes most of the anxiety.

The exception is passwords. Shopify does not export or transfer password hashes, and that holds true even between two Shopify stores. Every migrated customer will need to set a new password, or log in with a passcode if you run the newer customer accounts. Fold that reset into the launch communication, test the full login journey on a staging store first, and brief your support team on what to say. It is the most predictable source of day-one tickets.

This is the step most merchants assume is a checkbox, and it is not. Shopify has a native importer for products and customers; it has no general-purpose 'import orders from CSV' button for arbitrary historical orders. An order in Shopify is tied to a payment transaction, a fulfillment status, and tax calculation, so historical orders are recreated rather than restored. In practice there are three routes: Shopify's Store Importer, which supports a set list of source platforms and only inside a brand-new store's setup window; the Admin API Order resource, where a developer script creates the records; or a specialist migration app.

Whichever route you take, sequence decides whether the result is usable. Shopify's own guidance is to import historical orders after products and customers, so each order connects to the right product and the right customer identity. Import orders first and you split repeat buyers across old and new records. Ask the import to suppress order and shipping confirmation emails for these old orders — nobody wants a shipping notice for something that arrived in 2022.

And decide deliberately how far back to go. Recent orders that support returns, warranty, loyalty tiers, or B2B reorder context belong in Shopify. Very old, incomplete, or reporting-only history is usually better archived outside the admin, where it can still answer a finance question without cluttering daily work.

Subscriptions are where migrations get expensive, so scope them first. The subscription itself — who, what, how often — moves as data. The stored payment method does not, because card tokens belong to the processor that took the original charge and do not travel to a new one. That single fact sets the plan: import the customer records and plan details, set the contracts up in your subscription app, then send each subscriber a link to add a card.

Established subscription platforms run this as a defined process. Recharge and Appstle both migrate contracts and payment methods, and both keep migrated subscriptions paused until you have reviewed them and confirmed the data — precisely so a subscriber is never charged twice during the overlap. Make the email warm and specific, give subscribers a small reason to act now, and follow up once. The customers you lose are the ones who first hear about the move in a failed-charge notice.

Two related balances to check separately: gift cards and store credit. Balances move, but codes are conditional — Shopify Plus can create a card with a specified code by API, while other plans issue new codes and notify the customer. Loyalty points and reviews live inside their own apps, so export from the old app and import into the new install; they will not arrive with the store data.

A migration is a sequence, not a switch. Freeze edits on the old store, run the delta import for anything created since the full run, protect the old store so nobody buys on it, upload the redirect map, then point the domain. Keep the old platform open and read-only for a month — you will look something up. Two quiet traps are worth handling early: order numbers collide when two stores both start at the same figure, so offset one range and preserve the original number in a metafield; and imported historical orders can surface to customers through the Shop app, so disable that channel during the order import and re-enable it at launch.

Then judge the migration by what still works, not by how many rows landed. Can support look up a customer's last order without leaving Shopify? Can a customer log in and see a coherent account? Do your email segments and purchase-based flows still fire? Is a refund or a warranty claim a two-minute lookup or a scavenger hunt? Watch those questions for the first quarter, alongside the redirect and ranking checks.

A migration is finished when the team stops keeping one foot in the old system. If people are still opening the legacy admin six weeks in, something that mattered did not move.