
A WooCommerce store never truly stops taking orders during a migration window unless you explicitly stop it — a customer can complete checkout on the old server seconds after you've started copying the database to the new one, and that order will not exist in your export. This is the single biggest risk specific to e-commerce migrations that a generic WordPress migration guide doesn't cover.
Schedule the final cutover during your lowest-traffic hours and put the store into maintenance mode (or at minimum, disable checkout) for the 10–15 minutes it takes to do the final database sync. Losing 15 minutes of checkout availability at 3 AM is recoverable; losing orders silently is not.
With checkout frozen, take the final database dump — this now includes every order placed up to that second, with no risk of missing anything mid-transfer:
WooCommerce sessions (cart contents for logged-out users) live in the wp_woocommerce_sessions table and migrate automatically with the rest of the database — no separate step needed as long as you dump the full schema.
Stripe, PayPal, and most gateways send webhook callbacks to a URL tied to your domain, not your server IP, so webhooks continue working through the DNS cutover without reconfiguration — but verify this explicitly in your gateway's dashboard by checking recent webhook delivery logs after cutover, since a missed webhook (like a delayed payment confirmation) can leave an order stuck in 'pending' indefinitely.
Re-enable checkout only after confirming: the product catalog loads correctly, a test order completes end-to-end including the payment gateway's sandbox or a small real transaction, and email notifications (order confirmation, admin new-order alert) are actually arriving — SMTP configuration is a separate setting from the database and does not migrate automatically.

