WooCommerce to Shopify Migration Without Losing SEO or Revenue

We build and run Shopify stacks for a living, which means a WooCommerce to Shopify migration shows up on our desk on a regular basis.

Every one of them has a build side that gets scoped properly: the theme and the design system, the catalog and its data mapping, the apps that have to replace your plugins, payments, shipping, tax, and the QA pass over all of it. That work is real, it’s most of the hours, and it isn’t what this piece is about.

Running underneath it is a second workstream that rarely appears on the project plan: everything that has to survive the WooCommerce to Shopify migration. Your URLs and the rankings attached to them. Your review corpus and the stars it puts in the search results. Your Merchant Center matching.

Your analytics history. Your customer accounts. None of it is technically hard. All of it fails quietly.

The build side of a WooCommerce to Shopify migration has an owner and a launch date. The preservation work usually has neither, which is why it tends to get discovered after cutover instead of before. That’s the half this piece covers, and the order below is roughly the order it should get done in.

Here’s the sourcing standard for everything below: every number, price, threshold, or limit carries an inline link to where it came from. Vendor documentation is treated as authoritative for how that vendor’s own product behaves, and as a marketing claim the moment it describes an outcome. Google’s own documentation is the strongest evidence available, and we name it every time we lean on it. We won’t re-flag this on every paragraph after this one, but we’ll call out the specific places where a claim is thinner than it looks.

Start here, because this single fact determines which Google documentation governs your WooCommerce to Shopify migration and how much redirect work you’re actually signing up for.

Shopify’s storefront paths aren’t configurable. Shopify’s own help documentation states it plainly: “You can’t edit subdirectory names. Regardless of what domain you’re using, the subdirectory names remain the same,” naming /collections, /products, and /pages as the fixed examples. A product’s address on Shopify is always /products/ plus a handle, and that subdirectory name isn’t editable.

WooCommerce, by default, doesn’t use that structure. Its documented default product base is product, producing URLs like example.com/product/hoodie-with-logo, and its default category base is product-category (WooCommerce permalinks documentation). Some stores run a “Shop base” permalink instead, which puts products at example.com/shop/hoodie-with-logo, or a fully custom base. None of those match Shopify’s fixed structure, so no WooCommerce URL survives the migration unmapped.

Can I keep my old URLs on Shopify? No. Shopify’s subdirectory names are fixed regardless of what domain you’re using, so every product and category URL changes by definition. Every URL needs a redirect, not a preserved path.

Is a WordPress to Shopify migration the same thing? Nearly, and the difference is worth scoping. WooCommerce is a WordPress plugin, so a WooCommerce to Shopify migration is a WordPress to Shopify migration plus a product catalog, a customer list, and an order history. If you’re on WordPress without WooCommerce, everything here about blog paths, category and tag archives, author archives, attachment pages, and Yoast or Rank Math metadata still applies, and you can skip the catalog, discount, and subscription sections entirely.

That single fact puts a WooCommerce to Shopify migration squarely inside Google’s “site move with URL changes” documentation, not the much gentler “site move with no URL changes” doc that applies when you’re only changing hosting. Every product page, every category page, and depending on your permalink settings, potentially your entire blog changes address on the same day. Google’s redirect documentation is worth reading before you touch anything else, because it names your destination platform directly: “If you’re using a platform like Blogger or Shopify, the platform may already have built-in redirect solutions” (Google Search Central, redirects).

We won’t restate the general non-negotiables of a safe platform move here. Our migration principles post is the baseline law that applies to any platform pair. Everything from here is specific to a WooCommerce to Shopify migration.

If you’ve been researching a WooCommerce to Shopify migration, you’ve probably seen a number attached to how long recovery takes, or how much traffic a migration typically costs you. We checked those numbers against their claimed sources. None of them held up.

The alarming figures that circulate in this space, a percentage of SEO value lost, a share of migrations that fail outright, a recovery window measured in months, trace back to agency landing pages and listicles with no underlying study, no sample, and no method attached. They get repeated because they’re alarming, not because anyone measured them. We couldn’t find a published dataset of migrations segmented by source platform and destination platform. If a migration-loss percentage shows up in a sales conversation, ask where it came from.

