Quick answer: Orders are database rows, so the risk window is between your last database copy and the DNS switch. Put the store into a short maintenance/checkout-freeze, take the final database sync inside that freeze, switch DNS, then lift the freeze on the new server. Done this way, no order can land on the old server unnoticed.
Overview
A WooCommerce store differs from a plain site in one crucial way: customers write to the database around the clock. A file copy can be repeated safely, but every order, stock change and customer account created after your database snapshot exists only on the old server. The whole migration therefore revolves around controlling that write window.
Before you start
- A verified copy of the store already running on the new server (see zero-downtime WordPress migration).
- A maintenance-mode mechanism you have tested: WooCommerce coming-soon mode, a maintenance plugin, or a web-server level notice.
- The lowest-order-volume window from your sales analytics.
Step-by-step guide
- Announce a short maintenance window if your customers expect 24/7 ordering.
- Enable checkout freeze on the OLD site at the window start — customers can browse, but not order.
- Final database sync: dump the database (or at minimum the WooCommerce order, post and user tables) and import it on the new server.
- Verify order flow on the new server via hosts-file: place a test order end-to-end, including payment gateway sandbox if available.
- Switch DNS, lift the freeze on the NEW server, and leave the freeze ON on the old one — any straggler visitor still resolving old DNS cannot create an order there.
- Reconcile: next day, compare last order IDs on both servers to confirm nothing landed on the old side.
Common issues
- Payment webhooks: update gateway webhook URLs/IP allowlists if they reference the server directly, or asynchronous payment confirmations may miss.
- Cron-driven emails: disable WP-Cron on the old server after cutover so it does not send duplicate notifications.
- Sessions and carts: logged-in carts stored in the database survive the sync; guest carts in cookies survive DNS — but anything cached mid-switch may need a refresh.
When to contact support
Stores with constant order flow, multiple currencies or custom payment integrations should book an assisted migration — we plan the freeze window with you and stay online through the cutover.
Frequently asked questions
How do stores lose orders during migration?
Orders placed between the last database copy and the DNS switch exist only on the old server. A checkout freeze during the final sync closes that gap completely.
How long does the checkout freeze need to be?
Only as long as the final database sync and verification — typically minutes if a full copy was done earlier. Schedule it in your lowest-order window from analytics.
What about payment gateway webhooks after the move?
Update webhook URLs and any IP allowlists in the gateway dashboard to the new server, otherwise asynchronous payment confirmations can silently stop arriving.
How do I verify no orders were left behind?
Keep the old store in checkout-freeze after cutover, then compare the latest order IDs on both databases the next day; matching IDs mean nothing landed on the old side.
Related articles
- How to migrate WordPress without downtime
- How to migrate databases
- Post-migration checklist
- How to roll back a migration
Need a hand with your move? Contact Cloud2Y support →
