Migrating a WooCommerce store carries a stress an ordinary site does not: it is a live shop, with real orders coming in, real customers logged in, and real money moving — so a careless move risks lost orders, corrupted inventory, or broken checkout at the worst possible moment. The good news is that a WooCommerce store is still a WordPress site at heart, so the migration follows the familiar pattern, with a few extra precautions that specifically protect your orders, customers, and transactions.

This guide covers migrating a WooCommerce store safely: why it needs extra care, the critical issue of orders placed during the move, freezing the store or choosing a quiet window, the full migration process for a shop, the payment-and-checkout testing that is non-negotiable, and the go-live sequence. By the end you will be able to move your store to a better host without losing an order or breaking a sale.

Why WooCommerce needs extra care

At its foundation, a WooCommerce store is a WordPress site — files plus a database — so migrating it uses the same core process as any WordPress move. But WooCommerce adds a layer that raises the stakes considerably: the database holds live commercial data — orders, customers, products, inventory levels, and transaction records — and the store is actively transacting, so the migration must protect data that is changing in real time.

The specific risks that ordinary sites do not face are real: an order placed during the migration could be lost if it lands on the old site after you have copied the database; inventory counts could become inconsistent; customer accounts or payment configurations could break; and a broken checkout after go-live means lost sales directly. These are not hypothetical — they are the exact failures a careless store migration produces.

So WooCommerce migration is a WordPress migration plus a set of commerce-specific safeguards, all aimed at one goal: not losing or corrupting any orders, customers, or transactions during the move. The rest of this guide is the standard migration process with those safeguards woven in. Treat the store’s live data as the sensitive thing it is, and a WooCommerce migration is entirely safe; treat it as an ordinary site, and you risk exactly the commercial failures that make store owners dread migrating.

The critical issue: orders during the move

The single biggest danger in a store migration is orders placed during the transition. Here is the problem: you copy the database at a moment in time, but if a customer places an order on the old site after that snapshot — while DNS is still propagating and some visitors reach the old host — that order lives only in the old database and never appears in the new one. When you retire the old host, that order is lost.

This is unique to transacting sites. A static site’s content does not change during the migration window, so a snapshot is fine. But a store’s data is live: orders, stock levels, and customer registrations can all change in the very window during which you are moving. If you do not account for this, the migration silently drops whatever commercial activity happened on the old site after you copied its database.

So the core challenge of a safe WooCommerce migration is ensuring no order or data change slips through the gap between copying the database and fully switching over. There are two main ways to guarantee this — freezing the store during the move, or migrating in a quiet window and reconciling — and choosing and executing one of them is what separates a safe store migration from a risky one. This is the consideration that makes store migration genuinely different.

Freezing the store or choosing a quiet window

There are two proven strategies to protect against lost orders, and you should use one of them:

• Freeze the store: put the shop into maintenance or ‘catalogue only’ mode so no new orders can be placed during the migration, then copy the data, cut over, and re-enable purchasing on the new site — guaranteeing no order is placed on the old site after the snapshot.
• Quiet-window migration: perform the move during your lowest-traffic period (e.g. the middle of the night for your customer base) to minimise the chance of orders during the gap, and reconcile any that do come in.
• Lowered DNS TTL: either way, lower your TTL beforehand so the propagation window — the risky gap — is as short as possible.
• Reconcile afterward: check the old site’s orders after cutover for any placed late, and manually transfer them if found.

Freezing the store is the safest approach because it eliminates the possibility of a lost order entirely — no orders can be placed during the move, so nothing can slip through. The quiet-window approach is less disruptive (the store stays open) but relies on minimising and reconciling rather than preventing, so it carries a small residual risk that must be caught by checking the old site afterward. For a busy store, a brief freeze during a low-traffic window is often the best of both: minimal disruption, maximum safety.

The migration process for a store

With the order-protection strategy chosen, the migration itself follows the standard WordPress process with commerce data in mind. Back up everything first — and for a store, this backup is especially critical, since it holds irreplaceable orders and customer data. Then set up the new host and copy the two components: the files (WordPress, WooCommerce, themes, plugins, and product images) and the database (all products, orders, customers, and settings).

On the new host, import the database, upload the files, reconnect via wp-config.php, and run the search-and-replace to fix any stored URLs — exactly as in any WordPress migration. Because WooCommerce and its extensions store configuration and keys, make sure payment gateway settings and any API keys are carried over or reconfigured on the new site, since these are easy to overlook and essential for checkout to work.

Then, crucially, test the migrated store privately before going live (via a hosts-file preview), because a store has far more to verify than a content site: not just pages and images, but products displaying correctly, inventory accurate, cart working, and — above all — checkout and payment functioning. Only once the store is fully working on the new host, with your order-protection strategy in place, do you proceed to go live. The process is standard; the difference is the depth of testing and the protection of live orders.

Payment and checkout testing

The one test you absolutely cannot skip in a store migration is a full checkout and payment test, because a store that looks fine but cannot take payment is a store losing every sale. On the migrated site (in your private preview, and again after go-live), run a complete test transaction: add a product to the cart, go through checkout, and confirm payment processes correctly through your payment gateway.

This tests a chain of things that a store migration can break: the cart and checkout pages, the payment gateway configuration and API keys (which may not have carried over cleanly), the order-creation process, inventory decrementing, and the confirmation emails to customer and store. Any weak link means lost or broken sales, and only an actual test transaction reveals them. Many gateways offer a test or sandbox mode to do this without a real charge.

