A store cannot be migrated as a snapshot, because it is still writing while you copy it. Copying a brochure site is a photograph of something that is not moving. Copying a shop is a photograph of something that keeps taking money, decrementing stock and creating accounts for as long as the copy takes — and every one of those writes lands on the old database, not the new one.
So the orders people lose in a WooCommerce migration are almost never the old ones. They are the ones placed in the gap between the database snapshot and the DNS switch. What follows is where those records actually live on a modern store (this changed in 2023 and a lot of guides never noticed), everything the final sync has to carry, the machinery that keeps running on both copies at once, and the two-phase method that closes the gap.
Where your orders actually live (this changed in 2023)
Before you copy anything, answer one question: which storage is this store using for its orders? For years the answer was the same for everyone — WooCommerce kept orders in WordPress’s own posts and postmeta tables, as a post type. That is no longer the default.
WooCommerce’s documentation is specific (verified August 2026): High-Performance Order Storage keeps order data in custom tables built for the job — wc_orders, wc_order_addresses, wc_order_operational_data and wc_orders_meta — and it has been the default for new installations from WooCommerce 8.2 onward. Before 8.2, in the same documentation’s words, “WooCommerce relied on the _post and _postmeta table structures to store order information.” There is also a compatibility mode that keeps both in sync while a store tests the new system.
| Your store | Where the orders are | What has to come across intact |
|---|---|---|
| Installed on WooCommerce 8.2 or later | High-Performance Order Storage, by default | The four dedicated order tables — not the posts tables |
| Older store that never switched over | Legacy WordPress posts storage | posts and postmeta, with orders as a post type among your content |
| Running compatibility mode | Both, kept synchronised | Both sets — and they still have to agree with each other after the move |
This matters because of what people reach for under pressure. Exporting “all posts”, or a migration plugin that predates the change, or a partial database dump chosen table by table, will copy a store that looks complete and has an empty Orders screen. Move the whole database, and check the setting before you start rather than after.
Everything the final sync has to carry
The first copy is never the one that goes live. Between taking it and switching the DNS, the old store carries on trading, and everything below changes. This is the list we work through on every store cutover.
| What keeps changing during the copy | What it costs you if the final sync skips it | How it is handled |
|---|---|---|
| Orders placed after the snapshot | Customers paid on the old site for orders the new one has never heard of | Delta sync of the order tables at cutover; keep the old database until the two have been reconciled |
| Stock levels | The new site starts from snapshot stock and oversells items that were already bought | Re-sync stock in the same pass, with checkout paused while it runs |
| Customer accounts | Registrations and password changes from the gap vanish; those customers cannot log in | Sync users and usermeta in the same delta, not as a separate export |
| Coupon usage counts | Single-use and limited coupons reset to unused and can be redeemed a second time | Usage counters live in the database — carry them across; never reimport coupons from an old export |
| Pending scheduled actions | Renewals, follow-ups and stock jobs either disappear or run twice, once per host | Only one host runs the queue until the switch is complete |
| Webhooks and gateway callbacks | Deliveries fail from the wrong machine and WooCommerce switches the webhook off by itself | Check and re-enable webhooks on the live host immediately after the switch |
The parts that keep running on both copies
A shop is not only data. It is also a set of processes that fire on a schedule and talk to the outside world, and once a copy exists, two machines are running them.
Webhooks disable themselves. WooCommerce’s webhooks live under Settings → Advanced → Webhooks and post to a delivery URL whenever something happens in the store. The documentation states that WooCommerce “automatically disables a webhook after more than five consecutive delivery failures”, where a failure is any response that is not a 2xx, 301 or 302 (verified August 2026). A copy that cannot reach those endpoints burns through five failures quickly — and because the disabled state is stored in the database, it travels to production with everything else. It is the same class of failure as the staging noindex that ends up on the live site: a setting flipped somewhere harmless that rides the database into somewhere that matters.
The job queue runs on both hosts. Background work in WooCommerce — subscription renewals, follow-up emails, stock syncs — goes through Action Scheduler, which since version 3.0 keeps its actions in its own actionscheduler_* tables and processes the queue roughly every minute through WP-Cron, in batches (Action Scheduler documentation, verified August 2026). You can see the pending list under WooCommerce → Status → Scheduled Actions. If both copies are live and cron is enabled on both, both work through their own version of that queue, which is how customers end up with two identical emails or a renewal charged twice.
And the copy can still send real messages and take real money. A staging store cloned from production has the same live gateway credentials and the same email configuration it always had. Disable outgoing email and switch payments to test mode on the copy before you start testing anything on it — otherwise a checkout test is a real charge, and an order status change is a real email to a real customer.
The two-phase move, in order
Zero downtime and zero data loss are two different promises, and a store needs the second one. The site never has to go offline — that part we hold to, and the timing behind it is in how long a WordPress migration takes. But a shop does need a short window where nothing new is written, and pausing checkout for a few minutes is not the same as taking the shop down. Anyone promising a store migration with neither a pause nor a delta sync is promising that no one will order during the move.
- Check the order storage setting and note whether it is HPOS, legacy or compatibility mode. Everything else assumes you copied the right tables.
- Copy the whole site to the new host and keep it unreachable to the public. Disable outgoing email, set payments to test mode, and stop the job queue on the copy.
- Test the parts that only a store has: a full checkout end to end, a coupon, a stock decrement, a refund, an order status email. Not the homepage.
- Pause checkout on the live store at the quietest hour you have. The catalogue stays up; only new orders stop.
- Run the delta sync — orders, stock, users, coupon counters — from the live database to the new one, then re-enable email, live payments and the job queue on the new host.
- Switch the DNS, then reopen checkout. Place one real order yourself and confirm it lands in the new database, that the confirmation email arrives, and that the gateway shows the payment.
- Reconcile before you decommission. Keep the old host untouched until the order count and the last order number on both sides agree. That comparison is the only proof the migration did not lose anything.
When it is not worth the effort
If your store takes a handful of orders a week, skip most of this. The two-phase delta exists to protect revenue that would genuinely be at risk during a twenty-minute pause. On a shop with a few orders a day, pick a quiet evening, pause checkout, move it in one pass, and reconcile in the morning. Building the elaborate version is billable and, at that volume, pointless.
And do not move a store in the middle of its season. A migration during a sale campaign, a product launch or the run-up to Black Friday puts the highest-value orders you will take all year in the riskiest window you will create all year — to solve a problem that will still be solvable in January. The exception is the only one that matters: if the host is the thing failing, the risk of staying is higher than the risk of moving.
One more, because it is the most common reason people ask us about migrating a shop: moving hosts does not fix a slow checkout. That bottleneck is usually cart fragments, uncached dynamic calls and a bloated database, and it travels with the store — the reasoning is in the migration timing piece, and the fix is WooCommerce speed optimisation, not a new server. If what you actually need is the move — a host that keeps falling over, a plan you have outgrown — that is our WordPress migration service, stores included, and the checklist above is what it consists of.
Frequently asked questions
Will orders placed during the migration be lost?
Not if the move ends with a delta sync. The store keeps running on the old host until the DNS switch, so every order placed in the meantime is written there. The final pass before the cutover carries those orders, along with stock, accounts and coupon counters, to the new database. Orders are only lost when a migration treats the first copy as final.
How do I know whether my store uses HPOS or the legacy storage?
Look under WooCommerce → Settings → Advanced → Features, at the order data storage option. Stores installed on WooCommerce 8.2 or later default to High-Performance Order Storage, which keeps orders in dedicated tables. Older stores that never switched still keep them in the posts and postmeta tables. Both are valid — but a migration has to know which one it is copying.
Do I have to close the shop while migrating?
The shop stays open and browsable throughout. What is worth pausing, for a few minutes at the cutover, is checkout — so no order is written to the old database while the last sync is running. That is a very different thing from taking the site offline, and it is the only pause a well-planned store migration needs.
What happens to subscriptions and scheduled emails?
They live in the Action Scheduler queue, which sits in its own database tables and is processed roughly every minute. The risk is not losing it but running it twice: if both the old and the new copy are executing the queue, a renewal or a follow-up email can fire from each. Let one host own scheduled jobs until the switch is done.
Will customers have to reset their passwords?
No. Password hashes travel with the users table, so logins keep working. What does not survive is active sessions and carts — those are tied to cookies and the session table, so some customers will find themselves logged out or with an empty cart. Annoying, not damaging.
Do I need new payment gateway keys after the move?
The keys themselves move with the settings and stay valid. What needs checking is anything at the gateway configured with a URL or an address: webhook and callback endpoints, and any IP allowlist tied to the old server. If the domain is unchanged the URLs still resolve, but the deliveries now have to reach a different machine.
Sources (verified August 2026): WooCommerce — High-Performance Order Storage; WooCommerce — Webhooks; WooCommerce — Scheduled actions; Action Scheduler — FAQ.