How to Plan a Migration to Shopify

Most Shopify migrations do not fail on launch day. They fail three weeks earlier, in a scoping call where somebody says "it's about four thousand products" and everyone writes that number down and moves on.

Four thousand products is not a scope. It is a row count. It says nothing about how many of those products have variants with inconsistent option names, how many share a SKU with a different product, how many are referenced by an active discount rule, or how many have descriptions with hardcoded image URLs pointing at a server you are about to switch off.

The teams that come through a migration calmly are not the ones with the biggest budget. They are the ones who spent the first two weeks finding out what they actually had before anyone agreed what the work was.

What actually breaks in a Shopify migration

Migrations rarely break in the obvious place. The storefront is the visible part, so it gets the attention, and it is usually fine. The failures cluster in four areas that are invisible until they are not.

Data shape mismatches. Your old platform let a product have unlimited attributes with arbitrary names. Shopify has a defined model: products, variants built from up to three options, and metafields for everything else. Anything that does not map cleanly has to be reshaped, and that reshaping is a business decision, not a technical one. Somebody has to decide whether "Colour" and "Color" are the same option.

Identity and access. Customer records migrate. Passwords do not. Order history migrates, but order state — refunds mid-flight, partially fulfilled shipments, active subscriptions — often does not migrate cleanly, and each needs a decision.

The integration surface. The storefront is one system among several. Your ERP, 3PL, email platform, reviews app, and accounting export all talk to the old store. Every one of those connections has to be rebuilt, re-authenticated, and re-tested, and at least one of them will be maintained by someone who left the company.

URLs. This is the one that shows up in a traffic graph six weeks later, long after everyone has stopped watching.

Audit the source data before you scope anything

The audit is the single highest-leverage part of a migration, and it is the part most often skipped because it produces no visible progress. Do it anyway. Every hour here removes several later.

Products and variants

Pull the full catalog and look for the things that will not map:

• Products with more than three distinct option types, which exceeds Shopify's variant model and needs metafields or a restructure
• Option names that vary in spelling or case across products
• Duplicate or missing SKUs, and SKUs that carry meaning your operations team relies on
• Products with no price, no image, or no inventory record
• Bundles, kits, and configurable products, which almost never have a direct equivalent
• Digital or downloadable products, which need an app on Shopify

Count each category. A hundred products with four option types is a scoping conversation. Three is a footnote.

Customers

Customer records are usually the cleanest data you have, with two exceptions. First, passwords cannot come across — plan the activation flow and the email that explains it. Second, marketing consent state must be migrated accurately, because getting it wrong is a compliance problem, not a data problem. If your old platform tracked consent loosely, this is the moment you find out.

Orders and history

Decide early how much order history you actually need in Shopify. The honest answer is often less than people assume. Finance usually needs exports, not live records. Support needs recent orders, not everything since 2016. Migrating full history is possible, but it is slow, it inflates the project, and it frequently delivers records nobody opens.

Ask what each stakeholder needs order history for, then migrate to that requirement.

Content and media

Blog posts, landing pages, help content, and images. The traps here are hardcoded absolute URLs pointing at the old domain, images referenced from a CDN that gets switched off, and content stored in a page builder whose markup means nothing outside its own platform. Page-builder content usually needs rebuilding rather than migrating, and that is a content-team workload, not a developer one.

Integrations

List every system that touches the store, and for each one record what it reads, what it writes, who owns it, and whether it has a Shopify equivalent. This list is always longer than anyone expects. It routinely surfaces a connection nobody remembered building.

If it runs past a handful of systems — an ERP, a WMS, a finance export, a 3PL — then the integration layer, not the catalog, is what sets your schedule. At that point you are running a replatform rather than a migration, and how the work is sequenced matters more than how the import script is written.

Map every URL before you touch a template

Search engines have an index of your site. A migration invalidates a large part of it at once. The work is unglamorous and entirely mechanical, which is exactly why it gets deferred until it is too late to do properly.

Start by building the inventory from several sources, because no single source is complete:

• Your sitemap, which tells you what you think you have
• Search Console, which tells you what is actually indexed and getting impressions
• Server logs or analytics, which reveal URLs that still receive traffic and are in nobody's sitemap
• Your backlink profile, so that externally linked pages are not quietly dropped

Then map each URL to its destination. Most will map cleanly because Shopify's URL structure is predictable. The interesting ones are the exceptions: category pages that no longer exist, filtered URLs that were indexed by accident, and old campaign landing pages still earning links.

Redirects go live with the launch, not after. A redirect deployed two days late is two days of visitors and crawlers hitting dead pages.

Decide what you are not migrating

Every migration is an opportunity to leave things behind, and almost every team under-uses it. Migrating rubbish costs the same as migrating value: the same mapping work, the same validation, the same QA time.

Strong candidates for deletion rather than migration:

• Products discontinued years ago with no traffic and no backlinks
• Duplicate products created to work around an old platform limitation
• Expired campaign and seasonal pages
• Draft content nobody finished
• Customer accounts that never placed an order and have not logged in for years, subject to your retention policy

