Migrating a WooCommerce Store to Getwebup Without Losing Orders

Moving a plain WordPress brochure site is forgiving - if a page is stale for twenty minutes, nobody notices. Moving a WooCommerce store is not that forgiving. Orders keep landing, stock keeps depleting, and a payment gateway with the wrong webhook URL will happily take a customer's money while your new site has no idea the order exists. Here's how to move a live WooCommerce store to Getwebup without losing an order, overselling stock, or breaking payments mid-cutover.

Why a WooCommerce Move Is a Different Problem

A standard WordPress migration is basically: copy files, export/import the database, repoint DNS, done. WooCommerce adds three moving parts that a generic migration guide won't warn you about:

• Data that changes every minute. Orders, stock counts, and cart sessions are live on the old server right up until cutover - unlike a blog post, they can't just be "the version from this morning."
• External services that remember a URL. Razorpay, Stripe, PayPal, and most Indian payment gateways send webhook callbacks to a fixed URL on your domain. If that endpoint changes environment mid-transaction, the payment can succeed on the gateway's side while WooCommerce never marks the order paid.
• Serialized data in the database. Cart data, product meta, and some gateway settings are PHP-serialized. A naive find-and-replace on the domain name (instead of a serialization-aware tool) silently corrupts them - the site looks fine until someone tries to check out.

Before You Start: The WooCommerce-Specific Checklist

On top of the usual migration prep (full backup, Getwebup account provisioned, matching PHP version, DNS access), get these ready too:

• API keys/secrets for every active payment gateway (Razorpay, Stripe, PayU, PayPal, etc.) - you'll need to re-verify webhook endpoints after the move.
• A note of your current stock levels for fast-moving SKUs, so you can sanity-check numbers after import.
• A low-traffic window. Even with the steps below, pick a time with the fewest concurrent shoppers - late night IST works for most India-based stores.
• WP-CLI access on both the old and new server, if available - it makes the serialized-data step far safer than a plugin-based search-replace.

Step 1: Freeze the Moving Parts

Right before you start the final sync, put the store into a short maintenance window rather than trying to migrate a fully live cart system:

1. Enable WooCommerce's built-in "store notice" or a maintenance plugin that still allows admin access.
2. Let any orders already in the checkout flow finish, or ask WooCommerce to hold new orders for 10-15 minutes.
3. Note the last order ID and current stock levels for your top SKUs - this becomes your reconciliation checkpoint.

This window is usually shorter than the DNS propagation time itself, so it doesn't cost you the "zero-downtime" goal in any way a customer would notice.

Step 2: Migrate Files and Database the Normal Way

This part is identical to any WordPress move - compress wp-content and wp-config.php, export the database, and pull both onto Getwebup via SFTP or cPanel's Backup Wizard. The difference is what you do with the database once it lands:

# On the new server, use WP-CLI's serialization-aware search-replace
wp search-replace 'https://old-domain.com' 'https://new-domain.com' \
  --skip-columns=guid --precise --all-tables

Never do this replacement with a plain SQL UPDATE ... REPLACE() or a text editor - product meta, cart fragments, and gateway config are serialized PHP arrays where a length-prefixed string mismatch breaks the whole record silently.

Step 3: The Payment Gateway Trap - Webhook URLs

This is the step people skip and the one that causes "customer paid but order shows unpaid" tickets days later. Every gateway needs its webhook/IPN URL re-pointed and re-verified:

Update the endpoint on each gateway's dashboard before you flip DNS, and send a test webhook from the gateway's own testing tool once WooCommerce is live on Getwebup. Don't just trust that the URL "should" work because the domain is the same - the gateway cached the old server's response the last time it checked.

A note on API keys

If a gateway's account was tied to a staging or IP-restricted callback during testing, double check it's whitelisted for the production Getwebup server IP too, not just the domain.

Step 4: Reconcile Orders and Stock

Once the new site is live, compare against the checkpoint from Step 1:

• Confirm the last order ID on the new site matches (or is one higher than) what you noted before the freeze.
• Spot-check stock quantities on your top 10 SKUs against the numbers you wrote down.
• Place one real test order with a real (small) payment to confirm the full path - cart, checkout, gateway redirect, webhook, order confirmation email - actually works end to end.

Don't skip the live test order. A migration that "looks right" in wp-admin can still have a broken webhook that only shows up on the next real transaction.

Step 5: Re-point Shipping, Tax, and Search Settings

A few settings are easy to forget because they don't live in the pages/posts you're used to checking:

• Store address for tax/GST under WooCommerce > Settings > General - confirm it survived the import; some caching plugins store a cached version separately.
• Shipping zone rules - verify at least one zone still calculates correctly on a test cart.
• Product search/reindex - if you use a search plugin (WooCommerce's own product search or a third party), trigger a manual reindex after the move; stale indexes show old prices or out-of-stock items as available.

Prevention: Set Up for the Next One

If you'll ever need to move this store again - to a new theme host, a staging clone, or another server - these two habits save hours later:

• Keep a documented list of every payment gateway's webhook URL and where to change it, updated whenever you add a new gateway.
• Schedule a monthly automated backup that includes the database, not just files, so a rollback during any future migration is a restore, not a rebuild.

Quick Reference: Generic WP Move vs WooCommerce Move

Handled in this order - freeze, migrate, re-point gateways, reconcile, verify with a real order - a WooCommerce store move is no riskier than any other migration. The failures that do happen almost always trace back to one of two things: a plain-text find-and-replace that corrupted serialized data, or a webhook URL nobody updated. Get those two right and the rest is routine.