Migrating a WooCommerce store to Cloudways safely

By Abdalla Kamesh · Updated October 9, 2026 · Published October 2, 2026 · 5 min read

Disclosure: this post contains affiliate links to Cloudways. If you start a plan through one, StoreToNative may earn a commission at no extra cost to you. The migration procedure is generic; the Cloudways-specific tools mentioned are described on their own pages.

Migrating a live store is nerve-wracking for one specific reason: orders. A migration that loses an afternoon’s orders is not an inconvenience, it is customers who paid you and have no record of it.

The procedure below is built around never being in a position where that can happen. It takes an evening, and most of it is waiting.

Before you start: three decisions

1. Which cloud and which region. Cloudways sits on top of DigitalOcean, Vultr, Linode, AWS or Google Cloud. DigitalOcean is the sensible default. As of October 2026 their Micro plan is $14/month (1 GB RAM, 1 vCPU, 25 GB NVMe, 1 TB bandwidth) — fine for a blog, too small for a store — so the realistic floor for WooCommerce is Small at $28/month (2 GB RAM, 1 vCPU, 50 GB NVMe, 2 TB bandwidth). Put the server in the region where your customers are — latency is geography.

2. Which size. Start smaller than you think; resizing later is a slider rather than a migration. Under 500 products, the entry plan is usually right.

3. How you will move the files. Two options: the Cloudways WordPress Migrator plugin, or their free migration (one included for new users). Either is fine. The migrator plugin gives you control over timing, which matters for step 7 below.

They also offer a 3-day free trial with no credit card, which is enough to do everything up to the DNS switch and decide with real numbers.

The migration, in order

1. Create the server and application

Cloud, region, size, and a WordPress-with-WooCommerce application. Note the new server’s IP address; you need it in step 3.

2. Copy the site

Run the migrator plugin on your current store, or hand it to the migration team. This copies files and database to the new server. It does not touch your live site.

3. Test with your hosts file — do not skip this

This is the step that makes the whole procedure safe. Edit your local machine’s hosts file to point your domain at the new server’s IP:

203.0.113.10   yourstore.com www.yourstore.com

Now your browser sees the new server while every customer still sees the old one. You can test the real domain, on the real site, with no risk.

4. Test properly while you are in there

Not a homepage glance. Specifically:

Place a real order with a real card. This is the step that catches gateway configuration tied to the old server’s IP, missing SSL, or a webhook URL that no longer resolves.
Test a refund.
Check the transactional emails actually arrive — order confirmation, admin notification. Email is the most commonly broken thing after a move.
Log in as a customer and check order history.
Click through wp-admin. Products, orders, settings.
If you have a mobile app, hit the REST API:

curl -s "https://yourstore.com/wp-json/wc/v3/products?per_page=5&consumer_key=…&consumer_secret=…" | head -c 400

with the hosts file still pointed at the new server. You want a JSON array with prices and images, not an HTML error page.

5. Configure the stack

Now, before the switch, not after:

Enable Redis and the object cache plugin. Confirm it says connected, not merely installed. Why this is the biggest single win.
Set the PHP version to a current 8.x, having tested your plugins.
Configure Varnish exclusions: cart, checkout, my-account and /wp-json/ must never be page-cached.
Enable automated backups, and note the retention.
Set up a real server cron for wp-cron.php.
Create the staging environment — an app makes this mandatory.

6. Lower your DNS TTL

At least a day before the switch, drop the TTL on your A record to 300 seconds. This makes the actual cutover propagate in minutes rather than hours, and it makes a rollback fast if you need one.

7. The final sync, then the switch

This is the orders question, answered.

Pick a quiet hour. Look at your own order-time distribution and choose the trough.
Put the old site into a brief maintenance mode, or accept a few minutes’ gap. For most stores a five-minute window at 4am costs nothing.
Re-sync the database so orders placed since step 2 come across. The migrator plugin can do an incremental pass; otherwise export and import the orders tables.
Switch the DNS A record to the new IP.
Watch propagation and take the old site out of maintenance mode once traffic is arriving at the new server.

If you skip the re-sync, the orders placed between the copy and the switch are on a server nobody is looking at any more. That is the failure mode this whole sequence exists to prevent.

8. After the switch

Issue SSL on the new host and verify no mixed-content warnings.
Place another real order, on the live site this time.
Re-check the REST API, and confirm your app’s product screens load.
Check WooCommerce → Settings → Advanced → Webhooks are Active — a move is a common cause of webhook failures, and stale catalog data in an app is the symptom. Why sync breaks.
Keep the old host running for a week. It is cheap insurance and it is the rollback.
Restore a backup on the new host, once, to prove the backup works.

The five things that most often break

Email. Different server, different sending reputation and configuration. Test transactional email explicitly.
Payment gateway callbacks. Webhook and IPN URLs, and anything IP-allowlisted with your gateway.
Cron. Scheduled sales, subscription renewals and abandoned-cart timers all depend on it.
File permissions, showing up as failed uploads.
A security plugin’s server-specific config, sometimes blocking /wp-json/ on the new host.

The one-line summary

Copy, test through your hosts file with a real order, configure the cache stack, lower the TTL, re-sync the database at a quiet hour, switch DNS, then test again and keep the old host for a week. The hosts-file test and the final re-sync are the two steps that make it safe — everything else is just careful.

Related reading