Why WooCommerce migrations carry more risk
A static brochure site has one thing that matters during a migration: the files. A WooCommerce store has files, a constantly changing database of orders, customer accounts, stock levels, session data for active shopping carts, uploaded product images, and integrations with a payment gateway that expects your site to behave exactly the same on the new server as it did on the old one. Any one of those pieces handled carelessly can mean a broken checkout, a missing order, or a customer charged without their order actually recording.
Pre-migration checklist
- Take a full backup first, regardless of what your new or old host promises about the migration process. This is your safety net if anything goes wrong.
- List every active plugin, particularly anything handling payments, shipping calculations, or tax, since these sometimes store licence keys or configuration tied to the original domain.
- Note your payment gateway's webhook URLs from its dashboard, so you can confirm they still point somewhere correct after the move.
- Lower your domain's DNS TTL (time to live) a day or two before cutover. A shorter TTL means DNS changes propagate faster once you actually switch over, shrinking the cutover window.
- Pick a low-traffic window for the final cutover specifically, even though the bulk of the migration can happen live in the background beforehand.
The staging-first approach
A properly handled migration never points your domain at the new server until you've confirmed everything actually works there. The correct sequence looks like this:
- Copy everything to a staging URL on the new server, files and database, while your live store keeps running untouched on the old host.
- Test the full checkout flow on staging, including a real test transaction if your payment gateway supports sandbox mode, plus email delivery, product images, and any custom functionality.
- Run a final incremental sync immediately before cutover, capturing any orders or account activity that happened on the live site during testing.
- Switch DNS to point at the new server, only once staging has been fully verified.
This is the difference between a migration that just copies files and one that actually protects a live, transacting store.
What "zero downtime" actually means
"Zero downtime" doesn't mean nothing happens instantly. It means your current site keeps serving customers on the old host for the entire copying and testing phase, so there's no window where your store is simply unavailable. The only unavoidable moment of change is DNS propagation once you point your domain at the new server, and with a properly lowered TTL beforehand, that window is typically minutes, not hours, and doesn't take your store offline, it just means some visitors briefly see the old server and some see the new one during the switch.
Common mistakes that cause lost orders
- Skipping the database search-and-replace. WordPress stores full URLs directly inside the database in many places. A straight file copy without properly updating those references leaves images, links, and sometimes checkout redirects pointing back at the old domain.
- Forgetting payment gateway webhooks. Some gateways rely on a webhook URL configured in their own dashboard to notify your store that payment succeeded. If that URL isn't checked after migration, orders can appear unpaid even when the customer was charged.
- Migrating during a sale or peak period. Even a well-executed migration carries more risk during your highest-traffic window. Schedule it for a quieter period if you have any choice in the timing.
- Not testing the actual checkout flow on staging before cutover, only checking that the site "looks right."
How WebSpaceBar handles it
Every WebSpaceBar migration follows the staging-first sequence above by default: files and database copied to a staging URL while your current site stays fully live, a full review before anything changes, a final incremental sync to catch late orders, and only then a DNS cutover. For WooCommerce specifically, that includes checking payment gateway configuration and confirming the checkout flow works before your domain ever points at the new server.
Moving a live store?
Our engineers handle WooCommerce migrations specifically, not just a generic file copy. Business Hosting's 3 vCPU cores and 45GB NVMe storage are built for active stores.
Frequently asked questions
Will my store go offline during a WooCommerce migration?
Not with a properly handled migration. Your current site stays live on the old host while your files and database are copied to the new server in the background. The only brief window involved is DNS propagation at final cutover, which is typically minutes, not hours.
What happens to orders placed during the migration process?
A proper migration accounts for this by doing a final incremental sync of the database immediately before cutover, capturing any orders placed after the initial copy. This is why migrations should be handled by someone experienced with WooCommerce specifically, not just a generic file transfer.
Do I need to update my payment gateway after migrating?
Usually not the gateway credentials themselves, but you should check any webhook URLs configured in your payment gateway's dashboard, since some gateways reference your site's URL directly for callback notifications. This is one of the most commonly missed steps in a self-managed migration.
Why do images or checkout pages sometimes break after a WooCommerce migration?
The most common cause is hardcoded URLs stored inside the WordPress database rather than relative paths, left over from the site's original setup. These need a proper search-and-replace across the database during migration, not just a straight file copy, or images and links can point back to the old server.