WooCommerce to Shopify Migration: The Complete Guide
On this page
WooCommerce to Shopify is the most common migration we handle, and it fails in the most predictable ways.
Not the data. Products, customers, and orders move reliably enough with reasonable care. What catches people out is everything around the data: URL structures that do not map cleanly, plugin functionality with no Shopify equivalent, content living in places nobody thought to inventory, and an SEO plan that either exists in detail or does not exist at all.
So this guide is organised around what actually goes wrong, in the order you will encounter it.
First: should you migrate at all?
Worth asking honestly, because the answer is sometimes no.
Stay on WooCommerce if: you have deeply custom functionality built into WordPress that has no Shopify equivalent and represents real business logic; your store is a small part of a large content site where the commerce is secondary; you have in-house WordPress expertise and a stable, well-maintained installation; or your margins are thin enough that transaction fees materially change your economics.
Migrate if: you are spending significant time and money on maintenance, security, hosting, and plugin conflicts rather than selling; your site’s performance is poor and you have lost confidence in fixing it; you have suffered a security incident or live in fear of one; plugin update anxiety governs your release schedule; your checkout conversion is weak and you suspect the checkout is why; or you want to stop being a systems administrator and go back to running a shop.
The honest summary: WooCommerce gives you control and charges you in responsibility. Shopify takes away some control and takes the responsibility with it. Which trade you want depends on whether your team wants to maintain infrastructure.
If you are unsure, the tell is where your development budget goes. If most of it goes to keeping things working rather than making things better, that is the argument for migrating.
What moves cleanly
Products. Titles, descriptions, SKUs, prices, weights, images, and inventory levels all export and import with reasonable fidelity. Variable products map to Shopify variants, with a caveat covered below.
Customers. Names, emails, addresses, and order history move. Passwords do not — no platform exports them in usable form, so customers will need to reset. Plan communication around this.
Orders. Historical orders import for reference. They will not be perfectly identical to native Shopify orders, but for records and customer service they are fine.
Categories to collections. WooCommerce product categories become Shopify collections, though the hierarchy usually needs rethinking rather than copying, since Shopify handles nesting differently.
Blog posts. Movable, though formatting needs attention and this is where people underestimate the work.
Where it actually gets difficult
Variable products with many attributes. Shopify has historically limited the number of options per product, and stores with complex attribute structures — size, colour, material, finish, length — can exceed it. Check your most complex products against current Shopify limits early, because discovering this late forces a product architecture rethink under time pressure. Workarounds exist, including splitting into separate products, using metafields, or a combination, but each has consequences for merchandising and SEO.
Plugin functionality. This is the largest hidden scope. Every plugin doing something on your storefront needs a Shopify equivalent, a rebuild, or a decision to live without it. Make a full inventory before you scope anything, including the ones you forgot about. Common problem areas: complex dynamic pricing, role-based pricing for wholesale, bespoke product configurators, custom shipping logic, membership functionality, and anything built specifically for you by a previous developer.
Some of these map to Shopify apps. Some need custom development. Some simply cannot be reproduced and require a business decision rather than a technical one. The worst outcome is discovering this in week six.
URL structures. WooCommerce and Shopify structure URLs differently, and Shopify enforces its own prefixes for products, collections, blogs, and pages. This means most of your URLs will change, which means you need a comprehensive redirect map. More on this below, because it is the single most consequential part of the project.
Custom fields and metadata. Product specifications, care instructions, ingredient lists, technical data, and anything else stored in custom fields need mapping to Shopify metafields. Straightforward once identified, and frequently not identified until something is visibly missing.
Content pages. Not just your main pages — the accumulated ones. Landing pages from old campaigns, shipping policies, FAQs, size guides, about pages, and whatever else has built up over years. Crawl your own site properly rather than working from memory.
Reviews. Product reviews often live in a plugin with its own storage, and migrating them requires either a supported import path into your chosen Shopify review app or a manual approach. They are worth preserving — they carry conversion value and structured data — and they are commonly lost because nobody checked the path before switching.
Subscriptions, if you have them. This is the highest-risk item in any migration that involves them, and it has its own article in this batch. The short version: stored payment methods may not transfer, and if they do not, you lose subscribers permanently.
The SEO plan, which decides whether this goes well
Most migration horror stories are SEO stories. Traffic falls 40% and does not come back, because the redirect work was treated as a technical afterthought rather than the centre of the project.
Crawl your current site completely before you change anything. Every URL, its title, its meta description, its status code, and its organic traffic over the last twelve months. This is your source of truth and you cannot reconstruct it afterwards.
Pull your top pages by organic traffic and revenue. These get individual attention. A generic bulk redirect rule is fine for the long tail and not fine for the twenty pages producing most of your traffic.
Build a complete redirect map. Every old URL to its closest new equivalent, as a 301. Products to products, categories to collections, posts to posts, pages to pages. Where no equivalent exists, redirect to the most relevant parent rather than the homepage — mass redirects to the homepage are treated as soft 404s and waste the equity entirely.
Preserve titles and meta descriptions for pages that rank, unless you have a specific reason to improve them. Changing platform and metadata simultaneously makes it impossible to diagnose what caused a ranking change.
Keep your content. Thin product descriptions get thinner in migrations, because export and import loses formatting and someone tidies by deleting. If a page ranks, its content is doing work.
Match or improve structured data. Product schema, review schema, breadcrumbs, FAQ markup. Shopify themes handle much of this, but verify rather than assume.
Test the redirect map before launch, on staging, in bulk. Then test it again after launch, against the full crawl from step one.
Monitor for ninety days. Search Console coverage and performance reports, weekly. Expect some volatility in the first few weeks — that is normal. What is not normal is a sustained decline after week three, and catching it early is the difference between a fix and a recovery project.
There is a dedicated article on the post-migration SEO plan in this batch, because the ninety days after launch matter as much as the work before it.
A worked example: the migration that lost 40% of traffic, and why
A homeware retailer migrated from WooCommerce to Shopify with a developer who did the data migration competently and treated SEO as a box to tick. Their traffic fell roughly 40% within six weeks and they came to us four months later, still down.
What we found:
Their redirect map covered products and nothing else. Around 900 blog posts, 40 content pages, and every category URL had been redirected to the homepage in bulk. Google treats that as a soft 404 — the redirect does not pass equity because the destination is not equivalent — so years of accumulated authority on those URLs simply evaporated.
Their top-performing category pages, which had carried substantial buying-guide content, had been recreated as bare Shopify collections with no text at all. The content had not been migrated because nobody had inventoried it.
Product titles had been rewritten during import to a new template, changing the exact-match phrasing that several pages had been ranking on.
And their blog had moved to a URL structure with no redirects at all, returning 404s for roughly 900 URLs, many of which had backlinks.
Recovery took five months. We rebuilt the redirect map properly from an archived crawl of the old site — which we were fortunate to be able to reconstruct — restored the category content from the Wayback Machine and their own backups, reverted product titles where we could establish the originals, and mapped every blog URL to its new equivalent.
Traffic recovered to roughly 90% of pre-migration levels and then grew past it, but the lost year is not recoverable.
Every single failure in that project was preventable with a crawl before launch and a proper redirect map. The data migration was fine. The SEO work was the project, and it was treated as a task.
A realistic sequence
Weeks 1–2: audit and inventory. Full crawl. Plugin inventory with a decision against each. Custom field inventory. Content page inventory. Top pages by traffic and revenue. Complex product check against Shopify limits.
Weeks 2–4: scope and build decisions. What gets a Shopify app, what gets built, what gets dropped. Theme choice or build. Product architecture for anything that does not fit natively.
Weeks 3–6: build. Theme, custom functionality, app configuration, metafield structure.
Weeks 5–7: data migration to staging. Products, customers, orders, content, reviews. Then check it properly — spot-check the most complex products, not just the easy ones.
Week 7: redirect map. Built completely, reviewed against the crawl, tested on staging.
Week 8: pre-launch verification. Test orders, payment testing, email flows, tax and shipping configuration, tracking installed and firing, mobile testing on real devices, and a full run through your launch checklist.
Launch, then ninety days of monitoring.
That is roughly eight weeks for a straightforward store with a competent team. Complex stores take longer. Anyone promising two weeks for a store with meaningful history is either very good or has not asked the right questions, and it is usually the second.
What you gain, honestly
Worth being specific rather than promotional.
Maintenance disappears. No hosting, no security patching, no plugin conflicts, no PHP version anxiety, no 3am outage because an update broke something. For most teams this is the real value.
Checkout improves. Shopify’s checkout is heavily optimised and converts well, particularly with accelerated payment methods. This is frequently the largest measurable gain.
Performance becomes more predictable. Not automatically faster — a bloated Shopify store is slow too — but the infrastructure is no longer your problem.
Apps install without breaking things. Usually. The isolation is better than plugin architecture.
Support exists. There is someone to ask.
What you give up: database-level control, unlimited customisation of checkout below Plus, and a percentage of revenue in fees. Those are real costs, not footnotes, and they are why the “should you migrate” question deserves a real answer.
The inventory nobody does properly
Most migration overruns trace back to something discovered late that should have been found in week one. Here is the inventory that prevents it, and the questions to ask against each item.
Every plugin, with a decision. Not a list — a list with a column saying “Shopify app X”, “rebuild”, or “drop”. Include plugins that only affect the admin, because someone relies on those workflows. Include anything a previous developer installed that nobody understands, because “we do not know” is a finding rather than a gap.
Every custom field, and where it displays. Product specifications, care instructions, materials, compatibility data, downloadable files. Each needs a Shopify metafield and a place in the theme to render. Fields that exist but display nowhere can be dropped, and identifying those saves real time.
Every content page, from a crawl rather than memory. Nobody remembers the landing page they built for a campaign three years ago that still gets 200 visits a month. A crawl does.
Every form and where its submissions go. Contact forms, wholesale applications, sample requests, newsletter signups. Each needs rebuilding and reconnecting, and forms that silently stop working after launch are a particularly expensive failure because nobody notices for weeks.
Every integration. Accounting, email marketing, 3PL, ERP, POS, reviews, loyalty, analytics, ad platforms. For each: does a Shopify connector exist, what data does it pass, and who will reconnect it? This is frequently the longest tail in the project.
Every automated email. Order confirmations, shipping notifications, abandoned cart, password resets, back-in-stock alerts. Some move with your email platform, some are platform-native and need rebuilding.
Your tax and shipping configuration, in detail. Rates, zones, rules, exemptions, and any product-specific logic. Shipping rules in particular often encode years of accumulated decisions that exist nowhere except the settings.
Discount codes, active and historic. Customers use old codes. Decide which continue to work.
Anything with a legal or compliance dimension. Privacy policy, cookie consent, accessibility accommodations, age verification, regulated product disclaimers.
A day spent on this inventory routinely saves a fortnight later. It is also the part clients most want to skip, because it produces no visible progress and reads like administration rather than work.
Mistakes we see repeatedly
Migrating and redesigning at the same time. Tempting, because you are already disrupting everything. But when traffic drops you cannot tell whether the cause was the platform change, the redirect map, or the new design — and each has a different fix. Migrate first, stabilise, then redesign. If the current design is truly unusable, accept the diagnostic cost knowingly rather than by accident.
Launching in peak season. Nobody plans this and it happens anyway, because projects slip. If your migration slides into your busiest trading period, delay it. The cost of waiting is much lower than the cost of discovering a checkout problem during your highest-volume week.
Not keeping the old site accessible. Take a full crawl and a full backup, and keep the old installation running somewhere private for at least a few months. You will need to check what something used to say, and reconstructing it from archives is slow and incomplete.
Trusting the import without checking the hard cases. Automated migration tools handle simple products well. Spot-check your most complex products, your longest descriptions, your products with the most variants, and anything with unusual characters or formatting. Those are where errors hide.
Forgetting that customers must reset passwords. No migration moves passwords. Customers will arrive, fail to log in, and either contact support or leave. Email them before launch explaining what to expect, and make the reset path obvious on the login page.
Skipping real test orders. Place actual orders on the live site at launch, with real payment methods, for several product types including any with unusual shipping or tax treatment. Then check the order flows through to your fulfilment and accounting systems.
Leaving staging indexable. A crawlable staging site competing with your new production site is an avoidable and irritating problem, and the fix takes one line.
The bottom line
The data is the easy part. The project is your plugin functionality inventory, your product architecture where Shopify’s limits bite, and above all your redirect map and SEO plan.
Crawl before you change anything. Inventory every plugin and decide its fate explicitly. Map every URL, not just products. Preserve your content and your metadata on pages that rank. Then monitor for ninety days.
Do those things and a WooCommerce to Shopify migration is a good decision that feels boring, which is what a successful migration should feel like. Skip them and you will spend a year recovering traffic you already had.
Frequently asked questions
How long does a WooCommerce to Shopify migration take?
For a straightforward store with a few hundred products, standard functionality, and a competent team, around six to eight weeks end to end — with the bulk of that going to auditing, rebuilding plugin functionality, and the redirect map rather than moving data. Complex stores take three to four months, particularly where custom pricing logic, product configurators, or subscriptions are involved. Be sceptical of anyone quoting two weeks for an established store: either they have not asked about your plugins and custom fields, or they are planning to skip the SEO work, which is where migrations fail.
Will I lose my search rankings when I migrate from WooCommerce to Shopify?
Not if the redirect work is done properly, though expect some volatility for two to four weeks while Google reprocesses your URLs. Sustained losses come from specific, avoidable mistakes: an incomplete redirect map, redirecting everything to the homepage instead of relevant equivalents, losing category and blog content during the move, and rewriting titles on pages that were ranking. The safeguard is crawling your entire site before you change anything, so you have a complete record of every URL and its performance to redirect against and verify afterwards.
What happens to my WooCommerce plugins?
None of them come with you, which is the largest hidden scope in most migrations. Each one needs a decision: a Shopify app that does the same job, custom development to rebuild the functionality, or accepting the loss. Inventory every plugin before scoping the project, including the ones you rarely think about, and be specific about what each actually does for the business. The problem areas are usually role-based or dynamic pricing, product configurators, custom shipping logic, membership features, and anything a previous developer built specifically for you.
Can I migrate my product reviews from WooCommerce to Shopify?
Usually yes, but it depends on where they currently live and which Shopify review app you choose, so establish the path before you commit to either. Reviews stored in WooCommerce natively or in a common plugin can often be exported to CSV and imported into a review app that supports it. They are worth the effort — they carry real conversion value and contribute review schema to your search listings — and they are one of the most commonly lost assets in migrations, purely because nobody checks the import path until after the switch.
Is Shopify actually cheaper than WooCommerce?
Rarely on paper, often in practice. WooCommerce software is free; hosting, security, backups, premium plugins, and developer time to keep it all working are not, and those costs are easy to underestimate because they arrive separately. Shopify charges a predictable monthly fee plus transaction fees, which are a real cost that scales with revenue. The honest comparison includes what you currently spend on maintenance and what your team’s time is worth. Stores spending most of their development budget on keeping things working usually come out ahead; stores with in-house WordPress expertise and a stable setup often do not.