The WooCommerce Migration Checklist: What to Move, What to Leave Behind

It is the Tuesday after the launch. The new store looks right, every product is where it should be, and then the emails start. A customer wants to know why she is being asked to reset a password she never changed. Someone else rings because the tracking number he was promised never arrived, and the courier account turns out to be still pointed at the old site. By lunchtime somebody notices the category page that used to sit third in Google now returns a 404.

None of that is a product problem. Products are a CSV file, and a CSV file is a solved problem. What sinks a WooCommerce migration is the layer nobody wrote down: the plugin-era courier wiring, the reply address pointing at a mailbox no one reads, the five hundred category URLs Google has spent six years learning.

So here is a WooCommerce migration checklist organised the way a store actually breaks, by asset class rather than by day. For each one: what you are taking, where it goes wrong, and the single thing to do about it. Work through all eight before you pick a cutover date.

Three ground rules first, because each gets argued about at the worst possible moment if it is not written down. Name the freeze window, the gap between your final export and your DNS change in which any order placed on the old store will not exist on the new one; two hours is comfortable, two days is a reconciliation job you do by hand. Keep the old store alive for thirty days, somewhere you can still log into, because a third of the questions in the first fortnight are answered by looking at how it used to work. And decide who owns the courier, gateway, email sender, registrar and DNS accounts, because at least one is usually registered to someone who left.

Not sure which of these apply to your store? Send us the domain and your list of active plugins through the apply form and we will map the migration against this checklist before anything moves. That map is the part most people end up paying for twice.

1. Products, variants and the category tree

WooCommerce ships a product CSV importer and exporter, and for a simple catalogue it does the job. The trouble starts with variable products. Woo exports a parent row plus one row per variation, and the attributes binding them together sit in columns that mean nothing to another platform without a mapping step. Four sizes and six colours is twenty-four rows that must reassemble into one product with the right price, stock number and image on each swatch.

The category tree is the half people forget, because it is invisible in a spreadsheet. On a technical catalogue the hierarchy carries real commercial logic. The camping and caravan canvas retailer in our Intenze case study is the clearest example we have: awnings, pop-top canvas, covers and poles come in fits a customer matches against a specific vehicle, so the tree does the work of a search engine. Rebuilding it from memory instead of carrying it across is how a migration quietly loses the ability to sell.

Then there is what the CSV does not hold: original-resolution images rather than Woo's resized copies, attribute sets and swatch ordering, bundles and grouped products that rarely survive an export intact, downloadable attachments, and per-product shipping classes and weights, which feed into item seven and are silently zero if you skip them.

• Take: the product CSV with variations, original image files, the category tree with its ordering, and attribute and shipping-class definitions.
• Trap: variants reassembling wrongly, and bundles arriving as empty shells that look fine in a list view.
• Do this: check every variant, price, image and stock figure on your five most complicated products by hand before trusting the rest.

2. Order history, and the honest case for leaving most of it behind

Instinct says move everything. For most stores the right answer is to move very little, and to keep the rest somewhere it can be read rather than queried.

Order records are the messiest thing in a WooCommerce database. Legacy installs keep them as a post type spread across the posts and postmeta tables; newer ones use the dedicated tables introduced with high performance order storage. Either way an order carries a frozen snapshot of tax rules, shipping methods, discount codes and gateway identifiers pointing at plugins you are about to remove. Rehydrate that into a different schema and you get records that look like orders but cannot be refunded, reshipped or reconciled.

So separate the three reasons anyone wants it. Accounting needs totals and tax, which a CSV export already covers. Support needs to answer "where is my order from March", which read access to the old admin covers. Only the third, showing customers their own past orders, argues for a real import, and that matters mainly to stores selling consumables.

• Take: open and unfulfilled orders, a ninety-day trailing window, and a full CSV archive of everything before that.
• Trap: paying to import six years of orders without working payment references, then finding nobody opens them.
• Do this: ask whoever handles refunds how far back they actually looked last quarter, and set the import window to that number.

3. Customer accounts and the password problem

Customer records move easily. Passwords do not, and the gap between those two sentences touches every customer you have.

WordPress stores passwords as salted one-way hashes, so there is nothing to convert. Your new platform either imports those hashes with a compatibility layer, or it does not, and if it does not then every existing customer sets a new password. That is not a technical footnote. It is an email to your entire list, and unannounced it reads like a phishing attempt, which means support tickets and customers who quietly stop buying. The fix is sequencing: a short message a day ahead, from the address they already recognise, turns a security scare into a product announcement.

The rest of the record is more forgiving but easy to under-scope. Carry saved billing and shipping addresses, because a stored address is measurable checkout friction removed, and carry consent flags exactly as recorded, since consent does not transfer by assumption. Saved payment methods stay put, because those tokens belong to the gateway account that created them. Store credit and loyalty balances are a liability on your books, so reconcile them by hand, twice.

