Migrate your WooCommerce store without losing orders, customers or SEO

Migrating a WooCommerce store is not the same as moving an ordinary WordPress site. A store carries live data: orders, customers, stock levels and every link Google has already indexed. Get the move wrong and you lose more than files, you lose order history, logged-in customers and rankings. The good news is that a store can be moved without losses if you do it in the right order. This guide covers what is actually at risk, how to plan the switch, and a checklist for the day you move the traffic across.

What can actually be lost

Before you touch anything, it helps to be concrete about what a move can damage. It is three things, and they live in different places:

• Orders and customers. These live in the database, not the files. In recent WooCommerce, orders are stored in their own tables (High-Performance Order Storage), and customer data spans several tables. Copy only wp-content and you lose all of it.
• SEO and links. Every product and category has a URL that may be linked from elsewhere and indexed. Change the structure without redirects and you get 404s where rankings used to be.
• Configuration. Payment and shipping settings, tax tables and API keys live in settings and in wp_options. They do not always follow a simple export.

The basic rule: a store moves as a whole, files and database together, not as one content export at a time.

Do not freeze the store, plan the switch

The most common fear is orders arriving mid-migration and vanishing. The answer is not to close the store for a day, but to plan a short window where you freeze writes. One approach that works: build the new site fully beside the old one, test it, then run a final database sync right before you switch. During the short switch window you put the store into maintenance mode so no new orders land on the old server after you take your final copy. The window only needs to be minutes, not hours, if everything else is already in place.

Move the whole database, not just the content

Plugins that export posts and pages are not enough for a store. You need a full database copy. With WP-CLI that is one line on the old server:

wp db export store.sql

That file holds everything: the order tables, the customers, the products, the settings. On the new server you import it and then run a search-replace to change domain or path, if it changes. Always run search-replace with WP-CLI so serialised data is handled correctly, never with a raw SQL query that corrupts settings:

wp search-replace 'https://old.example' 'https://new.example' --all-tables --precise

Copy the files separately: all of wp-content, especially the uploads folder with the product images. Once database and files are both in place, product images, orders and customers line up exactly as before.

Keep your permalinks and redirect what changes

This is the part that decides whether you keep your SEO. Move the store to the same domain and keep the same permalink structure, and nothing changes on the outside, which is the goal. Change the domain and you need 301 redirects from every old URL to its new counterpart, so both visitors and Google follow along. Think through:

• Keep product and category slugs unchanged. Do not rename them in the same move.
• Set up 301 redirects at the domain level if the domain changes, not plugin redirects that can stop working.
• Update your sitemap and resubmit it in Google Search Console after the switch.
• Keep your robots setting so the new site is actually allowed to be indexed. A common miss is a new environment left with indexing turned off.

A successful store move is invisible from the outside. Customers log in as before, order history is intact, and search results point at pages that still respond. All the work is in the preparation and in the order you do the steps.

Test on a copy before you change DNS

Never point DNS at an unproven server. Finish building the new store, reach it through a temporary address or by pointing your own machine at it, and walk the whole flow: place a test order, confirm the confirmation email sends, that an old order shows in history, that stock levels match, and that payment in test mode works. Check too that taxes and shipping calculate correctly at checkout. Only once the copy behaves identically is it time to move the traffic. Hosting with real SSH and database access makes this straightforward, because you can verify directly on the server rather than guessing.

Checklist for the day you switch

• Put the old store into maintenance mode to freeze new orders.
• Take a final database export and load it onto the new server.
• Run search-replace if the domain or path changes.
• Verify a test order, an email send, and an old order in history.
• Change DNS and keep the old server running until the new one answers everywhere.
• Resubmit the sitemap and watch Search Console for a few days.

A store move done in this order loses neither orders, customers nor rankings. If you would rather not do it yourself, this methodical kind of move is exactly what we handle. Read more about how we think about running WooCommerce and about our migration process, where we build the new site beside the old and switch only once it is verified. If you are wondering whether it is worth having someone run the store day to day, not just during the move, we have written about why a support partner is more than a plugin.