Ecommerce Data Migration: How to Move Products, Customers and Orders

Ecommerce data migration moves products, customers, orders and content to a new platform without losing meaning or relationships. Extract data from the old system, map every field to the new model, transform and clean it (formats, duplicates, invalid values), load into a staging store, and validate with counts, totals, samples and journey tests. Migrate products, then customers, then orders. Rehearse the full run more than once, run a delta migration close to launch, and keep the old system ready for rollback.

Data problems are among the most common causes of migration trouble: missing variants, broken images, customers who can't sign in, orders that don't show in accounts, duplicated customers, wrong prices. Most are preventable with mapping, validation and rehearsal. This article covers the data side. For the overall plan, see ecommerce migration strategy and migration checklist.

Export complete data from the old system through APIs, database exports or export tools. Include IDs and relationships (which customer placed which order, which variant belongs to which product). Keep the raw exports unchanged for reference and repeat runs. Check that exports include everything: some export tools omit custom fields, metafields or inactive products.

Write a field mapping document: every source field, its destination, transformation rules and default values. Resolve model differences: a platform with unlimited variants moving to one with limits, custom attributes moving to metafields, category trees moving to collections. Decide what won't be migrated and why.

Migration is a chance to fix data, but keep changes controlled. Normalize formats (phone numbers, country codes, dates), deduplicate customers and products with documented matching rules, fix encoding problems, fill required fields, and flag invalid records for review rather than silently dropping them. Use scripts rather than manual edits so runs are repeatable.

Load into a staging or development store first. Order matters because records reference each other: products first, then customers, then orders. Shopify's migration guidance, for example, recommends importing products, then customers, then historical orders (Shopify Help Center). Record old-to-new ID mappings as you load; you'll need them for orders, redirects and integrations.

Validation proves the migration worked. Compare counts by type, sums (order totals, inventory), and random and edge-case samples between old and new systems. Check relationships: orders attached to the right customers, variants to the right products. Then test journeys with migrated data: sign in as a migrated customer, view order history, reorder, buy a migrated product.

Customer passwords are normally stored as one-way hashes that can't be converted for another platform, so customers can't sign in with old passwords after migration. Plan how they'll regain access: account activation emails, a password reset prompt at first sign-in, or passwordless sign-in where the platform supports it. Preserve marketing consent status and dates exactly. Customer data is personal data, so handle exports securely and delete temporary copies afterwards. See ecommerce privacy.

Historical orders support service, returns and reorders; migrate enough history to cover return windows and customer expectations, and archive older data in a warehouse if needed. Saved cards and subscription payment methods can't usually be exported as data; they're moved between payment providers under the providers' processes, which take time. Start that conversation early. See subscription ecommerce.

Run the full migration into staging at least twice before launch, timing each run and fixing issues between them. Close to launch, take a final full migration, then a delta migration of records created or changed since, during a short freeze. Timing rehearsals tell you how long the launch window needs to be. See migration launch plan.

Keep the old platform intact and able to take orders until the new one is confirmed. Define the point after which rolling back becomes harder (for example after new orders are taken on the new platform) and how orders taken in the new system would be moved back if needed. See parallel runs.

Options range from platform import tools and CSV files to migration apps, integration platforms and custom scripts using APIs. Shopify's guidance lists manual entry, CSV imports, migration apps, Shopify Partners and custom API work as approaches. Choose by data volume, complexity (variants, metafields, order history) and how many rehearsals you need; repeatable scripts or tools beat manual imports for anything beyond small catalogs.

An illustrative scenario, not a client case: a store migrating 8,000 products finds that its export tool omits custom attributes and inactive variants. The team switches to API-based extraction, maps attributes to metafields, writes transformation scripts, loads into a development store twice with validation reports, then runs a final full load and a delta for the last day's orders during a short freeze.

Data migration succeeds through mapping, repeatable transformation, ordered loading, thorough validation, rehearsals and a delta run at launch, with the old system kept ready for rollback. Related: migration testing and legacy ecommerce migration.