So treat payment and checkout testing as the non-negotiable heart of store-migration verification. Confirm not just that checkout loads but that a real (or sandbox) order completes end to end — payment captured, order recorded, inventory updated, emails sent. A content site’s testing can be a click-through; a store’s testing must prove the money path works. Get this right, and you have verified the thing that matters most about a shop; skip it, and you risk going live with a beautiful storefront that quietly rejects every purchase.

The go-live sequence for a store

Going live with a migrated store follows the standard cutover, but sequenced to protect orders. If you froze the store, the sequence is: with the store in catalogue-only or maintenance mode and the migrated site fully tested, cut over the DNS to the new host, wait for propagation (fast if you lowered TTL), confirm the new store is serving everyone, then re-enable purchasing on the new site. No order was possible on the old site during the gap, so none is lost.

If you used the quiet-window approach without freezing, cut over during the low-traffic window, keep the old host running through propagation, and then carefully reconcile — check the old site for any orders placed during the transition and transfer them to the new site manually, so nothing is dropped. Either way, verify the live store thoroughly again: run another real checkout test, confirm orders record and emails send, and check inventory and customer logins.

Then, and only then, once you are certain the new store is fully operational and you have reconciled or prevented any transitional orders, retire the old host — later than you might for a content site, because you want to be completely sure no order is stranded on the old server. A store migration is finished not when DNS switches but when you have confirmed the money path works on the new host and accounted for every order across the transition. Done with that care, you move your shop safely, without losing a single sale.

FAQs

How do I migrate a WooCommerce store safely?

It’s a WordPress migration plus commerce safeguards. Back up everything, then either freeze the store (catalogue-only/maintenance mode) or migrate in a low-traffic window so no orders are lost during the gap. Copy files and database, reconnect, carry over payment gateway settings and API keys, then test checkout and payment fully before going live. Cut over DNS, reconcile any transitional orders, verify, and retire the old host last.

Why is migrating a WooCommerce store riskier than a normal site?

Because its database holds live commercial data — orders, customers, inventory, transactions — that’s changing in real time, and the store is actively transacting. An order placed on the old site after you copy the database could be lost; inventory could become inconsistent; and a broken checkout after go-live means lost sales. A content site’s data is static during the move; a store’s isn’t.

What happens to orders placed during the migration?

That’s the critical risk: if a customer orders on the old site after you’ve snapshotted the database — while DNS is still propagating — that order lives only in the old database and won’t appear in the new one, so it’s lost when you retire the old host. Prevent it by freezing the store during the move, or migrate in a quiet window and reconcile the old site’s orders afterward.

Should I put my store in maintenance mode to migrate?

Freezing the store (maintenance or catalogue-only mode so no new orders can be placed) is the safest approach, because it eliminates the chance of an order slipping through during the move entirely. The alternative — migrating in a low-traffic window and reconciling — keeps the store open but carries a small residual risk. A brief freeze during a quiet window combines minimal disruption with maximum safety.

What must I test after migrating a WooCommerce store?

Above all, a full checkout and payment test — run a complete (or sandbox) transaction to confirm the cart, checkout, payment gateway, order creation, inventory decrement, and confirmation emails all work end to end. Payment settings and API keys often don’t carry over cleanly. Also verify products display, inventory is accurate, and customer logins work. A store that can’t take payment is losing every sale.

When can I cancel my old host after migrating a store?

Later than for a content site — only once you’re certain the new store is fully operational (checkout tested live) and you’ve reconciled or prevented every transitional order, so none is stranded on the old server. Keep the old host running through DNS propagation and your reconciliation check, then retire it. A store migration ends when the money path works on the new host and every order is accounted for.

The bottom line

Migrating a WooCommerce store safely is a standard WordPress migration with one overriding extra concern: the store holds live commercial data — orders, customers, inventory, and transactions — that is changing in real time, so the move must protect that data and never lose a sale. The central danger, unique to transacting sites, is an order placed on the old site during the transition window, which would live only in the old database and be lost when you retire the old host. You guard against it in one of two ways: freeze the store into catalogue-only or maintenance mode during the move so no order can slip through (the safest), or migrate during a low-traffic window and carefully reconcile the old site’s orders afterward — and either way, lower your DNS TTL beforehand so the risky window is as short as possible.

The migration process itself follows the familiar pattern — back up (especially critical for irreplaceable order data), copy files and database, reconnect via wp-config.php, fix URLs, and carry over the payment gateway settings and API keys that are easy to overlook — but the testing bar is far higher. The non-negotiable heart of store verification is a full checkout and payment test: a real or sandbox transaction confirming the cart, gateway, order creation, inventory update, and confirmation emails all work end to end, because a storefront that cannot take payment is losing every sale. Go live sequenced to protect orders, verify the money path again on the live store, reconcile or prevent every transitional order, and retire the old host only once you are certain nothing is stranded. Handled with that commerce-specific care, you move your shop to a better home without losing an order or breaking a sale.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. A WooCommerce store is a WordPress site with live orders, customers, and payments — so migrating it adds one rule: lose no order placed during the move. Freeze the store (or use a quiet window and reconcile), lower TTL, back up, copy files/database, carry over payment gateway keys, and run a full checkout/payment test before and after go-live. Retire the old host only once every transitional order is accounted for.