WooCommerce to Shopify Migration Plan

You will find that most WooCommerce stores don’t so much collapse as they calcify. An hour before a campaign is set to go, a plugin update will put the checkout out of commission. The marketing team won’t dare touch the theme unless a developer is on hand. Variant pricing goes adrift because you have three extensions vying for the same field. The store is still processing orders, but it has begun to tax the business behind it.

That tends to be the point at which migrating to Shopify ceases to be a tech discussion and becomes a matter of business. You could ask which platform is superior in the abstract, but the more pertinent question is whether what you are expending to keep WooCommerce in shape has become more than the cost of walking away.

There is an honest way to frame this project that you won’t see in most agency copy. A move from WooCommerce to Shopify is part re-platform, part redesign. We have aggregated data from some 50 projects at APPWRK and can tell you that 78 per cent of shoddily executed migrations will see their organic traffic fall off in the first quarter or two; a badly handled site can lose 30 to 60 per cent and be a year in the making to put right. It is not the mechanical CSV transfer where things go wrong. It is the URL strategy, the subscription cutover, the plugin logic hidden in serialized PHP meta, and the data model mismatch.

What follows is a plan to deal with the project for what it is: a 6 to 14 week program for the mid-market store, one that requires you to make some hard calls before any data is moved.

When the move is the right call, and when it is not

For stores with custom workflows or an in-house dev, or where revenue is dependent on plugins with no Shopify counterpart, WooCommerce does its job. But B2B operations with deep VAT rules or margin-conscious subscription brands often come to rue the decision once the transaction percentages and recurring app fees are tallied. You will hear the same refrain in the cost shock stories on r/woocommerce and r/shopify. A lifetime $60 plugin in WooCommerce can turn into three separate apps on Shopify running you $10 or $20 a month apiece.

Then there are the merchants for whom the store has devolved into a maintenance exercise. If your hosting and security are a second job, or if operational overhead has outstripped what the store puts back, Shopify takes the drag out of it. WeArePresta’s 2026 portfolio figures put the typical reduction in overhead at 20-30 per cent after a clean cutover. It is an agency number, not a peer-reviewed study, but it rings true with teams we talk to.

Run this test: put down the five risks that keep you up at night about your current store. Are three of them to do with the platform? Then you should be planning a migration. If they are matters of content or merchandising, the platform isn’t your problem. For a better read on the tradeoffs, have a look at our WordPress vs Shopify comparison.

What actually transfers, and what does not

The sales pitch for these tools is that they will move everything. They will move most of it. The 10 to 20 per cent they leave behind is generally what is protecting your revenue.

Cart2Cart, LitExtension and the like will get your standard product fields and order history across without issue. But the work that nobody gives you a quote for comes from the structural differences between the two. WooCommerce keeps its data in WordPress post types and serialized arrays in the postmeta. A plugin like WooCommerce Subscriptions can have business logic in it that a CSV export will never show you.

Shopify is a lot more rigid. Its product and variant model has a hard limit of three options and relies on structured metafields with a set key and type. Say your product has size, colour, material and fit as variables – you can’t have all four as options in Shopify. You have to decide whether to combine attributes, break them into separate products or relegate one to a filtering metafield. That is a merchandising call.

There are three items the export screen will mislead you about.

Customer passwords. Shopify’s API won’t take the raw PHPass hash from WordPress. On launch every customer will need to reset or activate their account. Make sure support is briefed and the email sequence is in place before you cut over.

Subscriptions. You can’t port payment tokens and mandates into Shopify’s system. Your options are to let the old ones wind down on WooCommerce while you build new ones on Shopify, or to put together a re-enrollment campaign with some kind of incentive. Either way works. You make a mistake if you fold subscriptions into the data import and then find out about the shortfall on launch day.

Orders as live records. Once you have imported them, orders are historical artifacts. Any chargebacks, refunds or disputes on pre-migration business will remain with the original payment gateway and must be dealt with outside of Shopify. Make sure to put the legacy order ID in a metafield for each one; it is the only way your ERP, accounting and support staff can do their reconciling.

If you want to know what is feasible, the Shopify team has put together a decent reference in their migration documentation for the standard transfer paths. Study it and plan for the things you can’t do.

The plugin audit nobody wants to do

