A blog migration that goes wrong loses a day of pride. A store migration that goes wrong loses orders, webhooks, and customer trust in payments. The store-specific checklist — the one our team runs on top of the standard migration list.
Before the move
- Backup with store tables verified: WooCommerce adds its own tables (orders, sessions, lookup tables) — confirm the backup includes them and the restore actually works.
- Note the webhook endpoints: payment providers (Stripe, PayPal) post order updates to fixed URLs. Inventory every integration and where it points.
- Pick the window by revenue: your lowest-traffic hours matter more than your team’s convenience. Stores never have a “quiet” time, only quieter ones.
- Freeze changes — no new orders shipping data you already exported; a mid-move order is the classic lost-record.
The move specifics
- Transfer everything, including session tables — shoppers” carts survive the move (or at least fail loudly rather than silently).
- Search-replace URLs serialized-safe — WooCommerce options are serialized; the mechanism in the standard checklist applies doubly.
- Update and test payment webhooks immediately: point providers at the new domain and run a real (refundable) transaction. A webhook miss means payments complete but orders never update — the worst failure mode because it is invisible until customers complain.
- Re-verify email delivery: order confirmations and admin notices depend on SMTP and DNS records that may reference the old server — the checklist in the email guide.
- Clear all caches and object caches — stale product pages with old-domain asset URLs survive otherwise.
The post-move hour
- Place a real test order end to end: browse → cart → checkout → payment → confirmation email → order visible in admin.
- Verify order history renders for a real customer account (dates, statuses, downloads).
- Check the Action Scheduler queue (Tools → Scheduled Actions) — migrations strand pending jobs; failed retries pile up silently.
- Watch tax and shipping calculations — plugins that license by domain sometimes degrade to trial mode after a move; check their settings pages.
The rollback position
Keep the old server running and frozen for a week (per the standard checklist) — for stores this is not paranoia but policy: DNS-straggling customers must reach a working checkout. If the new server misbehaves, the frozen old one is the instant fallback.
The migration service page describes how we run store moves with the transaction test as a hard gate.
Live orders, session carts, payment webhooks, and licensed plugins tied to the domain. Each needs explicit handling — a standard blog migration misses all four. Payment webhooks still post to the old domain. Update each provider's webhook URL and run a real refundable transaction — the update flow must be proven, not assumed. They do if session tables transfer and URLs are search-replaced serialized-safely. Without it, carts silently empty for shoppers mid-session — the reason sessions belong on the checklist. One week, frozen, as rollback and for stale-DNS visitors. Stores cannot afford checkout gaps while DNS propagates.What is special about migrating a WooCommerce store?
Why did orders stop updating after my store migration?
Do customer carts survive a WooCommerce migration?
How long should the old store server stay online after a move?
