Migrating a website to cloud hosting is one of those projects that feels bigger than it is — until something goes wrong. A botched migration can mean hours of downtime, lost orders, or a search ranking that takes months to recover. The good news is that website migrations are a solved problem: follow a phased plan, test at every step, and have a rollback ready, and the move becomes uneventful. That is the goal — a migration so smooth your visitors never notice it happened.
This checklist walks you through a complete migration to cloud hosting in six phases: audit and preparation, choosing your target, staging and testing, the actual migration, the DNS cutover, and post-migration monitoring. It works whether you are moving a small blog or a revenue-generating store, and it assumes you are moving from shared hosting, an old VPS, or a managed host to cloud infrastructure.
Phase 1: Audit What You Are Moving
Before touching anything, take inventory. You cannot migrate what you have not measured, and surprises during a migration are expensive. Spend a day on this phase — it pays for itself.
The migration inventory checklist
Write down every asset your site depends on: the website files themselves, the database, uploaded media, email accounts and forwarders, cron jobs or scheduled tasks, SSL certificates, DNS records (every A, CNAME, MX, and TXT record), third-party integrations (payment gateways, analytics, CDNs), and any server-side features like redirects, password protection, or custom error pages. For each item, note where it lives today and whether it needs to move. Email deserves special attention: many people forget that moving a domain to a new host can disrupt email if the MX records are not planned for. Decide up front whether email stays with the old provider, moves with the domain, or goes to a dedicated email service.
Take a performance baseline
Record your current page load times, server response times, and uptime before the move. Use a free speed test tool and note the numbers. This baseline is your success metric: after migration, you will compare the new numbers against the old ones. If you are migrating an online store, also note your conversion rate and checkout completion rate for the weeks before the move — hosting changes that affect performance show up in revenue, which is why choosing the right cloud hosting for an ecommerce store deserves its own planning before you migrate.
Phase 2: Choose Your Target Cloud Setup
With the audit complete, decide where the site is going. This is where the cloud’s flexibility matters: you pick the region closest to your visitors, the resources your audit says you need, and whether you want a managed platform or raw infrastructure. If the answer is not obvious, review how agencies structure cloud hosting for client sites — the patterns agencies use (isolated projects per site, separate billing, staging environments) are excellent defaults for any serious website.
Right-size, do not over-buy
Start with resources that match your current usage plus modest headroom — roughly a third above your observed peak is a sensible starting point for most sites. Cloud hosting lets you scale up later in minutes, so there is no prize for buying capacity you will not use this quarter. Note your current site’s disk usage, memory consumption, and bandwidth so you can pick a plan honestly instead of guessing. Keep a note of which levers you can pull later: vertical scaling (bigger server), horizontal scaling (more servers), caching, and CDN offload.
Lower your DNS TTL early
This is the single most important timing trick in a migration. DNS records have a TTL (time to live) that tells the internet how long to cache them — often set to 24 or 48 hours by default. At least 48 hours before your planned cutover, lower the TTL on your DNS records to something short, like 300 seconds (5 minutes). This ensures that when you flip the switch, the change propagates in minutes rather than days. Forgetting this step is the most common cause of “the migration worked for me but not for my customers” confusion.
Phase 3: Build and Test a Staging Copy
Never migrate directly onto a live domain for the first time. Instead, build a complete copy of your site on the new cloud server and test it before anyone visits. Most cloud setups let you preview the site through a temporary URL or by editing your own computer’s hosts file to point the domain at the new server’s IP — the latter is the most realistic test because your browser believes it is visiting the real site.
What to test on staging
Click through every important page, submit every form, and run a complete checkout if you sell anything. Check that uploads, search, login, and password resets all work. Verify SSL is in place and that both the www and non-www versions of the domain behave correctly. If your site sends email — order confirmations, contact form notifications, password resets — test that too, because email authentication (SPF, DKIM, DMARC records) is a frequent casualty of server moves. Finally, compare your staging performance against the baseline you took in Phase 1.
Freeze content changes
Once staging tests pass, put the live site into a change freeze if possible: no new posts, no new orders data you cannot reconcile, no settings changes. If the site must stay fully active (an ecommerce store cannot simply stop taking orders), plan for a final data sync — database and uploads — in the minutes before cutover. For stores with constant activity, schedule the cutover during your lowest-traffic window, typically the middle of the night for your primary audience’s timezone.
Phase 4: Execute the Migration
With staging verified and changes frozen, it is time to move. The execution phase has a strict order, and doing it in this order minimizes risk.
The migration runbook
First, take a final full backup of the old site — files and database — and store it somewhere you control, not just on the old server. Second, perform the final sync of any changed data (uploads folder, database) to the new server. Third, verify the new server one more time with the hosts-file trick: it should be byte-for-byte current. Fourth, update the DNS records to point at the new cloud server. Fifth, watch the DNS propagation and confirm the live site is being served from the new infrastructure — a simple way is to check the server’s response headers or a DNS lookup tool from several locations.
Do not cancel the old hosting yet
This is where the rollback plan lives. Keep the old hosting account active for at least one to two weeks after the cutover. If anything goes wrong — a plugin that breaks under the new PHP version, an integration that only worked on the old server — you can flip DNS back in minutes because you already lowered the TTL. Only cancel the old account after you have a full billing cycle of clean operation on the new server, and after you have confirmed that email, cron jobs, and backups are all running correctly in the new home.
Phase 5: The DNS Cutover, Carefully
The DNS change itself is a single action, but the hours around it need attention. Make the change when you can monitor for at least an hour afterward — not right before bed, and not on a Friday afternoon unless you enjoy weekend emergencies.
Watch propagation like a hawk
Use a DNS propagation checker to confirm the new records are visible from resolvers around the world. Because you lowered the TTL in Phase 2, most visitors will reach the new server within minutes. Expect a small number of stragglers on old DNS caches — this is normal and harmless as long as both servers are serving a working site. Keep the old server running during this window so nobody hits a dead end.
Re-verify SSL and email
Immediately after cutover, confirm the SSL certificate is valid on the live domain and that there are no mixed-content warnings (HTTP resources loading on an HTTPS page). Then send yourself test emails from every form and transactional flow on the site. Email issues are the most common post-migration complaint, and they are silent — nobody tells you your contact form stopped working until you wonder why inquiries dried up.
Phase 6: Post-Migration Monitoring
The migration is not finished when DNS propagates — it is finished when you have a week of clean data proving the new setup performs. Set up or reconnect your monitoring now: uptime checks, performance tracking, and error logging on the new server.
The first-week checklist
Compare the new performance numbers against your Phase 1 baseline; they should be equal or better. Check server logs for errors you did not see in staging — real traffic always finds edge cases. Verify that scheduled tasks, backups, and security updates are running on the new server, not the old one. Review your first cloud bill carefully so the pricing model is no surprise, and set up billing alerts so you will know if usage spikes. If you run an agency, this is also the moment to update your client documentation — which is part of the ongoing playbook for managing client sites on cloud hosting.
Cleanup and lessons learned
After one to two stable weeks, cancel the old hosting, remove the temporary staging URLs, and restore your DNS TTL to a normal value (a day or two is typical — short TTLs are for migration windows, not forever). Write down what went well and what did not; a one-page migration retrospective makes the next move dramatically easier. Migrations get routine with practice, and a documented runbook turns a stressful project into a checklist you can delegate.
Done properly, a cloud migration delivers exactly what the cloud promises: a faster, more scalable foundation for your site, with zero drama along the way. The checklist above is deliberately conservative — every phase exists because skipping it has caused a real outage somewhere. Follow it in order, keep your rollback ready, and your visitors will never know the ground moved beneath them.