Google’s own site-move documentation says this twice on the same page: “a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer,” and separately, “a small to medium-sized website can take a few weeks for most pages to move” (Google Search Central, site moves with URL changes). Google gives no month figure anywhere in that document. There’s no official multi-month recovery figure anywhere in it. “A few weeks for most pages” is the strongest, most specific wording Google publishes.

Google gives the point its own section heading on that page, “Expect temporary fluctuation in site ranking during the move,” and explains it directly underneath:

On link equity specifically, Google is unambiguous: “Don’t worry about link credit. 301 and other permanent redirects don’t cause a loss in PageRank” (Google Search Central, site moves with URL changes). That directly contradicts the widely repeated claim that redirect chains cost you a fixed percentage of link equity per hop. No Google document we could find states a decay figure like that.

The honest answer is that Google tells you to expect a few weeks of fluctuation on a well-executed move, that redirects don’t cost you link equity, and that nobody has published a credible number for what a botched WooCommerce to Shopify migration specifically costs. Nobody can honestly quote you the odds, which leaves execution as the variable you actually control.

You can’t prove what a WooCommerce to Shopify migration cost you if you never recorded what you had. Skip it and every post-launch traffic conversation becomes an argument with no evidence in it.

Shopify’s own Core Web Vitals reporting has a short memory. The web performance report is built from real user data and explicitly states, “Web performance data is available for only the last 90 days,” and that “the data in this report might be delayed by up to 36 hours” (Shopify, web performance reports). That’s a Shopify limitation, and it means the pre-migration state of your WooCommerce store lives nowhere Shopify will show you after cutover. You have to capture it deliberately, before you move.

The same problem exists on the Google side. Search Console’s Core Web Vitals report pulls from the Chrome UX Report, and “only indexed URLs can appear in this report” (Google, understanding the Core Web Vitals report).

CrUX is a rolling field dataset tied to specific, already-indexed URLs. The moment your URLs change, that URL-level history doesn’t transfer. Your new Shopify URLs start with no field data of their own, regardless of how fast the new store actually loads.

That’s why a real pre-migration baseline is three things, captured before staging even begins: a full crawl and indexed-URL inventory of the live Woo site, a Core Web Vitals snapshot at the field-data thresholds Google actually uses (LCP within 2.5 seconds, INP at 200 milliseconds or less, CLS at 0.1 or less, all measured at the 75th percentile), and a ranking and revenue-by-landing-page export. Without that snapshot, “did the migration hurt us” becomes an argument with no evidence on either side. A technical SEO audit is exactly this kind of exercise, and a Core Web Vitals benchmark run before the build starts is the difference between having a before-and-after and having only an after.

That a WooCommerce to Shopify migration needs 301 redirects is the easy part to know. Building the map is the actual work, and one specific Shopify rule breaks the naive version of it before you start.

Shopify’s redirect documentation states the constraint directly: “You can redirect only from broken URLs. Broken URLs display error messages, such as Page not found or 404” (Shopify, URL redirects). If a source path still resolves to something on the new store, whether by coincidence or because a theme or app is serving content there, it isn’t broken, so the redirect you set up for it never fires. This is the single biggest way a WooCommerce to Shopify redirect map fails silently.

Depending on your WooCommerce configuration, a Shopify migration means mapping several distinct patterns, not just products:

Two of those deserve sourcing. The /shop/ page is one of four pages WooCommerce creates on install, distinct from the category archives (WooCommerce, default pages). The category and tag bases are documented by WordPress as things you “can’t remove from the URLs altogether” (WordPress, customize permalinks), and attachment pages exist because WordPress “automatically generates a new web page, containing only that image” for every upload (Yoast, media pages settings).

What happens to my blog? Blog content has no CSV import path on Shopify, only apps or the Blog API, and your post URLs move from WordPress’s date or category-based structure to Shopify’s blog path format. Both the content transfer and the redirect map need separate planning from the product catalog.

Variation URLs deserve a separate note. A WooCommerce product variation doesn’t get its own clean path.

WooCommerce’s own code reference documents WC_Product_Variation::get_permalink() as a wrapper that “adds this variations attributes to the URL” on top of the parent product’s address (WooCommerce developer reference). Google’s ecommerce URL guidance recommends that when optional query parameters identify variants, “use the URL with the query parameter omitted as the canonical URL” (Google, designing a URL structure for ecommerce). Don’t spend redirect budget mapping variant parameters one to one.

