Moving a store to Shopify is rarely a case of “products go from A to B.” The parts that cause problems are the ones that don’t map cleanly: custom fields with no Shopify equivalent, order history that needs to land in the right status, customer records that carry consent or loyalty data your old platform tracked in its own way. This guide walks through what happens during a Shopify data migration, where the real friction shows up, and how to verify the result before you go live. It includes a real (anonymized) case from a migration we ran, so you can see what the custom-field problem looks like in practice rather than in the abstract.

What “data migration” actually covers

A Shopify migration typically moves five categories of data:

Products: Titles, descriptions, images, pricing, inventory levels, and variant structure (size, color, and other option-based attributes that Shopify maps directly to its own variant system).
Customers: Names, contact details, addresses, and marketing consent status, mapped into Shopify’s customer and consent fields. One thing that never transfers: passwords. Shopify doesn’t allow any migration tool to import customer passwords, so returning customers set a new one through an account invitation or a password reset. Plan the email that tells them before launch day.
Orders: Order history, line items, and fulfillment/payment status, mapped to Shopify’s own order-status model.
Content: Blog posts, static pages, and in some cases URL structure, which matters for SEO continuity. If your old URLs rank, pair the migration with 301 redirects; our SEO migration guide covers how.
Custom or non-standard data: Anything your old platform stored that doesn’t have an obvious Shopify home: product attributes specific to your catalog, custom customer fields, order metadata your fulfillment process depends on. This is the category that causes the most surprises, and it’s worth understanding in detail before you migrate, not after.

The first four categories are largely mechanical: Shopify has a defined field for most of what a typical store needs, and a competent migration tool maps source to destination automatically. The fifth category is where a migration succeeds or quietly loses data, because “no Shopify field for this” doesn’t mean the data doesn’t matter. It means someone has to decide where it goes.

The custom-field problem, and how it plays out

Shopify’s product model has a fixed set of native fields, plus product options for things like size and color that generate variants automatically. If your old platform’s custom fields map to variant options, that part is straightforward. If they don’t, Shopify’s answer is metafields: custom key-value fields, organized by namespace and key, that can hold text, numbers, dates, references to other resources, or lists of values, and that show up in the Shopify Admin alongside the product’s standard fields once they’re created. That’s flexible enough to hold almost anything a source platform stores. But metafields don’t get created and populated automatically because the source data exists.

A WooCommerce case: five fields considered, one mapped

Here’s what that looks like on a real migration. A home-decor retailer moving from WooCommerce to Shopify had a catalog built around a set of custom product fields: artist name, room type, color palette, mood, and layout. WooCommerce stored them as custom fields; Shopify has no default place for them. During the store review that’s part of our Done-for-you managed migrations, our team flagged that these fields wouldn’t come across automatically. They’d need to be created as Shopify metafields and explicitly mapped, field by field, from the WooCommerce source.

That’s a normal finding, and it’s exactly the kind of thing a pre-migration review is supposed to catch. What made it a useful case is what happened next. Once the merchant saw the full list of fields that could be mapped, and understood that custom field mapping is a separately priced add-on on top of the base migration, they didn’t map all of them. They picked the one field that mattered to how they ran the store, layout, and left the rest out. Artist, mood, color, genre, and room type didn’t make the cut, not because they couldn’t be migrated, but because once the merchant weighed them against the base catalog, they weren’t worth carrying forward.

The lesson isn’t “map everything” or “map nothing.” It’s that a custom-field inventory has to happen before migration, so the decision about what’s worth carrying over is one you make on purpose.

A Magento case: three identifiers, one barcode field

We’ve seen the same pattern from other platforms, in different shapes. One Magento store had multiple identifier-style fields on its products: separate entries functioning as EAN, GTIN, and UPC, set up as custom attributes specific to that store rather than anything Magento provides natively. Shopify has exactly one barcode field per product variant, so only one of those values could go there. The rest had to be mapped into metafields, or the merchant had to decide which identifier mattered operationally (usually whichever one their fulfillment or marketplace integrations checked).

Same underlying issue as the WooCommerce case: a source platform can store more distinct fields than Shopify has native slots for, so someone has to make an explicit decision about where the extra data goes, or whether it goes anywhere at all.

How the migration process runs

A typical Shopify data migration follows a consistent sequence, regardless of source platform:

Scoping and field review: Before anything moves, the source store gets reviewed for non-standard data: custom fields, non-option attributes, and anything else without an obvious Shopify equivalent. On a Done-for-you migration our team does this review with you; on a self-service migration, it’s the step to do yourself before you start. Either way, this is what catches the custom-field problem above before it becomes a live-store surprise.
Demo migration: A small sample moves first, so mapping issues surface on a handful of records rather than your whole store. Our free demo migrates up to 10 products, 10 customers, and 10 orders from your real data. This is where you check that stock levels, custom attributes, and order statuses landed the way you expected, and adjust anything that didn’t before it reaches your customers.
Full migration: Once the demo is approved, the complete data set moves: products, customers, orders, and content, following the field mappings confirmed during scoping.
Verification: The migrated store gets checked against the source for whether the right data landed in the right fields (more on this below).
Go-live: DNS and store settings get switched over once verification is complete.

What verification should mean

It’s tempting to treat verification as “does the customer count in Shopify match the customer count in the old platform.” That check matters, but it only confirms nothing got dropped outright. A count that matches can still hide a mapping problem if the wrong field got populated.

A more useful verification pass checks:

Field-level accuracy on a sample, not only totals: Pull a handful of records (products with custom attributes, customers with consent data, orders with specific statuses) and compare the field values in Shopify against the source, not only that a record exists.
Whether optional or non-standard fields made it across at all: If your migration scope included metafields, confirm they’re populated and visible on the product in the Shopify Admin, not only that the metafield definition was created.
Order and customer status accuracy: Order statuses and customer marketing consent are two of the easiest things to migrate “successfully” in the sense that a record was created, while still landing in the wrong state. Spot-check these specifically.
Anything that didn’t migrate, and why: A gap isn’t always a failure. In our Highly Preppy case study, 15 customers didn’t migrate because of invalid email addresses in the source data. Knowing the reason is what lets you decide whether to fix it.

Catching a mapping issue in the demo costs you a re-run. Catching the same issue after a full migration to a live store costs you a lot more.

Before you migrate: a short checklist

Inventory your custom fields. List your source platform’s custom fields and non-option attributes, and don’t assume they’ll come across automatically because they matter to you.
Get an answer for every non-standard field. Ask how each one (custom fields, product identifiers beyond a single barcode, customer or order metadata) will be handled: mapped to Shopify metafields, folded into descriptions or tags, or left out. Get that answer, and what it costs to map, before migration starts rather than renegotiating it midway.
Review the demo against your source data. Checking that products appear isn’t enough; check that the fields you care about are populated correctly.
Verify at the field level after migration. Sample real records rather than trusting a matching total.
Tell customers about passwords. Have the account-invitation or password-reset email ready for launch.

If you’re not sure what a specific field will need, ask. A short pre-migration conversation about your platform’s data structure is a lot cheaper than finding out what didn’t map after your store is live.

Complete Guide to Shopify Data Migration