How to Migrate Your Website to Cloud Hosting Without Any Downtime

Fear of downtime is the number one reason teams put off moving to cloud hosting. Fair enough — even an hour of outage feels like an emergency when your site handles orders or customer traffic.

But here's the thing: plan the migration correctly, and there's zero downtime. No error pages, no dropped emails, no broken forms. The cutover happens in the background — you're the only one who knows it happened.

Migrations do go wrong, though — almost always because someone rushed it, skipped testing, or forgot about email. Here's the full process, plus the mistakes that actually bite.

Pre-Migration Checklist

Don't migrate on a Friday afternoon or right before a big traffic event. Pick a low-traffic window.

Access you'll need:

• [ ] Hosting control panel login (cPanel, Plesk, etc.)
• [ ] Domain registrar login (often a different company than your host)
• [ ] FTP/SSH access to your current server
• [ ] Database credentials (WordPress, WooCommerce, or whatever CMS you run)

Backups:

• [ ] Full backup of files, database, email accounts, and DNS records
• [ ] Downloaded and stored locally — don't trust your host to have one

Tip: Screenshot your current DNS records before changing anything. Bad DNS records are the #1 cause of migration headaches, and you can't restore what you didn't record.

Inventory what's tied to your domain:

• [ ] Website files + database
• [ ] Email (hosting provider, Google Workspace, or other?)
• [ ] Subdomains
• [ ] SSL certificates
• [ ] Cron jobs / scheduled tasks
• [ ] Any third-party services pinned to your server's IP

Step 1 — Provision the New Cloud Server

Set up a clean environment matching (or exceeding) your current stack — same PHP version, same DB engine, same web server software, or newer if your app supports it.

This typically takes a few hours and doesn't touch your live site at all — the new server runs standalone until you're ready.

Lock down security now: automatic updates, firewall rules, fail2ban for SSH. Do this before any data transfers.

Step 2 — Transfer Files and Database

# Example: syncing files directly for a larger/custom app
rsync -avz -e ssh /path/to/site/ user@new-server:/path/to/site/

# Example: dumping and transferring a MySQL database
mysqldump -u user -p dbname > backup.sql
scp backup.sql user@new-server:/tmp/

• WordPress/WooCommerce: Duplicator or All-in-One WP Migration packages everything into one file you upload and extract.
• Larger/custom apps: rsync over SSH is faster and more reliable.
• Database: mysqldump or phpMyAdmin export/import — usually minutes even for large datasets.

⚠️ Do not touch DNS yet. The old server is still serving live traffic. The new one is just a private copy only you can see.

Step 3 — Test on the New Server

The step everyone's tempted to skip — don't.

Edit your local /etc/hosts file to point your domain at the new server's IP. Only your machine sees the new version; everyone else still hits the old server.

Test checklist:

• [ ] Homepage loads with all assets/styles
• [ ] Internal links work
• [ ] Contact form submits
• [ ] Checkout flow works (if e-commerce)
• [ ] SSL is valid, no browser warnings
• [ ] Cron jobs / scheduled tasks run
• [ ] Email sends and receives correctly

Common failure points here: hardcoded file paths, mixed-content warnings (HTTP assets on HTTPS pages), and DB connection errors from mismatched credentials.

Step 4 — Lower Your DNS TTL

1–2 days before cutover, drop your DNS TTL from the default (often 86400s / 24h) down to ~300s (5 min).

Lower TTL = faster propagation. Most visitors reach the new server within minutes of the switch instead of waiting up to a full day.

Step 5 — Switch DNS and Go Live

Update the A record (or nameservers) at your registrar to point to the new server's IP.

With a low TTL, most traffic shifts within 5–30 minutes. Some visitors may briefly hit the old server, some the new one — since both serve identical content, nobody notices.

Keep the old server running for 48–72 hours post-switch as a fallback — some resolvers are slow to update.

Step 6 — Post-Migration Verification

Once DNS has fully propagated (~24h to be safe), re-run your checklist on the live site:

• [ ] All pages load correctly
• [ ] Forms deliver to correct addresses
• [ ] Payment processing works (test transaction if possible)
• [ ] Email sends/receives normally
• [ ] Analytics/Search Console tracking correctly
• [ ] Third-party integrations (CRM, APIs, marketing tools) connected

Only decommission the old host once everything is fully verified.

Common Mistakes

• Forgetting email. If email lived on the old host, switching DNS without setting up email on the new server first kills it outright. Migrate email first, or move to a dedicated service.
• Skipping backups. Don't assume your host has one — some don't, some are stale. Take your own.
• Changing too much at once. Don't redesign, upgrade the CMS, or add plugins on migration day. Migrate → let it settle a week → then change things, so you can isolate the cause if something breaks.
• Ignoring SSL. Make sure a fresh cert is live on the new server before DNS switches, or visitors get security warnings (and some browsers block the site entirely).

Timeline

For a typical WordPress/WooCommerce site: 24–48 hours total, mostly DNS propagation. Server setup + file transfer + testing is usually 3–6 hours.

Larger sites with custom apps, multiple databases, or complex configs can take longer — some enterprise migrations get a full week of prep and testing before cutover.

FAQ

Will I lose data during migration?
No — the new server copies files/DB, it doesn't remove them from the old server. Originals stay until you're confident and choose to delete them.

Can I migrate e-commerce without losing orders?
Yes — run one final DB sync right before the DNS switch to capture orders placed during the migration window.

Do I need to update my registrar?
You'll update the A record or nameservers in DNS settings at your registrar — your host/migration team can specify exactly what to change.

What if something breaks post-migration?
Point DNS back to the old server (still running as fallback) within minutes — this is why keeping it alive for 72h matters.

Originally published on the Qaaf Cloud blog.