Here’s how a simplified version of that map looks once you’ve built it:

Once the map exists, the mechanics are straightforward. Shopify redirects are 301s (“301 redirects are cached by browsers and search engines,” per Shopify’s documentation), bulk-importable through a CSV with exactly two columns, Redirect from and Redirect to (Shopify’s sample redirect template). Standard plans cap out at 100,000 redirects; Plus goes to 20,000,000 (Shopify, URL redirects). A handful of prefixes can’t be used as a redirect source at all, including /apps, /cart, /orders, and notably /shop, which happens to be one of WooCommerce’s own permalink base options (Shopify, URL redirects).

On chains, follow Google’s guidance directly rather than your instinct to redirect through a convenient waypoint: “Avoid chaining redirects. While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects, we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5” (Google Search Central, site moves).

Redirects don’t appear in Shopify’s own migration data matrix at all, which is exactly why a third-party tool ends up in most WooCommerce migration projects. Matrixify’s entry paid tier, listed at “$20 / 30 days” as of August 2026, caps out at 10,000 redirects, well below Shopify’s own 100,000-redirect plan ceiling; the “$50 / 30 days” tier reaches the full 100,000 (Matrixify pricing). For a mid-catalog Woo store, the redirect count, not the product count, is what pushes you into the higher tier.

Verify the map before and after the WooCommerce to Shopify cutover with a real crawler rather than trusting the CSV import screen. Google names Screaming Frog in its own troubleshooting guidance, suggesting you “use other tools such as Screaming Frog to crawl your own site” (Google Search Central, site moves). Its All Redirects report, run in list mode against your old URL inventory, returns Chain Type, Number of Redirects, Redirect Loop, Temp Redirect in Chain, and Final Status Code for every URL you feed it (Screaming Frog, auditing redirects). That’s how you catch the failure Google names first, which is people “redirecting to the wrong (non-existent) URLs on the new site,” before Googlebot does.

This is the point in the project where most site owners realize the redirect map alone is a real body of work, before revenue continuity even enters the picture. It’s also exactly the discipline that our SEO migration work exists to handle as its own workstream, separate from the store build itself, and it’s a large part of what we cover end to end in a managed WooCommerce to Shopify migration.

This part of a WooCommerce to Shopify migration happens before cutover: controlling what Google can and can’t see while you’re still building.

A Shopify store behind a password is invisible by design. With a password page active, “Search engines find and display only the password page of your online store.

Other pages, such as product pages, are hidden and aren’t displayed in search results” (Shopify, password page). Your sitemap is unreachable under a password too: a sitemap reader “can’t access it if your website is password protected” (Shopify, finding your sitemap). That’s good news for avoiding premature indexation of a half-built store, and it comes with a real limitation: you can’t pre-validate how the new store will index before you take the password off.

If you need finer control than the password page gives you, robots.txt is customizable through a robots.txt.liquid template, but Shopify is explicit about the risk: it calls this an “unsupported customization,” states “Shopify Support can’t help with edits,” and warns incorrect changes can cause “loss of all traffic” (Shopify, editing robots.txt). Noindex isn’t a setting either.

It’s a theme edit, pasted as Liquid into theme.liquid (Shopify, hiding pages from search engines). Both are real tools. Neither is something to touch casually, and both are the kind of migration-only change Google explicitly warns people forget to remove: “remove any noindex or robots.txt blocks that were only needed for the migration” is on Google’s own list of named post-move mistakes (Google Search Central, site moves).

Google’s best post-cutover instrument is the two-sitemap method, and it’s worth setting up deliberately rather than discovering by accident: “Submit the two sitemaps you saved earlier from the mapping. Initially, the sitemap containing the new URLs would have zero pages indexed, while the sitemap of the old URLs would have many pages indexed. Over time the number of pages indexed from the old URLs sitemap would drop to zero with a corresponding increase of indexing of the new URLs” (Google Search Central, site moves).

Submit both. Watch the numbers trade places. That’s your real-time confirmation that Google is treating this as a move, not a disappearance.

Everything above is measurable in Search Console. The losses below aren’t. They show up in a P&L, weeks later, and they’re the ones a launch checklist is worst at catching.

