How to Tell Whether Your Site Actually Needs to Migrate
A lot of people start on shared hosting like Bluehost because the price makes sense at the beginning. As traffic grows, shared hosting stops keeping up. For sellers who don't want to manage servers manually but do want real performance, Cloudways sits in a useful middle ground. Here are the signals that your current server has become the actual bottleneck: the admin panel takes more than 3โ5 seconds to load; adding to cart or entering checkout is noticeably sluggish; running ads causes the server CPU to stay pegged at capacity; 502 or 504 errors appear during peak hours; database queries have slowed down to the point where WooCommerce Analytics won't load properly.
If the problem is "occasionally a bit slow," try optimizing the cache configuration, cleaning up the database, and trimming the plugin list on the existing server first. Migration may not be necessary. If three or more of the symptoms above apply, the issue is resource-level โ plugin optimization won't fix it.
What Cloudways is and why it suits WooCommerce is covered in detail in the Cloudways WooCommerce setup guide on this site. The short version: it's a managed cloud platform that lets you choose DigitalOcean, Vultr, AWS, or Google Cloud as the underlying infrastructure (check the current Cloudways panel for available options), and it handles the server environment for you โ PHP versions, MySQL, Nginx configuration, all managed.
What to Do Before the Migration
First, back up the entire site โ completely. If something goes wrong during migration, the cost can be lost order data. A backup is non-negotiable. Use UpdraftPlus to back up both files and database, and push the backup to Google Drive or Dropbox. Don't leave it sitting only on the existing server. Confirm the backup completed successfully and can be restored before touching anything else.
Second, lower the DNS TTL 24 hours in advance. Before migration, drop the domain's DNS TTL from the default 3,600 seconds (one hour) down to 300 seconds (five minutes). Lower TTL means the DNS change propagates faster โ once you point the A record to the new server, most visitors will switch over within five minutes rather than waiting an hour.
Third, migrate during a low-traffic window and consider enabling maintenance mode. If orders come in around the clock, there's a risk of new orders being written to the old database after migration has already completed, resulting in lost orders. Plan the migration for the quietest time of night and put the old site in maintenance mode during the process to prevent new data from being written there.
How to Migrate: Using the Cloudways Official Migration Plugin
Two approaches exist: the Cloudways official migration plugin (suitable for most users) and manual migration (for the technically experienced). Manual migration gives you more control โ the steps are: export the database via phpMyAdmin โ upload the wp-content directory via SFTP โ import the database โ update wp-config.php with the new database connection details โ run Better Search Replace to swap out the old domain in the database. For most non-technical sellers, the plugin route is the right call.
Step 1 โ Create the destination server and application in Cloudways. Log into Cloudways, click Add Application, and select WordPress with WooCommerce (not plain WordPress). Choose your cloud provider โ DigitalOcean works for most starting cases โ and select a server size. A store with stable monthly revenue should start at 2 cores and 4GB RAM at minimum; if you're running ads with traffic spikes, go straight to 4 cores and 8GB. Wait for the server to finish provisioning, then note the server's IP address and the application's SFTP credentials (found in Access Details).
Step 2 โ Install the migration plugin on the old site. In the old site's WordPress dashboard, go to Plugins โ Add New, search for Cloudways WordPress Migrator, and install and activate it.
Step 3 โ Enter the destination server details and start the migration. In the plugin, enter the SFTP Host, Username, Password, and Database Name provided by Cloudways, then click Migrate. The plugin transfers WordPress files, the database, images, plugins, and themes. Migration time depends on site size โ a small site at a few hundred MB might finish in minutes, while a multi-gigabyte store could take 30โ60 minutes.
Step 4 โ Test thoroughly before switching DNS. In the Cloudways panel, access the new site through the temporary URL (in the format *.cloudways.net) and test systematically: homepage loading, product pages, add to cart, checkout entry, and the payment flow. Don't skip this step. Finding issues before the DNS cut is made means fixing them without anyone noticing. Finding them after real visitors are hitting the new server is a different situation entirely.
Step 5 โ Switch DNS once everything checks out. Go to your DNS management โ Cloudflare or your domain registrar โ and update the A record from the old server IP to the new Cloudways IP. If you're using Cloudflare, temporarily set it to DNS-only (the grey cloud icon) during the cutover so traffic routes directly to Cloudways without the proxy layer. After the new server has been running stably for a day or two, re-enable the Cloudflare proxy to restore CDN and DDoS protection.
Things to Check After Migration
Payment webhook verification is the most important post-migration step. If the domain didn't change, Stripe and PayPal webhook endpoints are usually still functional โ but go verify in each platform's dashboard. In Stripe, go to Dashboard โ Developers โ Webhooks and review recent webhook delivery records. If there are errors, resend a test webhook and confirm the new server receives it correctly. API keys don't need to change, but if wp-config.php was overwritten during migration, confirm that API key settings in the plugins are still intact.
Enable Cloudways' built-in caching and Redis. Cloudways provides Breeze Cache for page caching and Redis for object caching โ both can be activated with one click from the control panel, and neither requires installing WP Rocket or any separate caching plugin. Redis is particularly useful for WooCommerce because a store generates far more database queries than a typical blog, and Redis keeps high-frequency query results in memory, significantly reducing database load.
Re-enable or reconnect Cloudflare. If the Cloudflare proxy was disabled during migration, bring it back once the new server is stable and confirmed working. That restores CDN delivery and DDoS protection.
Review the plugin list. Every plugin migrated over, including ones that were deactivated or forgotten. Post-migration is a natural opportunity to clean house โ delete deactivated plugins outright rather than just leaving them sitting there. Deactivated doesn't mean removed; the files are still on the server.
Handling Orders Lost During Migration
If maintenance mode wasn't enabled and new orders were written to the old database during the migration window, the recovery path is: export from the old database any orders that came in after the migration started, then manually import them into the new database. This involves using phpMyAdmin to run a SQL query filtering orders by timestamp, then inserting those records into the WooCommerce order tables (wp_posts and wp_postmeta) on the new server. For small order volumes, manually re-entering them in the new backend is also an option. The situation is entirely avoidable by enabling maintenance mode before starting.
Cost Reference
| Server Size | Monthly Cost Estimate | Best Fit |
|---|---|---|
| Small store (2 cores, 4GB) | ~$14โ30/month | Tens of orders per day, under 500 products |
| Growing store (4 cores, 8GB) | ~$40โ80/month | Active ad spend, hundreds of daily visitors |
| High-traffic store | $100+/month | High order volume, multi-language stores |
Verify current pricing on Cloudways' site โ plan structures and costs are subject to change. Domain registration ($10โ15/year), Cloudflare free tier, Let's Encrypt SSL, and WooCommerce itself remain free regardless of server choice.