Platform-Agnostic Data Migration: The ETL Method

Data migration to Shopify is an extract-transform-load problem, not a platform-expertise problem. The same method applies whether you're moving from Magento, BigCommerce, Salesforce Commerce Cloud, WooCommerce, or something custom-built. Here is the method, and why it doesn't change based on where you're coming from.

Last verified: September 6, 2026.

Why platform-agnostic isn't a hedge

Competing migration content treats data migration as a platform-specific skill — "Magento data migration" as though it required fundamentally different expertise from "BigCommerce data migration." It doesn't. Every migration is the same three-step problem: extract the data from wherever it lives, transform it into the shape Shopify expects, and load it in with verified parity. The origin platform determines where you extract from. It does not determine how the rest of the method works.

This matters commercially, not just intellectually. If the method is genuinely portable, then a partner's track record on your specific origin platform is a much weaker signal than their ability to describe the method itself — which is the argument this whole series is built on.

Extract

Identify the true source of truth for each data category: order history, customer records (including saved addresses and payment method references), product catalog (pricing, variants, custom attributes), and any custom fields specific to your business. On some platforms all of this lives in one place. On others — especially custom-built systems — it's spread across several systems that each need their own extraction plan.

The word doing the work there is true. It's common to find that the platform's copy of a record is not authoritative: the ERP holds the real inventory position, the OMS holds the real fulfillment status, and the storefront database holds a cached view of both that is occasionally stale. Extracting the cached view and calling it migrated is a failure that only surfaces after launch, when the numbers stop agreeing with the systems that never moved.

Extraction mechanics are the one genuinely platform-specific part of this method — which API or export tool a platform provides, and what its native structures look like. That's real, necessary knowledge. It is also narrow and mechanical, not the deep platform mastery most merchants assume they need to evaluate in a partner.

Transform

This is where platform-specific quirks actually show up, and even here the work is mechanical rather than expert: mapping the old data's structure — category taxonomy, variant relationships, custom field formats — into Shopify's data model.

Transform is also where the custom-to-custom trap creeps into data migration specifically. A team maps old category structures into Shopify collections in a way that faithfully replicates the old taxonomy, rather than asking whether Shopify's native collection and metafield model would represent the same information more simply. The data moves either way. The difference shows up months later, in whether the resulting structure is easy or painful to maintain, and in whether anyone can find anything in it. See the full audit for why this instinct is so persistent.

A short list of decisions that reliably need making explicitly rather than by default:

• Category taxonomy — which parts become collections, which become product types, and which become metafields. A one-to-one port of a deep legacy tree is almost never the right answer.
• Variant relationships — Shopify's option and variant model has real limits, and a catalog built around a more permissive model needs a deliberate mapping rather than a mechanical one.
• Custom attributes — metafields are the destination for most of these, but the decision of which ones earn a definition (and which are dead columns nobody has read in years) belongs in the transform step, not after launch.
• Customer identity — how accounts, addresses, and any loyalty or subscription status resolve, and what happens to records that are duplicated or orphaned in the source.
• Order history depth — how far back you actually need, since the honest answer is often shorter than the instinct and materially changes the timeline.

Load

Load into Shopify with systematic parity testing — field-by-field verification on a statistically meaningful sample, not a comparison of record counts.

A count match with individual-record discrepancies is the most common false-confidence trap in data migration. Totals can agree while individual records are subtly wrong in ways that surface later, usually when a customer disputes an order or a finance team reconciles a month that no longer adds up. The reconciliation discipline is covered end to end in data parity testing; the short version is that the check has to be at the field level, on records chosen at random rather than chosen because they're easy.

Load in batches, verify at each stage, and keep the source system readable until parity is signed off. A migration that has already decommissioned its source has no way to answer the first question anyone asks when a number looks wrong.

A concrete walkthrough: migrating customer records

