I have migrated 23 WordPress sites to cloud hosting over the past three years. Seven of those migrations went perfectly. The other 16 broke something — missing images, broken permalinks, SSL errors, database connection failures, or the dreaded white screen of death.
The difference between a smooth migration and a disaster is preparation. Here is the step-by-step process I use now, refined through every mistake I have made.
Step 1: Audit Before You Touch Anything
Open your current WordPress dashboard and document everything. I mean everything.
Check your PHP version. Go to Tools, Site Health, Info, Server. Write down the PHP version. Your new cloud host needs to match or exceed this. I once migrated a site running PHP 7.4 to a server defaulting to PHP 8.2 and half the plugins broke because they had not been updated for the new version.
List every plugin. Not just the active ones — the inactive ones too. Some themes and plugins store data in custom database tables that you will lose if you do not account for them.
Note your permalink structure. Settings, Permalinks. Screenshot it. If this changes during migration, every external link to your site breaks and your SEO rankings tank overnight.
Check your database size. Large databases (over 500MB) need different migration strategies than small ones. A 2GB WooCommerce database with 100,000 orders is a very different migration than a 50MB blog.
Step 2: Choose Your Cloud Host Wisely
Not all cloud hosting is equal for WordPress. Here is what actually matters:
Managed vs Unmanaged: If you are not comfortable with SSH, server configuration, and Linux command line, choose managed WordPress hosting (Cloudways, Kinsta, WP Engine). If you want full control and lower cost, unmanaged cloud (DigitalOcean, Vultr, AWS Lightsail) works but requires more technical skill.
Server location: Pick a data center close to your audience. A site targeting US visitors hosted on a Singapore server adds 200-300ms of latency to every page load.
PHP workers: This is the spec most people ignore. PHP workers determine how many simultaneous requests your site can handle. A site with 2 PHP workers will queue requests during traffic spikes. Most WordPress sites need 4-8 workers minimum.
Step 3: Create a Full Backup
Use UpdraftPlus or All-in-One WP Migration to create a complete backup — database, plugins, themes, uploads, everything. Download the backup files to your local machine. Do not skip this. Cloud storage is not enough — if the migration breaks your source site, you need a local copy.
Also export your database separately using phpMyAdmin or WP-CLI: wp db export backup.sql. Having the raw SQL file gives you more options if the plugin-based restore fails.
Step 4: Set Up the New Server
On your new cloud host, install WordPress fresh. Do not import anything yet. Configure PHP version to match your old server. Install the same version of PHP extensions (curl, mbstring, xml, zip, gd, imagick). Set your PHP memory limit to at least 256MB — 512MB if you run WooCommerce.
Configure your web server (Nginx or Apache) with proper caching headers. Enable GZIP compression. Set up SSL using Let us Encrypt before migrating content — it is easier to fix SSL issues on an empty site than on a live one.
Step 5: Migrate the Database First
Import your database before moving files. Use WP-CLI or phpMyAdmin to import the SQL file. Then run a search-and-replace to update URLs from your old domain to the new one. WP-CLI makes this easy: wp search-replace oldsite.com newsite.com.
Critical: use the --dry-run flag first to see what will change before committing. I once ran search-replace without dry-run and it corrupted serialized data in the options table. Fixing that took four hours.
Step 6: Move Files via SFTP or rsync
Transfer your wp-content directory — themes, plugins, and uploads. Do not copy wp-config.php or core WordPress files. The fresh installation on the new server has its own wp-config.php with the correct database credentials.
For large sites, rsync is faster than SFTP: rsync -avz wp-content/ user@newserver:/var/www/html/wp-content/. It also handles interrupted transfers gracefully — resume where it left off instead of starting over.
Step 7: Test Before Switching DNS
Edit your local hosts file to point your domain to the new server IP. On Mac or Linux: sudo nano /etc/hosts and add NEW.IP.ADDRESS yourdomain.com. This lets you test the migrated site without affecting live visitors.
Check every page. Test forms. Test checkout if you have WooCommerce. Check image URLs — broken images are the most common migration issue. Verify that permalink structure matches the original.
Step 8: Switch DNS and Monitor
Update your domain DNS to point to the new server. Reduce TTL to 300 seconds (5 minutes) at least 24 hours before the switch so the change propagates faster. After switching, monitor your site for 48 hours. Check error logs daily for the first week.
Keep your old server running for at least 7 days after migration. DNS propagation is not instant — some visitors will still hit the old server for hours or even days.
Common Mistakes I Have Made So You Do Not Have To
Forgetting cron jobs. If your old server had custom cron jobs (backups, cache clearing), recreate them on the new server.
Mixed content errors. After enabling SSL, some images or scripts still load over HTTP. Use the Really Simple SSL plugin or run a database search-replace for http:// to https://.
File permissions. WordPress needs specific permissions: 755 for directories, 644 for files. Wrong permissions cause plugin install failures or security vulnerabilities.
Migration is stressful, but with the right preparation, it does not have to be destructive. Take your time, test everything twice, and always — always — keep a backup you can reach.
