Ecommerce Data Migration: What Doesn’t Transfer
Most of your catalogue will survive an ecommerce data migration. Products, variants, images, collections, customer records and historical orders all move between platforms given the right tooling and enough patience. What catches teams out is the second list — passwords, active subscriptions, gift card balances, product reviews and every custom field someone added three years ago. None of those sit in a standard export, and none of them announce themselves when they go missing.
The dangerous part of a migration is rarely the data that fails to import. It is the data that imports looking perfectly fine and then behaves differently afterwards.
What an ecommerce data migration actually covers
“Migrating the data” gets treated as one line item on a project plan, usually sitting somewhere between “build the theme” and “launch”. In practice it is at least four separate jobs:
- Extraction — getting a complete, trustworthy export out of the old platform, including the things its own export tool leaves behind.
- Transformation — reshaping that export to match how the new platform models the same concepts. This is where most of the work lives.
- Loading — importing in the right order, because customers have to exist before their orders do, and products before their inventory.
- Reconciliation — proving that what arrived matches what left, at the record level, before anyone trusts it.
Skip the fourth and you find out what went wrong from a customer instead of from a report — the same reason a migration needs a 301 redirect map built before launch rather than after. Both are verification problems dressed up as data problems.
The three tiers of migration fidelity
Every piece of data in your store falls into one of three tiers. Sorting your own inventory into this table before the project starts is the single most useful hour you will spend on it.
| Tier | What it means | Typical records |
|---|---|---|
| Moves cleanly | Exports and imports with a direct field-for-field mapping | Products, variants, images, collections, prices, inventory counts, customer names and addresses |
| Moves, but changes | The record arrives; its behaviour or its URL does not survive | Historical orders, customer accounts, blog posts, category pages, discount codes |
| Does not move | Owned by a third party or cryptographically impossible to transfer | Passwords, subscription contracts, gift card balances, product reviews, loyalty points, metafields |
The middle tier is the one that hurts. Tier one is easy to check and tier three is at least obvious once someone names it. Tier two passes every count-based test and still causes support tickets.
What moves, but not the way you expect
Order history becomes a record, not a live order
Historical orders can and should be imported — support teams need them and customers expect to see past purchases. But an imported order is a copy of a transaction, not the transaction itself. No captured payment is attached to it, because the money was taken by a gateway the new platform never spoke to.
The consequence: you generally cannot refund, exchange or re-capture an imported order through the new platform’s normal flow. Those refunds have to be issued in the old gateway’s dashboard for as long as your returns window and chargeback exposure last. Plan on keeping that account open, and someone trained to use it.
Customer accounts arrive without passwords
Passwords are stored as one-way hashes, salted with something specific to the platform that created them. No platform can read another platform’s hashes and no reputable one will accept them. This is a security property working exactly as designed, and it is not negotiable.
So every account you migrate arrives without a way for its owner to log in. The new platform will offer to send activation invitations, and that email becomes the most consequential message of your launch. Send it badly — wrong timing, wrong sender, no explanation of why a reset is being asked for — and it reads as phishing. Send it to a list you haven’t cleaned and your sending reputation takes the hit in the same week your rankings are already wobbling.
Blog and content URLs get rebuilt, not copied
Editorial content transfers as text and images without much drama. Its addresses do not. Platforms disagree fundamentally about content URLs — Shopify, for instance, nests articles under a blog handle, so a post that lived at one path on your old system lands somewhere structurally different. Category and collection paths shift the same way.
Every one of those changes is a redirect you owe. This is the mechanism behind most post-migration traffic loss, and it is entirely preventable — provided the mapping is built from a crawl of what currently exists, not from what someone remembers publishing.
What does not move at all
Active subscriptions
Subscriptions are the hardest thing in any ecommerce replatforming project, because a subscription is not one record. It is three things that have to agree: a contract on the platform, a schedule in a subscription app, and a vaulted payment method held by the payment processor.
You can recreate the first two. You cannot export the third — the stored card lives with the gateway under PCI rules, and it never travels in a CSV. If you keep the same processor, a vault migration between compliant providers is a supported process, but it is arranged with the processor, takes lead time, and is not something the platform migration tool does for you. If you change processor at the same time as changing platform, you are asking every subscriber to re-enter a card, and some percentage of them simply won’t.
Gift cards and store credit
Outstanding gift card balances are a real financial liability, not a nice-to-have. They are also not part of a standard product, customer or order export, and codes are treated as sensitive data. Getting balances across takes deliberate handling — and it needs an owner in finance, not just in engineering, because the reconciliation is an accounting question before it is a technical one.
Product reviews
Reviews almost never live in your ecommerce platform. They live in the review app’s own database and are rendered onto your product pages. Migrate the platform and the reviews stay exactly where they were — attached to product identifiers that no longer exist.
The recovery path is an export from the old review app and an import into the new one, matched on SKU rather than on internal product ID. Most established review tools support this; our Judge.me integration guide walks through how that import works in practice. Do it before launch, because product pages that lose their social proof on the same day they lose their URLs are fighting on two fronts.
Metafields and custom attributes
Every store that has been running for a few years has accumulated custom fields — a care-instructions block, a supplier code, a “ships from” flag that the theme reads. They have no standard equivalent on the other side, so they need to be inventoried and remodelled by hand.
This is usually the largest single underestimate in a migration quote, which is one reason what a Shopify migration costs depends far more on how customised your current store is than on how many products it has. Ten thousand simple products are easier than five hundred complicated ones.
Two decisions that shape the whole project
How much order history do you actually need?
Importing every order since inception is slow and expensive, and much of it will never be read again. Importing none of it makes support miserable and strands your analytics baseline.
Ask what each year of history is for: returns and warranty claims need a defined window, customer service needs enough to answer “what did I buy”, reporting needs enough to compare like-for-like seasons. Set the cut-off deliberately and archive the rest somewhere queryable, rather than importing it out of anxiety.
Are you changing payment gateway at the same time?
If the answer is yes, say so out loud at kick-off, because it changes the risk profile of everything above. New gateway means no vault migration, subscription customers re-entering cards, saved payment methods gone, and refunds on old orders handled in a third place. It is sometimes the right call. It is never a detail.
How to prove the migration worked
Reconciliation is not “the import finished without errors”. It is a short list of checks run against the new store before launch and again immediately after:
- Counts, by type — products, variants, customers, orders. A mismatch is easy to see and easy to fix while you still have both systems.
- Spot-check the awkward records — your most-customised product, your biggest B2B account, a subscription customer, an order with a partial refund. Bugs cluster in the exceptions, never in the median record.
- Totals, not just rows — sum the order values on both sides. Rows can all arrive while currency, tax or discount fields quietly shift.
- Crawl before and after — the same crawl that builds your redirect map is the one that verifies it resolves.
If you want that sequenced into a full pre-launch routine, our free Shopify migration checklist covers the surrounding steps in order, from audit through post-launch monitoring.
Frequently asked questions
Can I migrate customer passwords to a new platform?
No. Passwords are stored as salted one-way hashes that only the originating platform can verify, so there is no mechanism to transfer them. Every migrated customer needs to set a new password, usually through an account activation email sent at launch.
Will my historical orders work normally after migration?
They will be visible and searchable, but they are records rather than live transactions. Because no payment was captured through the new platform, refunds and exchanges against pre-migration orders normally have to be processed in your old gateway, so keep that account open for the length of your returns window.
Do product reviews transfer automatically?
Not by themselves. Reviews are held by your review app, not your ecommerce platform, so they need a separate export and import matched on SKU. Handle it before launch so product pages don’t lose their social proof at the same moment their URLs change.
What is the most commonly underestimated part of an ecommerce data migration?
Custom fields. Metafields and bespoke attributes have no standard mapping between platforms, so each one has to be inventoried, remodelled and re-referenced in the theme. Highly customised stores take far longer to migrate than large but simple ones.
The short version
An ecommerce data migration is not a file transfer. It is a modelling exercise, and its quality is decided in the first week, when someone either does or does not sit down and write out what exists, where it actually lives, and what it becomes on the other side. The teams that come through a replatform without a bad quarter are the ones that treated passwords, subscriptions, reviews and gift cards as workstreams rather than as surprises.
To find out which tier your own data falls into, a free Shopify audit is a reasonable place to start. Wholesale and trade stores carry different constraints again — B2B replatforming adds price lists, company accounts and ERP to the same equation. And the route matters: a WooCommerce to Shopify migration has a very different data shape to an enterprise one.
Current store performance