You migrate a WooCommerce store without losing sales by protecting three things at once: the product and category URLs, the product data and its structured markup, and the checkout flow. Map every store URL to a 301, move each product with its images and schema intact, and test checkout end to end on staging before you switch. WPBuildAI runs store migrations this way, verifying the redirect map and a test purchase before cutover, so neither rankings nor revenue dip. A store is higher stakes than a brochure site, because a broken product URL is a lost ranking and a broken checkout is a lost sale.
The rule for stores: nothing goes live until a real test order completes and every product URL resolves.
What makes a store migration different
A content site risks rankings. A store risks rankings and revenue. WooCommerce adds product pages, category and tag archives, parameter URLs from filters, the cart and checkout, payment and shipping integrations, and customer accounts and order history. Each is a place something can break, and two of them, product URLs and checkout, map directly to money.
That is why a store migration is mostly verification. The build is the easy half.
What has to move, and the risk in each
Every element below needs a plan, not just the catalog.
| Store element | Why it matters | Migration risk | Verdict |
|---|---|---|---|
| Product and category URLs | Hold rankings and backlinks | High, structure often changes | 301 every one, no exceptions |
| Product data and images | The page Google and buyers see | High, many fields and assets | Migrate 1:1, re-link images |
| Product structured data | Drives rich results in search | Medium, easy to drop | Rebuild the schema |
| Checkout and payments | Directly equals revenue | High, integration heavy | Test a real order before launch |
| Customer and order data | Trust and continuity | Medium, sensitive | Plan the export carefully |
The pattern: product URLs and checkout carry the money, so they get the most verification. WPBuildAI proves both work before the switch rather than discovering a problem from a drop in orders.
Protect product rankings with redirects and schema
Product and category pages rank and earn backlinks, so every old URL must map to a 301 redirect to its new equivalent, exactly as Google describes for a site move. Filter and parameter URLs need a deliberate decision rather than a blanket redirect. Rebuild the product structured data so price, availability, and review rich results survive, since those snippets drive clicks. The signal-by-signal detail sits in the same discipline as any move; the deeper explanation of why 301s carry rankings is in do 301 redirects preserve SEO.
Protect revenue with a real checkout test
Rankings are half the risk; the other half is the buy button. Before cutover, place a real test order on staging through the live payment path, confirm the confirmation email, tax, and shipping calculations, and check the cart on mobile. Migrate customer and order history with care, since it is sensitive data. Only then switch. For the overall move sequence this fits into, see how to migrate a WordPress site to Lovable.
For example, a store that verified a full test purchase and all product redirects before launch cut over on a quiet evening with zero lost orders, because nothing reached customers until it was proven.
What has to be exported before you touch anything?
Seven things, and most of them cannot be recovered from the public site once the store is switched off.
| What to export | Why it cannot wait | Where it lives |
|---|---|---|
| Full order history | Legal and accounting obligations | Orders screen, CSV export |
| Customer records | Accounts, addresses, consent state | Users and customers export |
| Product data with variants | SKUs, prices, stock, attributes | Products export |
| Product images with filenames | Filenames drive image URLs | Media library |
| Coupons and their rules | Conditions are invisible on the public site | Marketing settings |
| Tax and shipping rules | Rebuilt wrongly, they cost money quietly | Store settings |
| Payment gateway configuration | Keys and webhook endpoints | Gateway plugin settings |
Order history is the one that catches people. It is a business record with retention obligations attached, and it does not need to live on the new store, but it does need to exist somewhere you can search.
Which store URLs get missed most often?
The generated ones, because nobody wrote them and so nobody remembers them.
Product category pages come first, including nested ones, since these often rank for the broad terms that bring in new customers rather than returning ones.
Filtered and sorted variants come second, addresses carrying attribute or price parameters that got indexed at some point.
Then paginated category pages, which carry crawl paths to products deep in the catalogue. Attachment pages for product images, which WordPress creates by default. Tag pages if the store used them. And the account, cart, and checkout URLs, which do not need rankings but do appear in bookmarks and old emails.
A store with 300 products routinely produces 2,000 or more addresses once these are counted, which is why a store migration takes longer than a brochure migration of the same page count.
How do you protect revenue on launch day?
By testing the money path with real transactions rather than by inspecting it.
Place a real order end to end, with a real card, and confirm five things: the payment captures, the order appears in the new system, the confirmation email arrives, the stock decrements, and any accounting or fulfilment integration receives it. Then refund it.
Do the same for the awkward paths, since those are where stores actually lose money quietly: a discount code, a shipping option that is not the default, a country you sell to but rarely, and a product with variants.
Check that abandoned cart and transactional emails send from the new setup and land outside spam, because a new sending configuration frequently does not on day one.
And keep the old store reachable but not indexable for a short window, so you can compare against it when a number looks wrong rather than reconstructing it from memory.
When should a store not migrate?
In its peak season, for the obvious reason. A store that makes a third of its revenue in six weeks should not be changing every URL during them, and the honest advice is to wait for the quiet period even if that means several months.
It should also not migrate when the commerce logic is genuinely complicated. Subscriptions, tiered wholesale pricing, per customer catalogues, and complex tax handling are the store rather than decoration, and rebuilding them is a software project priced accordingly.
And it should not migrate for speed alone if the slowness is fixable. A store that is slow because of a bloated theme and twenty plugins may get most of the benefit from a cleanup, and that is worth measuring before committing to a rebuild.
What happens to product rankings during the move?
They follow the product URL, so the answer depends entirely on whether that address survives and whether the page arrives complete.
A product page that keeps its URL and its content keeps its position, with no recrawl delay at all, which is the strongest argument for preserving store URLs rather than tidying them during a replatform.
A product page that changes address recovers over two to six weeks provided one permanent redirect points old to new and the destination is the same product rather than a category. Sending a discontinued product to the category above it is the right call; sending it to the homepage is close to worthless.
Where stores actually lose is in the detail that came with the page. Structured product data, review markup, and stock and price signals frequently do not survive a replatform, and their loss shows up as rich results disappearing rather than as a ranking drop, so it gets noticed late. Check a handful of product pages against a structured data validator on launch day rather than in month two.
How long does a store migration take?
Four to eight weeks for a store of a few hundred products, roughly double a brochure site of the same page count, and the extra time is not in the design.
The inventory is larger, because a 300 product store generates thousands of addresses once categories, filters, pagination, and attachment pages are counted. The redirect map is correspondingly larger and needs more judgment per row.
Then there is a whole workstream that brochure sites do not have: exporting orders and customers, rebuilding tax and shipping rules, reconnecting the payment gateway and its webhooks, and testing the money path with real transactions.
Budget a week purely for testing, and run it before the cutover rather than after. A checkout defect found in staging costs an afternoon, and the same defect found in production costs a day of sales plus the customers who quietly gave up.
Key takeaways: migrating a store without losing sales
A WooCommerce migration protects rankings and revenue together. Map every product and category URL to a 301, migrate product data and rebuild its structured markup, and prove checkout with a real test order before you switch. Product URLs and the buy flow carry the money, so verify those hardest. WPBuildAI runs store moves with that verification built in, so the cutover is a flip, not a gamble with your orders.
Quick answers
How do I migrate a WooCommerce store without losing sales?
Map every product and category URL to a 301 redirect, migrate each product with its images and structured data intact, and place a real test order on staging before cutover to prove checkout, payments, tax, and shipping all work. WPBuildAI runs store migrations with the redirect map and a test purchase verified before the switch, so neither rankings nor revenue dip when the new store goes live.
Will my product pages lose rankings when I migrate?
Not if every product and category URL is redirected to its true new equivalent. Google consolidates each page’s ranking signals through the 301, so positions and backlinks follow the products. Rebuilding the product structured data keeps your price and availability rich results. Rankings only drop when product URLs change without redirects or the catalog content is altered during the move.
What is the biggest risk in an e-commerce migration?
Two things tie for biggest: a broken product URL, which loses a ranking, and a broken checkout, which loses a sale. The first is prevented by a complete one-to-one redirect map; the second by a real test order through the live payment path on staging before launch. Both are verification problems, which is why a store migration is mostly testing.
Can I migrate customer accounts and past orders?
Usually yes, but it needs care because the data is sensitive and the structure differs between platforms. Plan the export and import as its own step, confirm the data maps correctly on staging, and handle it in line with your privacy obligations. If a clean transfer is not possible, prioritize products, URLs, and checkout first, since those protect rankings and revenue.
What has to be exported before a WooCommerce migration?
Order history, customer records, product data with variants, product images with their filenames, coupon rules, tax and shipping configuration, and payment gateway settings. Order history is the one people leave too late, because it carries retention obligations. It does not have to live on the new store, and it does have to exist somewhere searchable before the old one is switched off.
How do I make sure launch day does not cost me sales?
Place real orders rather than inspecting the checkout. Confirm the payment captures, the order lands, the confirmation email arrives, stock decrements, and any fulfilment integration receives it, then refund. Repeat for a discount code, a non default shipping option, an unusual country, and a product with variants, because those awkward paths are where stores lose money without noticing.
How long does a WooCommerce migration take?
Four to eight weeks for a store of a few hundred products, roughly double a brochure site of the same page count. The extra time goes into the larger URL inventory, exporting orders and customers, rebuilding tax and shipping rules, reconnecting the payment gateway and its webhooks, and a full week of testing the money path with real transactions before cutover rather than after it.
