WooCommerce to Shopify migration: what actually breaks

Search “WooCommerce to Shopify migration” and you will get forty checklists that agree with each other. Audit the catalogue. Export the CSVs. Pick an import app. Rebuild the theme. Set up redirects. Test. Launch.

None of it is wrong. It is just that all of it stops at launch day, and launch day is roughly when a migration starts to go wrong.

We have moved stores between these two platforms in both directions, for supplement brands, apparel labels, a handloom catalogue with product options no platform was designed to hold, and several regulated botanical retailers where getting it wrong would have meant losing a payment processor as well as a weekend. The pattern barely changes. The parts everyone plans for go fine. The damage arrives from four directions nobody put in the project plan: data that quietly did not come across, a redirect map that passed testing while being wrong, a revenue dip nobody had modelled, and a team who found out on Monday that their working environment had changed.

So this is the version written from the other side.

Start by asking whether the platform is your problem

This costs us work to say, and we say it to most people who ask.

Most stores that want to replatform do not have a platform problem. They have a theme four developers have extended over six years. They have twenty-eight apps, nine of which do nothing and three of which are quietly fighting. They have a checkout nobody has looked at since 2023. Move all of that to Shopify and you get the same problems on a faster host, with an invoice attached.

The test is short. Write down the three things you believe migrating will fix, then decide whether each one is a property of WooCommerce or a property of your WooCommerce.

Genuine platform problems look like this. You are spending real money and management attention on hosting, uptime and PCI scope, and you would rather not. Your peak traffic breaks the site and every fix is an infrastructure project. You want checkout to be permanently somebody else’s responsibility. Your merchandising team cannot change anything without a developer, and that has become the bottleneck on revenue.

Things that will follow you across the fence: a slow site (usually theme weight, unoptimised images and app sprawl, all of which migrate happily), a poor conversion rate (checkout changes, but your product page and your offer are yours), and messy catalogue data, which will be exactly as messy on the other side because the import does not clean anything.

If your list sits mostly in the second group, fix those where you are. It is cheaper, it is faster, and you keep the result whichever platform you end up on. Quite often people run that exercise and stop wanting to migrate, which is a fine outcome. We would rather tell you now than four months in.

What genuinely does not transfer

Migration tools advertise products, customers and orders. They do move those, mostly. The trouble is everything sitting around them.

Customer passwords. Hashed, and therefore unmovable. Every customer resets on first login. That is unavoidable and fine, but treat it as a communications event rather than a technical footnote. If you have a large dormant list, expect a support spike and a measurable dent in returning-customer conversion for a fortnight.

The theme. Nothing ports. WooCommerce themes are PHP, Shopify themes are Liquid, and there is no bridge between them. Budget for a full storefront rebuild and be suspicious of anyone suggesting otherwise.

Subscriptions. Here is the one that hurts, and almost no migration guide covers it properly.

WooCommerce Subscriptions holds three things: the subscription, the schedule, and the payment token that lets you charge that customer again next month. The token belongs to your payment gateway, not to WooCommerce. Move to Shopify and a subscription app, and you are asking a system the gateway has never met to charge cards it has never seen.

Sometimes the tokens can be migrated. That requires staying with the same gateway, the gateway supporting token export, and the receiving app supporting token import. Often one of those three is false. When it is, every subscriber re-enters their card details, and a predictable share of them never get round to it. On a subscription business, that is not an inconvenience during migration. It is a revenue event, and it belongs in the business case before anyone opens a CSV.

Find out which situation you are in early. Ask your gateway in writing whether tokens can be exported. Ask the receiving app the same question, in writing, and get a name. If either answer is no, model the churn honestly and decide with the real number in front of you.

Custom fields. If you have used ACF, post meta or a product add-on plugin to hold size charts, ingredient lists, care instructions, lab reports or downloadable spec sheets, none of it maps by itself. Shopify metafields will hold all of it, but somebody has to design the schema and write the mapping. Catalogue migrations tend to blow their estimates here, not on the product import.

Reviews. They live in a plugin and will live in a different app afterwards. Most review apps ship an importer. Test yours on one product before trusting it with four thousand.

Product options. Shopify’s data model is stricter than WooCommerce’s. Products carry a limited number of option dimensions and a ceiling on total variants, and anything above the ceiling fails at import rather than degrading politely. If you sell made-to-order goods, configurable bundles, or anything with more than three axes of choice, restructure the catalogue before you import it. This is a modelling problem rather than a data problem, and in our experience it is the single most common reason a migration stalls in week three.

SEO metadata. Title tags, meta descriptions and canonicals do not ride along in a product CSV. They need a mapped import of their own. Skip it and you will lose rankings while blaming your redirects.

The redirect map is the highest-stakes thing you will build

Everything above is recoverable. A bad redirect map costs organic revenue for months, and it is horrible to spot, because traffic decays rather than stops.

Every guide tells you to set up 301 redirects. Very few tell you how to test them, so here is how we do it.

Build the source list from reality rather than from your sitemap. A sitemap contains what you believe exists. Pull from three places instead and merge them: a full crawl of the live site, your top thousand landing pages from the last twelve months of analytics, and every URL with an inbound link pointing at it. That third source is the one people skip and the one holding your equity.

Map by pattern, then work the exceptions by hand. The structural disagreements between the two platforms are predictable, and the table in the image above covers most of them. Product tags are where judgement comes in. A store with two hundred tags does not need two hundred collections; map the ones with traffic or links and let the rest resolve somewhere sensible.

