What would count as proof that a Shopify data migration worked? A progress bar reaching 100% shows that records were written. It does not show that a trade customer still carries their tax exemption, that a gift card holds the balance it had on Friday afternoon, or that last spring’s orders still point to the right customers. Those are separate questions, and an import log rarely answers them.
The reassuring part comes first: products, customers, historical orders, gift cards, store credit and content can all be brought into Shopify. What does not transfer is a narrower list with larger consequences, namely customer passwords, a few fields the CSV formats cannot carry, saved card details without a specialist process, and behaviour that existed only as logic in the old platform. Accuracy is verified by reconciling counts, totals, relationships and samples against the source at each stage.
What Transfers in a Shopify Data Migration, and How
Shopify’s own guide to migrating to Shopify lists the data that can be moved: products, customers, historical orders that have already been fulfilled, gift cards, certificates and store credits, blogs, and pages such as shipping or contact information. It also sets a sequence that matters for accuracy: orders are imported last, after the products and the customers, so that each order can attach to records already in place.
The routes run from manual copying and CSV files to App Store migration apps and custom migrations built on the Shopify API. Shopify notes that some data cannot move through CSV at all, so the method is often chosen per data type rather than once for the whole project.
| Data type | How it usually moves | What tends not to carry over | What verification should confirm |
|---|---|---|---|
| Products and variants | Product CSV, migration app or API | Variant metafields, bundles and reviews via CSV; legacy IDs | Counts per product type, prices, option values, images, inventory by location |
| Customers | Customer CSV, migration app or API | Passwords; consent evidence beyond a yes or no | Counts, marketing consent, tax-exempt flags, addresses, tags |
| Historical orders | Migration app or API only | Some discount detail; anything the old platform calculated on the fly | Order counts and revenue totals by period, links to customers and products |
| Gift cards and store credit | Migration app or API | The ability to correct a card once it is created | Number of active cards and total outstanding balance |
| Subscriptions | Subscription app plus a payment method migration | Wallet and bank account payment methods | Active contracts, next billing dates, payment method coverage |
| Content and URLs | Copy, CSV or app, plus a redirect map | The old URL structure itself | Page counts and a redirect test against the old URL list |
Products and customer data are high in volume but well supported by standard formats. Orders, balances and subscriptions are smaller, yet each carries money or a customer promise, so an error there is more likely to reach a customer or the finance team.
Products and Variants: Where Structure Changes Meaning
Product data usually transfers, but its structure may change on the way. Shopify’s product CSV documentation contains two details that matter for accuracy. When the overwrite option is used, a blank non-required column overwrites the matching value in Shopify with a blank. And changing option values deletes the existing variant IDs and creates new ones, which Shopify warns can break third-party dependencies, such as a product feed or ERP mapping keyed on those IDs.
Other boundaries follow. Images must sit at a public https address without password protection, which matters if the old store is about to be switched off. Variant metafields, bundles and reviews cannot travel in the product CSV, and its inventory column only suits single-location stores. Each gap needs a separate route or a deliberate decision to leave the data behind.
Identifiers are where many relationships quietly fail. BigCommerce’s ecommerce migration guide points out that fields such as customer IDs or variant SKUs may differ between platforms, which can lead to missing data or broken relationships. A practical safeguard is a crosswalk: a table recording each old ID next to its new Shopify ID for every product, variant, customer and order. It costs little to keep, and it tends to become the backbone of later reconciliation. Catalog hygiene before the move is a separate job, covered in our pre-launch catalog cleanup checklist.
Customer Data: The Records Move, Some Context Does Not
Most customer data imports reliably: names, emails, phones, addresses, notes, tags and tax-exempt status all have a place in the customer CSV. According to Shopify’s customer import documentation, credentials are the exception: passwords encrypted by another platform cannot be carried across in a CSV, so customers are invited to set up their accounts again. Where the store uses Shopify’s newer customer accounts, which sign people in with a one-time emailed code, the impact may be smaller, but the invitation still needs planning.
Marketing consent is easy to flatten during a move. The customer CSV accepts email, SMS and WhatsApp consent only as a yes or a no, which says whether a person is subscribed today but not when, where or how they opted in. Omnisend’s guide to GDPR for email marketing lists documenting consent among its compliance steps, so a business selling into the UK or EU may want to keep the original consent records, unsubscribes included, in an archive or the email platform. The exact legal requirement is a question for the business’s own advisers.
Two further limits are easy to overlook. Customer metafields in the CSV are restricted to a few simple types and must already be defined in the admin, and customer files are capped at 15 MB, so large volumes of customer data are split into batches that each need reconciling.
Historical Orders: Decide How Much History the Store Needs
Historical orders cannot be imported through the Shopify admin. They move through migration apps or the API, and Shopify’s developer documentation describes the orderCreate mutation as suited to importing orders from an external system. Its defaults fit a migration: inventory is bypassed, so an imported order does not reduce today’s stock, and customer confirmations stay off unless requested. Staff notifications differ, because each imported order can send a new order email to staff, so they are usually paused during the import.
One constraint matters before anyone promises an exact copy. The same documentation states that orderCreate does not support multiple discounts, such as line-item discounts, and allows one discount code per order. An old order that combined a promotion with a voucher needs a deliberate representation, for example discounted line prices, so that totals still reconcile with the source.
How far back to go is a business decision. Shopify’s Plus launch checklist recommends migrating, at minimum, the historical orders within the return policy window. Full history gives customer service and lifetime-value reporting a complete view, but adds import time, reconciliation effort and edge cases. Choose it when repeat-purchase analysis depends on it; choose a shorter window plus a searchable archive when older orders are mainly needed for occasional lookups.
Gift Cards, Store Credit and Subscriptions: Data With Money Attached
Outstanding gift card and store credit balances are liabilities, so an accountant is likely to check them after launch. Gift cards move through migration apps or Shopify’s API rather than CSV, and the Plus launch checklist adds that they can only be deactivated, not deleted, and that a card number cannot be reused. A batch imported early and corrected later can leave a trail of deactivated cards.
The safer pattern is usually to import balances close to cutover, once card sales on the old platform have stopped. Verification then compares the number of active cards and the total outstanding balance with the liability finance already reports.
Subscriptions add a payment layer. Shopify’s documentation on migrating payment methods states that moving saved card numbers requires the Plus or Enterprise plan, runs through Shopify Professional Services and a PCI-approved import flow, and excludes accelerated wallets and bank account details. For a subscription business, that can decide the timeline and even the plan, so it belongs in the first scoping conversation.
When the Source of Truth Is Not the Old Store
Some data is better not taken from the old store at all, because another system already owns it. WD Market’s Evelatus case study covers an electronics brand with stores across the Baltics whose catalog of 860,000 products was being managed manually: with no ERP integration, stock levels, prices, descriptions and images required constant manual updating. That project was a WooCommerce migration and rebuild, not a move to Shopify, and the case study presents the answer as ERP integration and full catalog automation.
The lesson carries across platforms. When an ERP or PIM is the authoritative source for products, prices or stock, copying those fields from the old storefront imports a second-hand version of them. The migration scope then shrinks to what the storefront genuinely owns, while the integration supplies the rest and keeps it correct after launch.
Internal expert input required: state how the Evelatus catalog was initially populated (from the ERP or from the legacy store), and add one verified example of a reconciliation issue found and fixed before a Shopify launch.
Other things stay behind because they were not stored as data in the first place:
- Pricing and promotion logic. Customer group prices and custom checkout rules are behaviour, not records, so they are rebuilt or retired and then tested rather than reconciled.
- App-held data. Reviews and loyalty points often live inside third-party apps and move through those apps’ own import tools.
- The old URL structure. Shopify uses its own URL patterns, so old addresses are preserved through a redirect map.
- Engagement history. Email engagement, support tickets and analytics usually stay in the systems that recorded them.
How Shopify Data Migration Accuracy Is Verified
Verification works best as controls that run at every stage rather than one inspection at the end. The idea is borrowed from finance: agree the figures before anything moves, then prove the destination matches them.
- Fix a baseline before extraction. Record counts and control totals from the source for each data type, such as products and variants, customers, orders and revenue by month, and outstanding gift card balance. Without a baseline, later checks can turn into a matter of opinion.
- Run a test load with awkward records. Include the difficult cases deliberately: products with many variants, partially refunded orders, part-used gift cards. Edge cases are where mapping errors tend to appear.
- Reconcile counts and totals after every load. Compare the destination with the baseline for each type. On large stores, Shopify’s bulk operation queries export data asynchronously as a JSONL file, which is far more practical than paging through records.
- Compare fields on a stratified sample. Check records from each category, segment and order period field by field, using the ID crosswalk to pair them.
- Test relationships, not just records. Confirm that orders link to the right customers and products, and that integrations keyed on IDs still find their records.
- Reconcile the delta and sign off at cutover. Import records created or changed since the main load, rerun the counts and totals, and have each data owner approve the figures before launch.
Key takeaway: a Shopify data migration is accurate when the business can show it, not when the tool reports that it has finished. Agree the baseline counts and control totals before extraction, and later checks have something objective to be measured against.
Reconciliation proves the data arrived intact; functional testing proves the store behaves correctly with it. Both are needed, and our Shopify migration QA checks cover the second half, from test orders to post-launch monitoring.
Choosing a Migration Method by Data Risk
An expensive method is not automatically safer. For a Shopify data migration, a CSV import is often enough when the catalog is modest, variants are simple and order history is short. It is transparent, cheap and easy to rerun, but orders and gift cards need another route.
A migration app tends to suit stores on a common source platform with standard data, because it handles orders and relationships that CSV cannot. The trade-off is less control over how unusual fields and discounts are mapped, so the test load matters more, not less. A custom API migration becomes appropriate with large volumes, custom fields, several source systems or strict accuracy requirements for orders and balances. It costs more, but mapping decisions are explicit and the delta can be rerun at cutover.
Many projects combine them. The deciding question for each data type is what an error would cost and who would notice it first.
Mistakes That Undermine Migration Accuracy
- Starting without a baseline. Without source counts and totals, the team can only check that the import looks plausible, a much weaker standard than proving it matches.
- Correcting option values after the first import. New variant IDs can silently disconnect feeds and integrations that were tested against the earlier ones.
- Treating consent as a single column. Discarding the original consent records can leave the business unable to show where a subscriber came from.
- Importing balances weeks before launch. Balances keep changing on the live store, so an early import leaves a gap that someone has to reconcile by hand.
Proving the Data Arrived Intact
Most store data can move to Shopify, and the reliable way to run a Shopify data migration is to treat accuracy as something demonstrated rather than assumed. Products, customers, historical orders and balances each need their own route and controls, while passwords, some CSV fields, saved payment details and platform logic need a separate plan or a deliberate decision to leave them behind. With a baseline, an ID crosswalk, reconciliation after each load and sign-off at cutover, the launch decision rests on evidence instead of a progress bar.
From Data Inventory to a Signed-Off Cutover
The first practical step is an inventory of the data the store holds, where each type lives and what would happen if it arrived wrong. WD Market’s Shopify migration services start there. The feasibility assessment sorts the store’s data and logic into what can move as it is, what should be replaced and what can be simplified, and the roadmap defines the data migration scope and sequencing: which data moves, in what order, and how the transfer is checked. For a store with a simple catalog and little order history, that review may simply confirm that a CSV or app-based import is enough.
If a specific platform, data volume or cutover window needs a second opinion, send us the details through the contact page, including the source platform and roughly which data types matter most. We also post shorter observations on replatforming, integrations and data quality on WD Market’s LinkedIn page.
Internal expert input required: if WD Market uses a standard reconciliation template or sign-off sheet on migration projects, describe it briefly here.
Shopify Data Migration Questions
Can customer passwords be migrated to Shopify?
No. The previous platform holds passwords in encrypted form, and Shopify cannot import them, so existing customers need a fresh start after the move. With classic accounts, they receive an invitation to choose a new password. With Shopify’s newer accounts, a code sent by email replaces the password altogether. Either way, the first email existing customers receive deserves careful timing and wording, because it is often their first contact with the new store.
How many historical orders are worth bringing across?
At a minimum, orders still inside the returns window, because they may still lead to refunds or exchanges. Beyond that, it depends on who uses the history. Customer service and repeat-purchase reporting benefit from a longer record, while finance usually relies on the ERP or accounting system for older transactions. A common compromise is a defined period in Shopify plus a searchable archive of everything older.
Will importing historical orders change stock levels or email customers?
Not by default when the import uses Shopify’s order creation API. Imported orders leave inventory untouched unless the import specifies otherwise, and customer confirmations are switched off unless they are requested. Staff alerts are the exception: anyone set up to receive new order notifications may get one email per imported order, so the import team normally disables those alerts for the duration of the load.
Can a Shopify data migration be rehearsed more than once before launch?
Yes, and rehearsals are one of the more effective ways to find mapping errors early. Products, customers and orders can be loaded into a test store, reconciled, corrected and loaded again, although Shopify limits order creation on development and trial stores to five orders per minute, so an order rehearsal often uses a sample. Gift cards are the exception worth planning around. Once created they cannot be removed or their numbers reused, so they are usually rehearsed in a separate test store and loaded into the live store only once, close to cutover.
Who should sign off that migrated data is correct?
Ideally, the people who own each type of data in the business rather than the team that ran the import. Finance is best placed to confirm gift card balances, store credit and revenue totals, operations to confirm stock and product data, and the ecommerce or CRM owner to confirm customer data and consent. Independent sign-off makes the launch decision more robust, because each owner checks the figures they will be accountable for afterwards.