How to Migrate an E-commerce Store with Less Downtime
Author: [TO BE CONFIRMED] · Published: October 25, 2026
Moving a brochure site to a new host is a file copy with a DNS change. Moving a live store is different: orders arrive while you are moving, stock changes with every sale, and a customer who checks out during the move must not lose their order — or pay twice. A migration that ignores that reality can lose sales that no amount of speed on the new server will win back.
This guide is a practical plan for moving a WooCommerce store with as little downtime, and as little risk, as possible.
The principle: never migrate the live store directly
The safe pattern is always the same: copy, test, then switch. You build a complete copy of the store on the new server, test it thoroughly while the old store keeps trading, and only then point traffic at the new server — during a short, planned window, with a way back.
If a migration plan starts with “take the old site down and move it”, stop. That plan guarantees downtime and gives you no rollback if something fails halfway through.
Before you start: the pre-migration checklist
Back up everything on the old server — files and database — and confirm the backup is restorable. This backup is your rollback, not just a precaution. See How to Plan Backups for an Online Store.
Record the current environment: PHP version, MySQL/MariaDB version, WordPress and WooCommerce versions, plugin and theme versions, and any server-level settings (memory limits, cron jobs, redirects, SSL certificate details).
Check compatibility on the new server first. Confirm the new server runs PHP 8.3 or 8.4, MySQL 8.0+ or MariaDB 10.6+, and the memory and worker limits your store needs — see WooCommerce Hosting Requirements for a Growing Store. A plugin that works on PHP 8.1 may not work on PHP 8.4; find that out on staging, not on launch night.
Lower the DNS TTL at least 24–48 hours before the move (for example, to 300 seconds). DNS changes propagate faster when the TTL is low, which shortens the window in which some visitors reach the old server and others reach the new one.
Choose a low-traffic window from your analytics — usually overnight on your quietest day — and tell your team (and, if the window involves any interruption, your customers) in advance.
Freeze non-essential changes. Ask the team not to add products, change prices, or install plugins during the migration. Every change made on the old store after the copy is a change you must sync later.
Step 1: copy the store to the new server
Copy the files and the database to the new server. Use a migration plugin, a managed migration service from the new host, or a manual copy with rsync and mysqldump — whichever you choose, the method matters less than verifying the result.
Copy the full WordPress installation, including wp-content/uploads, themes, plugins and wp-config.php (with new database credentials).
Export and import the database, and confirm the row counts match.
Update the site URL if the staging copy uses a temporary domain, and check for hard-coded URLs in the database — a search-and-replace that handles serialised data correctly is essential, because a naive find-and-replace can corrupt serialised plugin settings.
Install the SSL certificate on the new server before testing, so checkout and payment testing reflect the live setup.
Step 2: test on staging, thoroughly
Test on the staging copy with a temporary domain or a hosts-file entry — never test by pointing the live domain at an unproven server. Work through the full customer journey:
Browse the homepage, category and product pages; check images, prices and stock.
Search and filter products.
Add items to the cart, apply a coupon, and change quantities.
Check out as a guest and as a logged-in customer, in the payment gateway’s test mode, and confirm the order email arrives.
Test account login, password reset, and order history.
Process a refund and a stock adjustment in the admin area.
Check contact forms, email deliverability, and any integrations (shipping, accounting, CRM, marketing tools).
Confirm that cart, checkout and account pages are excluded from caching, and that no shopper sees another’s cart.
Fix every issue on staging. If a plugin fails on the new PHP version, resolve it here — update it, replace it, or stay on a compatible PHP version and plan the upgrade separately.
Step 3: the final sync and the switch
This is the delicate part, because the old store has kept trading while you tested. Orders, customers and stock have changed since your copy was made. You must close that gap.
Option A — a short maintenance window (simplest and safest for most stores). Put the old store into maintenance mode, or enable a “catalogue mode” that stops new orders, at the start of your low-traffic window. Take a fresh database export, import it on the new server, verify the order count matches, then update DNS to point at the new server. The window is typically minutes to an hour, and no order is lost because no order could be placed during the freeze.
Option B — a live delta sync (for stores that cannot stop). Keep the old store trading, use a migration tool that syncs the database delta, and switch DNS with a low TTL. This is more complex, and you must verify after the switch that every order placed during the migration exists on the new server, with the right stock levels. For most small and mid-size stores, Option A is the right choice — a short, announced pause is cheaper than a lost order.
Whichever option you use:
Update DNS and confirm propagation from several locations, not just your own desk.
Keep the old server running, untouched, for at least a week after the switch. It is your instant rollback.
Monitor the new store closely for the first 48 hours: orders, payments, emails, error logs, and checkout speed.
Step 4: verify after the switch
Do not declare the migration done when DNS resolves. Verify:
Orders: the order numbers continue from the old store without gaps or duplicates, and every order placed around the switch is present.
Stock: quantities match the old store’s final state.
Payments: a real (small) live payment succeeds, webhooks arrive, and refunds work.
Email: order confirmations, shipping notifications and password resets are delivered and not landing in spam.
Search and SEO: the site is crawlable, redirects from any changed URLs are in place, and Search Console shows no sudden error spike.
Decide the rollback trigger before the switch: for example, “if checkout fails, or orders are missing, after 30 minutes of investigation, we revert DNS to the old server.” Reverting DNS with a low TTL is fast; rebuilding a broken store is not. Keep the old server live and unchanged until you are confident, then — and only then — cancel it. Never delete the old server in the same week as the migration.
Common mistakes
Migrating during a sale or campaign. Never. The busiest week is the worst week to move.
Forgetting email. DNS includes MX records. If you move DNS without moving the mail records correctly, order emails stop. Check MX, SPF, DKIM and DMARC on the new DNS.
Forgetting cron jobs. Scheduled tasks, subscription renewals and stock syncs often run from server cron. Move them, and test them.
Testing with the wrong URL. Hard-coded URLs in content, emails or integrations that still point at the old domain will break silently after the move.
No backup before the move. If the migration corrupts the database and there is no verified backup, the store is gone. Back up first, always.
Cancelling the old hosting too soon. Keep it for at least a week, preferably two, after a clean switch.
The bottom line
A low-downtime store migration is a staged move: copy, test the full customer journey on staging, freeze orders briefly, sync the final database, switch DNS with a low TTL, verify orders, stock, payments and email, and keep the old server as a rollback for a week. The extra hours of preparation are what make the actual switch boring — and a boring migration is a successful one.
For a new home for your store, see our WooCommerce hosting plans. [TO BE CONFIRMED: whether Offshore Hosting offers a managed WooCommerce migration service, and what it includes.]
Sources
MonoVM — How to Backup a Server or VPS: The Ultimate 2026 Guide: https://monovm.com/blog/how-to-backup-a-server-or-vps/
High-Availability.com — Snapshots vs. Backups: Securing Your Data: https://blog.high-availability.com/episode-18-snapshots-vs-backups-securing-your-data/
Email on your own domain looks professional and stays yours when you change providers. This guide explains what business email hosting involves, how it differs from free webmail, and the DNS and deliverability pieces that make it work.
Latency figures are widely quoted and widely misunderstood. This guide explains what ping measures, which hop actually matters, and the limits of what a VPS can do.
Webhooks, queue mode, and execution retention decide whether n8n stays fast or slowly fills its database. This guide explains each one and the settings that matter.