Cloud Hosting Migration Without Downtime

Moving a live WordPress site from shared or managed hosting to a cloud provider like DigitalOcean, Vultr, or AWS Lightsail is one of those jobs where the failure mode is loud: broken checkout pages, missing images, or an hour of 502 errors while DNS catches up. It doesn’t have to be that way. A zero-downtime migration is mostly a sequencing problem, not a technical one — you build the new environment fully, verify it in isolation, and only then flip traffic over.

Why Downtime Happens in the First Place

Almost every bad migration traces back to one of three mistakes: DNS was changed before the new server was actually ready, the database was copied once and never re-synced with changes made during the cutover window, or file permissions on the destination server silently broke uploads and caching. None of these are cloud-specific problems — they’re sequencing problems that happen to be more visible on cloud infrastructure because you’re managing the stack yourself instead of a host doing it for you.

Step 1: Build the Destination Environment First, Fully Isolated

Spin up the new droplet, instance, or VPS and get the full stack — PHP version, web server, database — matched to what the site currently needs, not just “the latest version.” Mismatched PHP versions are the single most common cause of a white screen after migration. Install the site on a temporary subdomain or via a local hosts-file override so you can browse and click through the entire new environment before any real visitor sees it.

Step 2: Move the Database With a Tool That Rewrites URLs Safely

A raw mysqldump and import works, but WordPress serializes some data (widget settings, some page-builder content) as PHP serialized arrays, and those break if you do a naive find-and-replace on the domain. Use WP Migrate DB or the export/import feature in a plugin like All-in-One WP Migration, both of which understand serialization and rewrite URLs correctly instead of corrupting the array length prefixes. Run the migration, then spot-check five to ten posts with embedded media or widgets to confirm nothing rendered as broken shortcodes.

Step 3: Sync Files, Then Do a Delta Sync Right Before Cutover

rsync is the right tool for the wp-content directory — it’s incremental, so the first full sync can happen hours or days ahead of cutover, and a second delta sync (just the changed files) takes seconds right before you flip DNS. This is what actually eliminates downtime: the gap between “copy files” and “go live” shrinks from hours to under a minute.

Step 4: Lower the DNS TTL Days in Advance

DNS propagation delay is the part people forget to plan around. If your A record TTL is set to the default 24 hours, some visitors will keep hitting the old server for a full day after cutover, missing any orders or comments placed on the new one. Drop the TTL to 300 seconds (5 minutes) at least 48 hours before the migration. This single step removes most of what people call “unavoidable downtime.”

Step 5: The Actual Cutover — Freeze, Sync, Verify, Switch

Put the old site into maintenance mode (or a short read-only state) for the few minutes it takes to run the final delta sync of files and a fresh database export/import. Then update DNS. Because the TTL is low, most traffic redirects within 5–15 minutes. Keep the old server running and unchanged for at least 48 hours — it’s your instant rollback if something on the new stack misbehaves under real traffic.

Common Gotchas That Cause “Invisible” Downtime

• Object cache and page cache pointing at the old server’s Redis/Memcached instance — clear or reprovision these on the new box rather than assuming they’ll rebuild cleanly.
• Hardcoded IP allowlists in firewalls or CDN configs (Cloudflare, in particular) that only permit the old server’s IP to originate traffic.
• Cron jobs (WP-Cron or real system cron) still pointing at the old server for scheduled posts or backups.
• SSL certificate provisioning — if you’re using Let’s Encrypt, issue and verify the cert on the new server before cutover, not after, since first-time issuance can take a few minutes and will show visitors a certificate warning if it’s still pending.

Verdict

A cloud migration only causes downtime when steps get compressed under pressure. Build fully in isolation, drop your DNS TTL two days early, use a serialization-aware database migration tool, and treat the cutover itself as a five-minute freeze-sync-switch operation rather than an all-day project. Keep the old server alive as a rollback net for 48 hours and the whole migration becomes close to invisible to visitors.