This one is simple, underreported, and guaranteed to affect every customer account you have. “Because passwords are encrypted outside of Shopify, you can’t migrate customer passwords from another online store using a CSV,” and Shopify’s own guidance is that you “need to invite your customers to create new passwords so that they can register their accounts” (Shopify, importing and exporting customers). Treat this as an email deliverability event, not a footnote: every returning customer needs a reset email that lands, gets opened, and doesn’t read like a phishing attempt.

Shopify’s own migration documentation is blunt: “You can’t export or migrate reviews from WooCommerce to Shopify” (Shopify, migrating from WooCommerce). That sentence is true, and it describes native WooCommerce reviews rather than the third-party review platform most real stores actually run. What matters for those stores is what happens when a purpose-built review app has to re-match its corpus to a completely new set of product IDs.

That question breaks at three specific, well-documented joints.

The first is product identity, and it’s the one that costs the most because it fails silently. Stamped states the requirement most plainly of any vendor here: “Product IDs must be platform-generated IDs (not SKUs, handles, or URLs),” and “Reviews cannot be migrated without a valid product ID mapping” (Stamped, migrating reviews between platforms). Judge.me documents why this trips people up: “product identifiers differ between WooCommerce and Shopify,” and if you skip the manual mapping step, “if a product isn’t mapped, its reviews will be imported as store reviews instead” (Judge.me, migrating reviews to Shopify). Yotpo documents the identical mechanism in its own words: “If the Product ID value is empty, the review is treated as a site review” (Yotpo, importing reviews).

The import doesn’t error. It reports success. The reviews exist somewhere in the account. They just aren’t attached to the product anymore, so the product page shows zero, and nobody notices until a customer asks why the five-star product they remember buying looks unreviewed.

There’s a mechanical trap that makes this worse. Shopify product IDs are long enough that spreadsheet software silently converts them to scientific notation, and Stamped warns this “will lead to the reviews not being assigned to the correct products” (Stamped, common import issues), a trap Junip warns about independently in its own import documentation (Junip, custom import template). That’s not a failure to import, it’s a misassignment, which is arguably worse because it looks like it worked.

Loox is the notable exception in this landscape. It matches primarily on the Shopify product handle, “the last part of the product URL (after /products/)” (Loox, importing reviews with a custom file), which means preserving your product slugs from Woo into Shopify is a review-corpus decision, not just a redirect decision.

REVIEWS.io matches on SKU, and its own documentation on unmatched SKUs describes exactly what happens when SKUs drift during a migration (REVIEWS.io, unmatched SKUs), with the added constraint that its imports are only available “within the first 90 days of your REVIEWS.io account” and allow “one import per review type” (REVIEWS.io, importing reviews). That’s a one-shot window. Getting the SKU mapping wrong the one time you’re allowed to run it isn’t trivially reversible.

The second joint is verified-buyer status, and it has a real downstream cost. Judge.me states plainly that “reviews imported from your Judge.me account on WooCommerce won’t be verified in your Judge.me account on Shopify,” and separately, “imported reviews won’t appear in your Google Shopping product reviews feed” (Judge.me, migrating reviews to Shopify). Google’s own Merchant Center requirement is “a minimum of 50 reviews across all of your products” to display product ratings at all (Google Merchant Center, product ratings). Put those two facts together and you get a specific outcome: a store that migrates its entire review corpus can keep every star on its own product pages and still fall below the 50-review floor in Merchant Center, losing star ratings in Google Shopping entirely, and quietly.

The third joint is theme-resident structured data, and it’s the easiest to forget because it isn’t stored in the review app at all. Okendo’s widgets require an App Embed toggle turned on in the Shopify theme customizer, and “failing to do this means your widget will not appear” (Okendo, installing on Online Store 2.0). Judge.me documents the same category of failure from the other direction, naming a theme “overwriting or blocking” the product schema as a known cause of missing rich snippets, alongside the requirement that the review widget be installed on the product page (Judge.me, displaying product ratings in Google Search results).

Google’s own rule is unforgiving on this point: “It must be immediately obvious to users that the page has review content,” and “if you marked up reviews, users should be able to see the text of the review and associated rating” (Google, review snippet structured data). A new theme is guaranteed on a WooCommerce to Shopify migration. Reinstalling the widget and re-verifying the schema isn’t optional cleanup. It’s how you avoid shipping structured data that claims a rating your page no longer displays.