• Take: customer records with saved billing and shipping addresses, and consent flags exactly as recorded.
• Trap: an unannounced forced password reset landing in thousands of inboxes and reading as phishing.
• Do this: write the heads-up email now, schedule it for the day before cutover, and send it from your existing address.

4. SEO assets: URL structure, the 301 map, meta and structured data

This is the only item that can cost you money for a year rather than a weekend. Everything else is recoverable in an afternoon; lost rankings take two quarters if you are lucky.

Start from the structure you have. WooCommerce serves products at a product path and categories at a product-category path, often behind a shop base, and those exact strings are what Google indexed. If your new platform prefers different paths you have a real choice: adopt the old structure, or change it and redirect. Adopting is almost always cheaper, and people talk themselves out of it for aesthetic reasons rather than commercial ones.

If you do change paths, the redirect map is not an end-of-project task. Export every indexed URL from Search Console and your sitemap, deduplicate, and map each to a permanent 301. Then hunt the URLs that are not products: paginated category pages, filter URLs indexed by accident, old blog posts. Google's guidance on site moves with URL changes is worth reading in full: redirects must be permanent, one to one, and live on day one.

Two things get missed every time. Meta titles and descriptions written by an SEO plugin live in that plugin's own tables, not the product record, so a standard export leaves them behind; get them out before you deactivate anything. And structured data needs a decision, because Woo emits product markup and most SEO plugins emit their own, so plenty of stores ship two overlapping copies for years. One emitter, checked in a rich results test.

• Take: the indexed URL list, plugin-stored meta titles and descriptions, and a documented decision on who emits structured data.
• Trap: redirecting products only and missing category, pagination and legacy blog URLs, which is where the slow bleed comes from.
• Do this: build the 301 map as a two-column spreadsheet before development starts, and test fifty redirects on staging.

5. Product reviews

Reviews are the asset most likely to be lost outright, because they are not stored where anyone looks. Native WooCommerce reviews are comments, sitting in the comments table with a review type and a rating in the metadata, not in the product export. Migrate from a product CSV and the reviews simply do not appear, usually noticed a week later when someone asks why the stars are gone.

If you use a third-party reviews plugin the reviews live in that vendor's system, not your database, and the export is a support request. Make it early, because some vendors take a fortnight and a couple treat it as a retention conversation.

Whatever the source, insist the export carries the fields that make a review worth having: rating, body, reviewer name, original date, verified-purchase flag and photos. Reviews stamped with this month's date look manufactured, break the chronology customers scan, and if you emit review markup alongside them you are publishing dates that are not true. Last catch: reviews attach to products by an internal identifier that will not survive the move, so they have to be re-keyed against SKU.

• Take: rating, body, reviewer name, original date, verified-purchase flag and photos, keyed to SKU.
• Trap: reviews living in the comments table or a vendor's platform, so a product export leaves every one behind.
• Do this: export reviews as their own file on day one, and confirm the original dates came with them.

6. Transactional email and the reply address nobody owns

Order confirmations, shipping notifications, password resets and refund notices are the emails customers actually open, and on a WooCommerce store they are typically produced by three things at once: Woo core for the order mail, a plugin for the sending infrastructure, and sometimes a marketing tool that has taken over the templates.

Inventory two things before you switch. First, which messages go out and what triggers each; the list is longer than the owner expects, and a message that stops sending is invisible until a customer complains they never got a tracking number. Second, and this is the one that bites, the from address and where a reply actually lands. On older stores these drift apart: the store sends from a no-reply address, customers reply anyway, and the replies land nowhere. Getting that under control was a concrete win in the Intenze move, where the reply address stopped being a field buried in a plugin screen and became a setting in one dashboard, changeable by the person who reads the mail.

Sender authentication does not travel with your content either. SPF, DKIM and DMARC are DNS entries pointing at whatever service sent your mail before, so a new sender needs new records, verified before the first confirmation goes out. Sending unauthenticated on your busiest day is how confirmations land in spam at the moment customers are watching for them.

• Take: every triggered message, the from address, the real reply-to destination, and your current SPF, DKIM and DMARC records.
• Trap: a no-reply from address whose replies vanish, and unverified sender records putting confirmations in spam on launch day.
• Do this: place a real test order on staging, reply to the confirmation email, and confirm it reaches a mailbox a human opens.

7. Shipping and fulfilment integrations

Shipping is where a migration stops being a website project. Nothing here transfers as data; all of it is configuration rebuilt deliberately, and it goes wrong because it looks trivial until the first real order.

