What actually gets migrated
Beyond the obvious product catalog, a full data migration typically covers customer accounts and their order history, existing orders (open and historical), content like blog posts or static pages, reviews if they're stored on-platform, and any custom fields or metadata specific to your business. Not everything necessarily needs to move - some historical data may be archived rather than actively migrated, which is a scoping decision made during the assessment, not assumed by default.
Why a straight export/import isn't enough
Two platforms rarely model data identically - one platform's flat product list might be another's hierarchical categories-and-attributes system; one platform's simple customer record might need to be split across several object types on the new platform. A literal field-by-field copy from an export file often produces data that's technically present but structurally wrong - broken variant relationships, lost custom fields, or customer records that don't link correctly to their order history. Real data migration means mapping each data type deliberately, not just moving files.
How we approach it
We start with a data audit - understanding what actually exists in the old system, including inconsistencies that built up over time (duplicate customers, orphaned records, inconsistent categorization) - before deciding how it maps onto the new platform. Cleanup often happens as part of this step rather than after, since migrating bad data faithfully just reproduces the same problems on the new platform. See Data Cleanup & Mapping for how this fits into a managed migration.
Frequently asked questions
Does data migration include my order history?
It can - whether historical orders are actively migrated into the new platform or archived separately is a scoping decision, since not every platform or business needs live order history in the new system. We discuss this during the assessment.
Will my custom fields transfer automatically?
Not automatically - custom fields need an explicit equivalent on the new platform (often metafields or custom attributes), and that mapping has to be defined, not assumed to exist by default.
Can I migrate data myself using a plugin or import tool?
For small, simple catalogs this can work. For stores with meaningful customization, order history, or data quality issues, a generic import tool typically can't make the judgment calls a proper data audit and mapping process requires - it just moves whatever's in the file, mistakes included.
How do you avoid data loss during migration?
By auditing and mapping before moving anything, testing the migration against a staging environment first, and verifying record counts and spot-checking data after the move rather than assuming the import ran correctly.