Extract every customer record from the source system, including order history references, saved addresses, and any loyalty or subscription status. Transform each field into Shopify's customer data model — this is usually where address formatting, custom tags, and non-standard fields need explicit mapping decisions rather than a straight copy. Load in batches with verification at each stage, checking a sample of records field by field: does the address match, does the order history reference resolve, does a loyalty tier show the right value.

Then repeat the same three-step discipline for product catalog and order history, adjusting only the specific fields being verified. The shape of the work does not change between categories, which is exactly the point — a team that has done it once on customers can do it on orders without inventing a new process.

Why the transform step is where projects actually go wrong

Extraction is usually mechanical: export the data, confirm it's complete. Loading is also mostly mechanical, provided transform produced clean, correctly mapped data. Transform is where judgment calls happen, and judgment calls made under timeline pressure default to whatever requires the least thought — which is almost always a faithful copy of the old structure.

The tell is a transform spec that reads as a field-mapping table with no rationale column. A table says what moved where. It doesn't say why the old shape was or wasn't preserved, which means nobody can revisit the decision later without redoing the analysis from scratch.

What parity testing actually looks like

Parity testing is the step most often described and least often specified, so it's worth being concrete about what a real one involves.

• A sample chosen at random, not chosen for convenience. Records picked because they're easy to look up are systematically the simple ones, and simple records are not where transform bugs live.
• A named field list per record type. "We checked the orders" is not a test. "We checked total, tax, discount, line items, shipping address, fulfillment status and financial status on 500 randomly sampled orders" is.
• Deliberate inclusion of the awkward records. Multi-currency orders, partially refunded orders, orders with a discontinued product, customers with several addresses, products with the maximum number of variants. These are the ones that break, and a random sample of a large catalog may not contain enough of them.
• A written sign-off with a date and a name. Parity that nobody signed is parity nobody owns, which becomes obvious the first time a number is questioned after launch.

The discipline generalizes past migration — it is the same reconciliation habit that data parity testing covers for replatforming generally, and the same one Nuts.com's migration applied across catalog, customers, orders and live subscriptions moving off a homegrown platform in six months.

What to do about the data you decide not to migrate

Some data shouldn't come. Order history beyond a certain depth, records for customers who haven't transacted in years, product records for lines discontinued long ago, custom fields nobody has read since the person who added them left.

Deciding not to migrate something is a legitimate outcome of the transform step, and it is not the same as deleting it. Export it, store it somewhere queryable, and write down where it went and who can get at it. The failure mode here isn't losing data — it's a finance or support team discovering at the worst possible moment that the answer to a question exists nowhere reachable. A short retention note in the migration plan costs nothing and prevents that entirely.

How to test a partner's ETL discipline before signing anything

Ask any prospective partner to walk through their ETL method in the abstract, before you tell them your origin platform. A partner with a real, repeatable method can explain it independent of any single platform. A partner without one will default to describing platform-specific experience instead, because that's what they actually have.

Then ask for a specific example of a past migration's parity testing process — not the outcome, the process. Sample size, which fields, what tooling, who signed it off. A partner with a real method can describe exactly how they verified correctness. A partner without one will describe the migration in terms of "it went smoothly" without being able to explain how they'd have known if it hadn't.

Frequently Asked Questions

Is data migration different for every ecommerce platform?

The extraction mechanics differ — which API or export tool a platform provides — but the underlying method of extract, transform, and load with parity testing is the same regardless of origin platform.

What's the most common mistake in data migration?

Verifying by record count alone instead of field by field on a meaningful sample. Totals can match while individual records are subtly wrong, a gap that often surfaces only when a customer disputes an order.

How much order history should we actually migrate?

Less than most teams assume. Decide the depth deliberately in the transform step — it materially changes the timeline, and the honest requirement is usually shorter than the instinct to bring everything.

Who should own the transform decisions?

Someone who understands both the business's actual reporting and operational needs and Shopify's current native data model. A person deeply embedded in the old platform's structure will tend to preserve it by default, which is how a legacy taxonomy survives a migration it should not have.

If you want a second opinion on a transform spec before it becomes a build, talk to an architect — or see how data migration fits into a systems replatform.