Rate rules come first: zones, weight and price bands, free shipping thresholds, rural surcharges, per-product shipping classes, oversized item handling. On a store running for years these encode hard-won commercial knowledge, and they are frequently spread across two or three plugins interacting in ways nobody documented. Screenshot every configuration screen before you deactivate a thing.

Then the courier link, which has its own credentials and needs re-authorising against the new store. With it goes the part that saves real time: a paid order reaching the fulfilment system without anyone retyping an address, and a tracking number returning to the customer without anyone copying and pasting. That automation is the whole value of the integration, and on the Intenze store it is the piece that moved from a plugin somebody had to maintain to a platform capability, described on our shipping app page. Pickup, click and collect and local delivery are their own testing pass, as is tax if shipping is taxed differently from goods.

• Take: screenshots of every rate and zone rule, per-product shipping classes, and courier credentials with a named owner.
• Trap: treating shipping as a setting rather than an integration, and reauthorising the courier link after cutover.
• Do this: run three test orders on staging, one standard, one oversized, one rural, and print a real label for each.

8. The plugin list you get to delete

Finish by going the other way. Every item so far asked what you are taking. This one asks what you are deliberately not taking, and it is the item that pays for the project.

Open your plugins screen and write all of them down, because most Woo stores we take over run between fifteen and forty. Sort each into three piles. Pile one is what the new platform already does natively: collection filters, a banner announcing the workshop is closed for a week, a reviews display, a cookie notice, image optimisation, caching, security, backups. On a modern stack these are not extensions at all, and each is a subscription that stops and a compatibility risk that disappears. Pile two is genuinely specific to your business and needs a real answer before cutover. Pile three is the plugins nobody can explain, always larger than expected.

Two costs come off the books with pile one. The obvious one is licence renewals. The less obvious one is the maintenance tax: someone applies the updates, and someone works out which of thirty vendors broke the checkout when a customer reports it. If that arithmetic is why you are reading this, the full argument is on our WordPress alternatives page.

• Take: every active plugin listed and sorted into native, business-specific, and unexplained.
• Trap: rebuilding a plugin's behaviour out of habit when the platform already did it and nobody checked.
• Do this: deactivate the unexplained pile a week before cutover and see whether one person raises it.

9. Sequence it, and do not big-bang it

Inventory first: items one through eight written down as lists and screenshots while the old store still runs normally. Build and import second, onto staging nobody outside the project can reach. Test third, with real orders rather than clicks: place them, pay them, refund one, ship one, reply to the confirmation email. Only then move DNS. Afterwards watch Search Console coverage and 404 reports for holes in the redirect map, watch that every paid order reaches fulfilment, and watch your support inbox, which catches anything the first two missed.

• Take: a four-phase plan with a named owner and a date against each phase.
• Trap: moving DNS before real orders have been placed, paid and refunded on staging.
• Do this: book the cutover for a weekday morning and keep the old store readable for thirty days.

Frequently asked questions

How long does a WooCommerce migration take?
For a few hundred products with standard shipping rules, weeks rather than months, and most of that is inventory and testing rather than building. What stretches a timeline is almost never product count. It is bundles, unusual shipping logic, and waiting on a third party.

Will I lose my Google rankings when I move off WooCommerce?
Not if the URL structure is preserved or fully redirected with permanent 301s on day one and the meta data comes across. Losses are nearly always traceable to a specific failure: missing category redirects, meta titles stranded in a plugin's tables, or a noindex left on from staging. Expect a brief wobble as Google recrawls.

Should I move my order history?
Move open and recent orders, archive the rest as CSV and keep the old admin readable. Imported historical orders arrive without working payment references, so they cannot be refunded or reconciled anyway. The exception is stores selling consumables, where reordering from history is the point.

Do customers have to reset their passwords?
Usually yes, because WordPress password hashes are one-way and rarely portable. Treat it as a communications task: announce the move a day ahead from the address customers recognise, so the reset email arrives expected rather than looking like phishing.

What about my product reviews?
They need a separate export. Native Woo reviews live in the comments table, not the product CSV, and third-party reviews live in the vendor's system and have to be requested. Insist on original dates and verified-purchase flags, and re-key them by SKU.

The short version

Nine items, and the ones that hurt are not the ones that look hard. Products are a file. Orders are a decision about what is worth carrying. Passwords are an email you send a day early. SEO is the only item with a twelve-month failure mode, so it gets the spreadsheet and the fifty-redirect test. Reviews are the asset most often lost outright. Email and shipping are integrations, not settings, and both need a real test order to prove.

We have run this checklist on real stores, including a full WooCommerce catalogue move for a New Zealand camping and caravan canvas retailer, and the way we scope that work is set out in how we handle site rescues and migrations. If you want the map before committing to anything, send your domain and plugin list through the apply form. The asset-by-asset assessment is yours whether or not you move.