A WooCommerce store of any size will have 20 to 50 active plugins. On Shopify you might get by with 10 to 25 apps for the same end result. But the head count is not what matters. The issue is that plugin logic is domain knowledge you can’t see until you put it on paper.

Before you move any data, go through every plugin and write down the function it serves. I don’t mean the name of the plugin. “WooCommerce Advanced Custom Fields” is a name. “Stores fitment data for the category filter and product spec table to read from” is a job. You can rebuild the latter on Shopify, but you will miss the former.

Here is what a good working table should look like:

Should you come across a plugin you can’t sum up in a sentence, give it a closer look before the migration. That is where the tax exemption logic and B2B tiers are hiding. Failing to surface them now is how you end up with those “we didn’t realise this was a feature” Slack messages a couple of weeks in.

The SEO work is the work

Losing organic traffic to unmapped URL changes is the most predictable way a WooCommerce to Shopify move can go wrong. It is also entirely within your power to prevent.

WooCommerce permalinks are anything but rigid. You have /product/, /shop/, tag archives, custom slugs and old campaign URLs still pulling in visitors. Shopify is fixed in its ways with /products/handle or /collections/handle. You are not going to get a 1:1 match, so the redirect map is where you have to apply some judgment.

Your SEO plan needs to cover these five points at a minimum:

1. Crawl the whole site. Use Screaming Frog or Sitebulb to get every indexed URL from the live WooCommerce install. Not just the product and category pages but the blog posts, PDFs, image URLs and the like.
2. Classify them. Separate the money pages from the informational and low-value ones. Your 301 strategy will vary accordingly.
3. Build a mapping spreadsheet based on intent. A backlinked URL for a product you no longer sell ought to go to the relevant collection, not the homepage. If a category is gone, point it to whatever page now fills that role.
4. Put the redirects in place and test in batches well before you go live. And do not forget to explicitly recreate the Open Graph metadata, canonical tags and structured data from Yoast or RankMath on the new platform.

There is no migration on their part.

You should be monitoring Search Console for a good four to eight weeks post cutover. The data on impressions, indexing and crawl errors will point you to any redirects that require another look.

On this front the divide between a clean migration and a botched one is hard to miss. If you read what practitioners have been saying on X in 2025 and 2026, a well-prepared cutover might see a temporary 5-10% dip in organic traffic but it is back to normal in a matter of weeks. APPWRK’s numbers paint a different picture for those who rush: 30 to 60% in losses and three to six months of remediation work. Usually it comes down to whether someone had a firm grip on the redirect map before the launch date was set.

Then there is the question of your blog. You need to make a call before you go live. The way most people do it is to leave WordPress on a subdomain such as blog.yourstore.com if the content has SEO value, or put in the work to rebuild the best posts on Shopify with proper redirects from the old slugs. You could simply kill off the WordPress blog without porting anything over, but that third option is sure to take a toll on your long-tail traffic.

A realistic timeline

Founders want to know how long the migration will be. But the better question is how long it will take your team to come to a decision.

The agency benchmarks are fairly consistent across the sources we see:

• Data-only: 2-4 weeks, provided you have a simple catalog and no complex SEO history or custom checkout.
• Standard mid-market with some customization: 6-10 weeks to handle the plugin audit, URL mapping, QA and the like.
• Redesign and complex integrations on top of the migration: 8-14 weeks.
• Multi-brand or international replatforms: Anywhere from 3 to 9 months, typically in pilot waves.

Trying to do a non-trivial store in under 8 weeks is asking for trouble. We saw an agency on X talk about a year-long project for one complex shop; they did two weeks of domain modeling workshops before writing a line of code. An extreme example perhaps, but it makes the point: scoping takes more time than developers think and if you don’t do it you just move the cost elsewhere.

Within that schedule you have six tracks to run:

1. Business decisions and audit (SEO baseline, product structure, subscription strategy)
2. Staged dry-run imports and data mapping
3. Moving content and rebuilding the storefront
4. Testing your app replacements and integrations
5. Getting ready to launch with UAT scripts and payment verification
6. Training the team and watching things post-launch

Don’t let the technical side be the bottleneck, the decisions are. Who gives the nod on new navigation? Which customer fields are important? Do you archive or keep certain historical orders in Shopify? Whether a niche WooCommerce workflow is retired or rebuilt. Having one product owner with the authority to make those calls is what separates a migration that stays on schedule from one that doesn’t.