Then test properly, which does not mean spot-checking a dozen. Take the entire source list, request every URL against the new site, and record three things: status code, number of hops, final destination. You are hunting four failure modes.

1. 404 - a page you forgot.
2. 200 - a page you forgot to redirect, now duplicated across two URLs.
3. Chains of more than one hop, leaking a little equity at each.
4. A clean 301 to the wrong page. This is the dangerous one, because it passes every automated check ever written. A hundred unmapped products all pointing at your homepage looks perfectly healthy to a crawler and tells Google your catalogue no longer exists.

That fourth mode is why a human has to read a sample of the mapping. No script will tell you that /product/organic-green-powder/ should not be resolving to /collections/all. When Gud Tonics came to us after a botched migration, the redirects were technically flawless and pointing at the wrong things.

What it costs, and what moves the number

Published migration prices are wildly inconsistent because agencies are quoting for different planets. You will see $150,000 to $300,000 for mid-market replatforming, and those figures are real for enterprise catalogues with ERP integrations, multi-region tax logic and a dozen stakeholder teams to satisfy.

That is not the project most D2C brands are running. For a store turning over somewhere between $100k and $5M, with a catalogue in the hundreds rather than the tens of thousands, the honest cost drivers are these, roughly in order of impact.

Catalogue complexity comes first, and it is not the same as product count. Five hundred simple products is a smaller job than forty configurable ones. Then custom functionality, where every bespoke behaviour resolves to an app subscription, a Shopify-native rebuild or a compromise, and each one needs a decision. Then integrations: ERP, 3PL, accounting, CRM, email, each its own small project. Then content, because a three-hundred-post blog with images and internal links is real work. Then redirect mapping, which scales with how many URLs have earned links rather than how many exist. The theme build is the most visible line on the quote and rarely the biggest.

The costs that get forgotten are more interesting. Functionality that was a one-off plugin purchase becomes an app subscription at $30 to $300 a month, for as long as you trade; add three years of that up before you compare platforms. Transaction fees, if you are not using Shopify Payments. Staff time, because your team stops doing their job in order to learn a new one. And the revenue dip, which deserves its own section.

The first two weeks

This is the part other guides do not have, and it decides whether the migration was worth doing.

Expect a dip, and know which dip you are looking at, because panicking about the wrong one is expensive.

A migration with clean redirects usually sees organic sessions fall for one to three weeks while Google recrawls and reassigns authority, then recover. A shallow dip that has started climbing by week three is normal and needs no action at all. It is not evidence that something is broken. Reacting to it, by reverting redirects or resubmitting sitemaps daily or changing URLs a second time, reliably makes things worse.

What is not normal: a dip still deepening at week three; impressions holding steady while clicks collapse, which is a title and meta problem rather than an indexing one; specific high-value URLs vanishing while everything else recovers, which is a redirect problem on those URLs; and crawl errors climbing week on week instead of falling.

Agree what you will watch, and the threshold at which each becomes a problem, before you launch rather than during the argument.

That subscription row wants a human every morning for a month. Failed rebills do not announce themselves. They turn up as an unexplained revenue shortfall six weeks later, by which time the customers have gone.

Decide your rollback triggers in advance too. Not because you are likely to use them, since full rollbacks are rare and unpleasant, but because deciding under pressure at 11pm produces bad decisions. Reasonable triggers: checkout is broken and cannot be fixed inside an agreed window, payment capture is failing, or catalogue data is materially wrong across a large share of products. Everything else is a fix-forward problem.

The parts nobody budgets for

Your team has to relearn their jobs. Customer service looks up orders somewhere else. Fulfilment sees a different screen. Whoever merchandises now thinks in collections rather than categories. Because nobody plans training, the week after launch gets spent with three people asking each other where things are while the support queue grows. Half a day and a one-page internal cheat sheet removes most of that.

Customers need telling as well. At minimum: passwords reset on first login, order history has come across, subscriptions continue or they do not. Send it before launch and the support spike becomes a non-event. Send it after and you are explaining yourself to people who are already annoyed.

And every internal process document that references the old admin is now wrong. Somebody should own fixing them.

When we would tell you not to do it

If you are heading into peak season. Migrate in your quietest quarter, and never in Q4.

If your subscription tokens cannot move and subscriptions are most of your revenue. Solve that first or stay where you are.

If your catalogue needs restructuring to fit Shopify’s option model and nobody has time to think it through properly. The import will not do that thinking for you.

If the real problem is conversion rate. Fix it on the platform you already have, which is cheaper and faster, and you keep the improvement either way. We have rebuilt conversion on stores that then chose not to migrate at all.

And if you cannot name three things the move fixes that could not be fixed where you are.

What it comes down to

Migration failures are rarely technical. The export runs, the import runs, the theme gets built, everyone goes home. What breaks is around the edges: subscriptions whose payment tokens stayed behind with the old gateway, custom fields nobody mapped because they were nobody’s job, a redirect map that passed automated testing while quietly pointing half a catalogue at the homepage, and a team who found out on Monday.

Plan the fortnight after launch as seriously as the fortnight before it and this becomes what it should be, which is a manageable project with a predictable dip and a known recovery.

Thinking about moving? Send us your store URL through the contact form and we will come back with the three things we would check first: how your catalogue maps onto Shopify’s option model, whether your subscription tokens can travel, and where your link equity actually sits. If the honest answer is that replatforming relocates your problem rather than solving it, we will tell you that instead.

You can also look at how we handled Kampura’s move from WordPress to Shopify, or the rest of our recent work.