Judge.me discontinued its app on non-Shopify platforms, listing WooCommerce’s sunset date as “31 October 2025 (accessible until 19 November)” and stating “We have now sunset Judge.me on all non-Shopify platforms” (Judge.me, sunsetting on WooCommerce and others). Judge.me still publishes a WooCommerce-to-Shopify migration article describing a support-request export, and the sunset notice also says that after the date “access to all Judge.me functionalities and data will be permanently removed.” We couldn’t resolve which of those governs for a merchant asking today, and that unresolved tension is itself the argument: export your review corpus early and independently, before you need it, not on migration day.

One vendor claim is worth flagging as a claim rather than a fact. Cart2Cart’s Shopify App Store listing advertises migrating “products, customers, orders, reviews, and more” (Cart2Cart, WooCommerce import listing), which sits in direct tension with Shopify’s own statement that reviews can’t be migrated from WooCommerce. That’s a vendor claiming more than the platform documents, and it’s exactly the kind of gap you want to test before you trust it with your corpus.

The pattern above is bigger than reviews. Merchant Center’s matching logic prefers GTINs first, and falls back to “SKU (Stock Keeping Unit), Brand + MPN (Manufacturer Part Number) pairs, and product URLs” when a GTIN isn’t available, with the explicit warning that those fallbacks “generally don’t offer as good a match as GTINs, which can lead to reviews not being matched to products” (Google Merchant Center, product ratings). A WooCommerce to Shopify migration changes every product URL by definition, which resets one of those three fallback signals at precisely the moment the others are under the most stress. Google also requires that “the domains in the product_url of the review data source must match the registered domain in your Merchant Center account” (Google Merchant Center, product ratings), which matters directly if your Shopify move also touches your domain or subdomain structure.

Shopify documents a self-referral problem that’s the direct analog of the old PayPal-referral bug WooCommerce stores know well: “if a customer enters the checkout and then returns to your online store to continue shopping, then the checkout page might be listed as a source,” and the recommended exclusion list is your store’s primary domain, checkout.shopify.com, shop.app, and external payment providers such as paypal.com (Shopify, excluding referrer domains). The shop.app entry is new to you. Woo stores never had it as a self-referral source. It’s worth adding to your exclusion list on day one rather than discovering three weeks of inflated referral traffic that’s actually your own checkout.

Migration isn’t only an SEO event, it’s a revenue event, and it’s worth modeling what the underlying performance work is actually worth in your funnel rather than treating any of this as a cost center to minimize.

Skip this section if you don’t, which is most stores. For the ones it does apply to, this is the largest single thing that can go wrong on cutover day, and WooCommerce’s own documentation concedes it up front. Because “a subscription agreement is linked to a product, customer, payment gateway and potentially one or many orders, migrating a subscription can be rather difficult” (WooCommerce, migrating subscribers). The asset that has to move isn’t the card number, it’s the token: WooCommerce Subscriptions needs “customer payment method data, like a credit card token, in order to link the subscription with the payment gateway” (WooCommerce, migrating subscribers).

WooCommerce’s documented fallback for when tokens can’t move is to create the subscription with “an invalid customer token for a valid payment gateway” so that “the first renewal payment after the import will fail and the failed payment handling process is initiated” (WooCommerce, migrating subscribers). The official answer, in other words, is to intentionally break the customer’s next charge and then chase them to fix it. That’s not a migration bug. It’s the documented plan.

On the Shopify side, moving actual card numbers is gated behind plan tier: “Migrating credit card primary account numbers (PANs) requires your store to be on the Shopify Plus or Enterprise plan” (Shopify, migrating payment methods), a plan that starts at $2,300 per month as of August 2026 (Shopify pricing). For stores that can’t or won’t go to Plus, Shopify documents a slower alternative, in which “customers update their billing information” and “their payment methods move from the secondary gateway to the primary gateway” (Shopify, migrating payment methods). That’s a real path, and it means your store runs two gateways in parallel until customers re-enter their details, on their card-expiry schedule rather than yours.

If you’re weighing whether Plus is the right target in the first place, especially for a B2B or wholesale operation outgrowing WooCommerce and weighing a Shopify migration, that decision belongs earlier in the process than the migration mechanics covered here.

Some things have no clean path from WooCommerce to Shopify, and knowing that in advance saves a lot of frustration on launch day. Each item below is sourced in the paragraph that follows it.