What launch week should look like

Ideally it is uneventful. Orders are coming in, operations isn’t after you for checkout bugs and support hasn’t been flooded with confused tickets. You get that by doing your dry runs in advance, not by trying to be a hero on the day of the launch.

You will find the cutover playbook to be something like this:

• Several dry runs in staging Shopify. We do a first pass on a subset for mapping validation, a second on the whole catalog for QA, and then a third as a delta migration right before we cut over.
• A hard content freeze on WooCommerce. During the final delta window there are no inventory edits, price changes or new products. Make sure merchandising is in the loop about the freeze before you even send the calendar invite.
• UAT scripts from end to end. The team that owns it in production should test every scenario: guest and registered checkouts, region-specific tax, shipping permutations, discount codes, refunds (partial and full), and subscription enrollment.
• Get your payment processor verified before launch. Non-US merchants have a habit of getting caught in identity verification loops with Shopify Payments. One Bulgarian operator on X put it best in early 2026 after two weeks of fighting rejections with perfectly good paperwork. Don’t wait.
• A DNS plan with names attached to it. There should be no ambiguity over who is flipping DNS, verifying SSL, watching the order feed or making the call to support if things look amiss.
• Rollback path on paper. You can keep the WooCommerce store online and have the steps bookmarked to point the domain back. It is an operational move, not a rebuild.
• Support has been briefed. They need their scripts for password resets, account activation, missing order history and any policy shifts associated with the new store.

Then there are parallel or dark launches to further mitigate risk. Put Shopify on a temporary domain and run some real traffic through it to see if the transactions hold up; only flip DNS when the numbers are what you expect. Heinz did it in 2020, launching its “Heinz to Home” store in seven days with a limited set of SKUs and then growing from there. It is an MVP pattern that most brands coming from WooCommerce can use, multi-brand retailers and those with an international footprint in particular.

Costs the proposal won’t show you

On the surface you have the migration project, the new app stack and the Shopify subscription. But the hidden costs are in your own team.

Merchandising will put in days to validate variant structures and collections. Operations is testing warehouse integrations and tax settings. Finance has to make sense of legacy order IDs and historicals. Support is fielding the ticket volume and writing new scripts while marketing is over the landing pages and campaign links. Bring them in late and the project drags or you have gaps at launch. Get them involved early and the timeline is honest, the launch is calm.

App costs are another matter. What was a $60 plugin in WooCommerce may well be three apps at $15 a month in the Shopify market. Once you factor in developer retainers and managed WordPress hosting, the total cost of ownership tends to favor Shopify if you are doing $500K to $1M in GMV a year or more. Under that it is a question of how many apps you can do without. We recommend a pre-launch rule: every app needs an owner and a renewal review.

How good partners approach it

There is a difference between the migrations that work and the ones you tell as cautionary tales. A good team will treat it as a program with a phased scope and locked decisions, with one product owner calling the shots across tech, UX and ops.

Refact’s work is a case in point. Our five-year Broya partnership on Shopify began with the sort of structural work you read about here: we clarified the subscription model before we got to the storefront and improved conversion in increments. Over on the WooCommerce side, the NudFud build was an exercise in designing product structure and fulfillment rules in tandem. A migration is much the same thing, in reverse.

For a closer look at the platform choices that come after the move, our Shopify development guide covers theme selection and app governance. Or see the ecommerce migration services overview for the phases in detail. And if you are doing the import work yourself, follow the Matrixify WooCommerce to Shopify workflow. In particular, use read-only API credentials for extraction and do a dry run with the transformation preview. Those two habits alone will save you days.

The decision to make before you write any code

Moving from WooCommerce to Shopify is seldom a simple yes or no. It is a series of judgments on URL strategy, plugin logic, product structure and which old data you want to carry forward. The store that gets migrated by a lone developer and a CSV on a Friday night is the one that makes for a recovery story. The one handled as a six-track program with named owners is the one that is quietly outperforming the old system by month two.

If you are considering the move and want the scoping done right before anyone opens a theme, Refact’s data migration discovery is meant to settle the questions raised in this article. We put a money-back guarantee on the strategy because the real risk is in the early thinking. Once you have that sorted, the build is the easy part.