The one caution: check traffic and backlinks before deleting anything. A discontinued product page with steady search traffic and inbound links is an asset, even if the product is gone. Redirect it rather than dropping it.

Build a staging environment you can re-run

The most useful thing you can build early is not the storefront. It is a repeatable import.

You will run the import more than once. You will find a field that was mapped wrong, a category that imported with the wrong parent, or a currency that came through unrounded. If your import is a person clicking through a CSV upload, every one of those fixes is a manual redo, and the temptation is to patch the result by hand instead — which means the next run silently loses the patch.

A repeatable import means:

1. The mapping lives in code or configuration, not in someone's memory of which columns they matched
2. Running it twice produces the same result rather than duplicate records
3. Each run reports what it wrote, what it skipped, and why
4. The whole thing can be pointed at a fresh store and re-run from scratch

Then validate against the source. Compare record counts by type. Sample deliberately: the product with the most variants, the customer with the longest order history, the order with a partial refund, the item with an unusual character in its title. Edge cases are where the mapping errors hide, and they never appear in a random sample of ten products.

The cutover runbook

Cutover is the one part of a migration where improvising is expensive. Write it down.

A usable runbook covers, in order: what gets frozen and when, who confirms each step, how DNS and domain changes are sequenced, when redirects go live, which integrations get re-pointed and in what order, what gets verified immediately after, and what the rollback position is if a step fails.

That last one matters most and is the most often missing. Full rollback is not always possible once orders start landing in the new system — but "we cannot roll back after this point" is a legitimate entry in a runbook, provided everyone knows which step it sits after. What is not acceptable is finding out during the incident.

Schedule cutover for the lowest-traffic window you can find, with the people who understand each system available rather than on a plane. The disruption window should be short and predictable. Any agency promising there is no window at all is describing a marketing position, not an engineering plan.

What to watch in the first two weeks

Launch is not the end of a migration. It is the start of the period where the mistakes surface.

Immediately: checkout completes end to end with a real payment method, order confirmation emails send, orders reach your fulfilment system, and inventory decrements correctly.

First 48 hours: 404 rates, redirect coverage against your mapping, integration error logs, and search behaviour on the new storefront. Watch what customers search for — it exposes navigation problems faster than any analytics report.

First two weeks: Search Console coverage and crawl stats as the new URLs are discovered, organic landing pages compared against pre-launch, and support ticket themes. A cluster of tickets about the same thing is your clearest signal about what actually broke.

Expect some ranking movement while search engines re-crawl and re-evaluate. Movement is normal. A sustained decline in a specific section usually points at a redirect gap in that section, which is fixable if you are watching.

A realistic way to think about timelines

We do not quote migration timelines before the audit, and we would be sceptical of anyone who does. Before you know the shape of the data, a schedule is a guess dressed as a commitment.

What you can plan for is sequence. Audit first, because it sets the scope. Then mapping and architecture, because they determine the build. Then the storefront and integrations in parallel, because they are independent. Then staged imports and validation, which always take longer than expected because this is where the audit's findings come due. Then cutover, then a support window.

The step teams most often compress is validation, because it sits between "the site looks done" and "we can launch". It is also the step whose absence causes the launch-week incidents. Protect it.

The platform you are leaving shapes the work

Everything above applies to any migration. What changes between them is where the difficulty concentrates, and it is worth knowing which kind of project you are actually running.

Leaving WooCommerce, the catalog is rarely the problem — the plugin stack is. Twenty to sixty plugins encode pricing rules, shipping logic, and subscription billing, and the migration is really an exercise in deciding what each one becomes on Shopify.

Leaving Magento, the difficulty is structural. Attribute sets, bundled products, customer groups, and tier pricing express business rules that Shopify models differently, so the work is translation rather than transfer, and some translations are imperfect enough to need a decision.

Leaving BigCommerce, the data side is comparatively predictable — both platforms are hosted with reasonable APIs. The sharp edge is product options: BigCommerce modifiers that never created variants have no clean Shopify equivalent.

Leaving Wix, extraction is the project. It is a closed system with limited export and API access, so the effort sits in getting a complete, verified catalog out at all — and the storefront is a rebuild, because nothing about a Wix site is portable.

Where this usually lands

A migration is a data project wearing a web project's clothes. The storefront is visible, so it absorbs the attention and the budget conversation, but it is rarely what determines whether the migration goes well. What determines that is whether someone did the tedious work of finding out what the data actually looked like, writing down where every URL was going, and deciding in advance what would happen if a cutover step failed.

None of that is exciting. All of it is cheaper than the alternative.

If you are planning a move to Shopify and want a view on where the risk actually sits in your specific setup, tell us what you are working with — we will give you a straight assessment of what the audit is likely to surface. If you would rather start on your own, the migration readiness scorecard runs through the same factors and tells you which of them apply to your store.