Each of those deserves its source. Shopify’s migration matrix lists historical orders as available through “migration apps, Order API, Transaction API” only, lists blogs and pages the same way, and warns that on import “any staff member” set to receive order notifications “will receive a new order email for each imported order” (Shopify, CSV migration). The options cap is explicit: “Shopify only allows for 3 product options” and “Products with greater than 3 options won’t have their options imported” (Shopify, migrating from WooCommerce).

WooCommerce supports three coupon types with granular restrictions like minimum spend, excluded sale items, and per-user usage limits (WooCommerce, coupon management), while Shopify’s native discounts cover amount-off, buy-X-get-Y, and free shipping, with tiered or custom-eligibility logic requiring apps (Shopify, discount types). Yoast’s settings export covers site option groups only, and a per-post CSV of SEO titles and descriptions is a Premium feature (Yoast, import and export tools); Rank Math’s settings export excludes post metadata, and the CSV carrying seo_title, seo_description, canonical_url and schema_data per post is PRO-only (Rank Math, editing SEO meta at scale). And the free core WooCommerce CSV tool covers products, with customers, orders, and coupons requiring the paid Customer / Order / Coupon Export extension (WooCommerce, Customer/Order/Coupon Export).

Google’s guidance on when to run a WooCommerce to Shopify migration is specific enough to plan around directly. Small and medium sites should move “all URLs on your site simultaneously instead of moving one section at a time,” because it “helps our algorithms detect the site move and update our index faster” (Google Search Central, site moves). Don’t stage a partial cutover hoping to de-risk it. If you’re a small or medium site, which covers most WooCommerce stores, a clean single cutover is the lower-risk option, not the higher-risk one.

Pick your window deliberately. Google’s own advice is to “time your move to coincide with lower traffic, if possible. If your traffic is seasonal or dips on certain weekdays, it makes sense to move your site during the recurring traffic dips” (Google Search Central, site moves).

Google also warns that after a migration it “will crawl your new site more heavily than usual” and to “Ensure that your new site has sufficient capacity to handle the increased traffic from Google” (Google Search Central, site moves). On a Shopify destination there’s no server for you to provision, so the practical version of that warning points backward: your old WooCommerce host still has to serve every redirect under a heavier-than-usual post-migration crawl. Don’t downgrade or decommission it on cutover day.

One misconception worth killing outright: don’t reach for Search Console’s Change of Address tool. It exists for domain moves only.

Google states this without ambiguity: “The Change of Address tool can be used only on properties at the domain level,” and “You cannot move properties at the path level” (Google, using the Change of Address tool). If you’re keeping your domain, which most WooCommerce to Shopify migrations do, this tool doesn’t apply to you. A same-domain WooCommerce to Shopify migration is governed entirely by the redirect map and the site-move documentation covered above.

Google’s step 5 is to “monitor the traffic on both the old and new URLs,” verifying every domain and subdomain variant separately in Search Console (Google Search Central, site moves). Because migrating from WooCommerce to Shopify changes every path shape at once, start that on day one and know what you’re looking for.

Google names its own most common post-move failures by title, and they’re a genuinely useful checklist to run against your own launch: incorrect redirects, other crawl errors, insufficient server capacity, and not updating sitemaps (Google Search Central, site moves). A normal dip looks like fluctuation across many URLs while the index catches up.

Google’s “few weeks” language describes how long it takes most pages to move in the index, not how long your traffic line stays down, and Google publishes no recovery figure at all. You’re watching for direction, not a date. A broken migration looks like a spike in not-found errors in Search Console that doesn’t shrink week over week, or a sitemap of new URLs that never climbs off zero indexed pages while the old sitemap never drops.

Google also recommends keeping your redirects in place “for as long as possible, generally at least 1 year,” because that “allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs,” and adds that from a user’s perspective you should “consider keeping redirects indefinitely” (Google Search Central, site moves). Redirects aren’t a launch-week artifact to clean up later.

How do I actually test that the migration worked? Crawl your old URL list in list mode and confirm every URL resolves to a 301 rather than a 404. Submit both your old and new sitemaps in Search Console and watch indexed counts trade places over the following weeks. Compare your Core Web Vitals field data once there’s enough traffic on the new URLs to be meaningful, against the baseline you captured before you moved.

