A WooCommerce-specific migration scenario that reasons through webhook endpoints, serialized data, and email deliverability risks a generic "migrate a WordPress site" checklist would miss.
Works with Claude / GPT300 uses★ 4.3
The prompt
zero-downtime-migration-plan
You're migrating a WooCommerce store from [a cheap shared host] to [a managed
WordPress host], and the client's non-negotiable constraint is: checkout cannot go
down during business hours (9am-6pm local time), and existing order confirmation
emails must keep working through the transition.
Plan this in three phases, reasoning through the WooCommerce-specific risks a generic
"migrate a WordPress site" checklist would miss:
1. Pre-migration: what to audit beyond the standard database/files backup,
specifically WooCommerce webhook endpoints (payment gateway callbacks often
hardcode the old domain), scheduled Action Scheduler jobs that might be mid-run
during cutover, and transactional email deliverability (SPF/DKIM records tied to
the old host's mail relay).
2. Migration sequence: state exactly when to do the database search-replace (must be
serialized-data-safe, since WooCommerce stores serialized data in order meta and
cart sessions) relative to the file transfer, and how to handle DNS cutover so it
happens outside business hours even though the migration may need to run during
them for testing.
3. Post-migration verification: the WooCommerce-specific checks a generic migration
checklist misses. Place a real test order end-to-end including the payment
gateway's sandbox/live mode setting, confirm order confirmation emails actually
arrive (not just that WooCommerce logs show "sent"), and check that webhook URLs
in the payment gateway's dashboard now point to the new domain.
For every step where a broken webhook or failed email would only be discovered when a
real customer hits it, state the specific way to test that step preemptively instead
of finding out from a support ticket.
Migrations rarely fail at the file transfer. They fail at a webhook still pointing to
the old domain, or serialized cart data silently corrupted by a naive find-and-replace,
both of which look completely fine until a real customer’s payment or email fails.
Pro tip: always lower the DNS TTL in the pre-migration phase, days ahead of
cutover. It’s the one step that can’t be rushed after the fact.