This is the discipline behind our 90-day post-launch monitoring window: watching indexed-URL counts trade places between the old and new sitemaps, tracking the redirect map for anything silently failing the broken-URL rule, and treating a wide gap between launched and confirmed working as the default assumption rather than the exception. Once the dust settles, the work shifts into ongoing ecommerce SEO: variant URL hygiene, collection page structure, and the duplicate-content questions a new platform introduces that the old one never had.

If your rankings have already slipped and it wasn’t from a recent migration, that’s a different problem with a different fix, and we’ve written about what recovery looks like for a site in gradual decline.

Shopify’s own documentation lays out an honest escalation ladder for how complex a WooCommerce migration gets: manual copy and paste, then CSV export and import, then a migration app from the Shopify App Store, then hiring a Shopify Partner, then custom API solutions (Shopify, migrating to Shopify). Most WooCommerce stores of any real size land somewhere between the third and fourth rung, and the honest answer to “can I do this myself” depends entirely on how many of the items in this piece apply to your store.

If you want to migrate WooCommerce to Shopify yourself, and you run a small catalog, no subscriptions, and native reviews you don’t care much about, the CSV path plus a redirect tool covers most of it, and a competent DIY effort with a crawler and a spreadsheet is realistic. If you’re running a third-party review platform with hundreds of products, active subscriptions, and a Merchant Center feed that matters to your paid budget, you’re weighing every item in the revenue-continuity section above against your own team’s bandwidth to execute all of it correctly, once, with no do-over on the parts that only run one time. That’s the actual decision, not “is Shopify hard to use.”

Cost is part of that calculation too. As of August 2026, Shopify’s own published pricing looks like this:

That’s from Shopify’s own pricing page, and the plan-tier arithmetic is worth doing yourself before you pick a target plan. This next part is our own math off those published list prices: on Basic, a store that keeps a third-party payment gateway pays a 2% Shopify surcharge on top of whatever that gateway already charges, so on a $60 order that surcharge alone is $1.20 before the gateway’s own cut. Moving to Shopify Payments removes that surcharge but resets your card rate to 2.9% plus 30 cents.

Which is cheaper depends on your gateway’s own published rate, which we don’t have and won’t guess at, but the comparison is worth running against your actual processor before you commit to a plan. There’s no verifiable published figure for what WooCommerce hosting costs, so there’s no honest total-cost-of-ownership comparison to offer here between the two platforms. Anyone who hands you one is doing math with an input that doesn’t exist publicly.

What does a WooCommerce to Shopify migration cost? Shopify’s own plan pricing starts at $39/mo for Basic as of August 2026, with Plus starting at $2,300/mo for stores that need Plus-only capabilities like card-number migration for subscriptions. Beyond the platform fee, cost depends on catalog size, redirect volume, and whether you’re paying for a migration app tier, a partner, or both. There’s no verifiable public figure for what your current WooCommerce hosting costs, so a fair total-cost comparison isn’t something anyone can offer without your specific numbers.

What tends to tip the decision toward a migration agency rather than a DIY effort isn’t the product export. It’s everything downstream of it: the redirect map at real catalog scale, the review corpus re-matching, the subscription contract recreation, and the monitoring window that catches what the launch checklist can’t. If that’s the shape of your store, have us run the migration end to end rather than discovering the gaps in this piece one at a time, after they’ve already cost you something.

None of the work above is the hard part of a WooCommerce to Shopify migration. The theme, the catalog mapping, the app replacements, and the QA are harder, and your build team already knows it owns them. The preservation work is easier and it goes wrong more often, because easy work with no name on it’s the work that doesn’t get done.

So give it a name and a date. Capture the baseline before the build starts.

Own the redirect map as a deliverable rather than a launch-day task. Decide who is re-matching the review corpus and who is watching Merchant Center in the weeks after. That’s the entire difference between a WooCommerce to Shopify migration that costs you a few weeks of fluctuation and one you’re still explaining next quarter.

If your store is small and clean, you now have the method, sourced, to run this yourself. If it’s carrying real subscription revenue, an established review corpus, and a catalog large enough that the redirect map alone is a serious project, we run WooCommerce to Shopify migrations end to end, revenue-continuity work included. If you want a second opinion on where your current store stands before you commit to a date, start with a free visibility audit.