Moving a website and domain to cloud hosting without downtime requires more than copying files. This reusable checklist covers preparation, DNS changes, testing, rollback, email protection, SSL, and post-migration SEO checks so you can switch hosting providers with controlled risk.
Overview
A website migration usually involves several separate systems: the application or CMS, databases, uploaded files, DNS records, SSL certificates, email services, analytics, and search-engine signals. Treating the move as a single “change the IP address” task is a common source of outages.
The safest approach is to build and test the new cloud environment before changing public DNS. Keep the existing site available while you copy its content, lower DNS time to live (TTL) values ahead of the cutover, and document every record and dependency. The domain registrar and hosting provider do not have to be the same company; in many migrations, you move the website while leaving domain registration and email unchanged.
For background on the broader process, see the website migration checklist and shared hosting versus cloud hosting guide. This article focuses on a migration where the destination is cloud hosting, a cloud load balancer, or a comparable managed platform.
Define the migration boundary
Before making changes, write down what is moving and what is staying. The website may move to a new server while the domain remains at its current registrar. Email may remain with a separate provider. A CDN, payment service, API, or staging system may use different DNS records. This inventory determines which records can be changed safely and which must remain exactly as they are.
Choose a cutover window
Schedule the final DNS change during a period when someone can monitor the site and respond to errors. Avoid launching immediately before a campaign, product release, billing cycle, or holiday traffic period. A low-traffic window reduces operational pressure, but it does not replace testing.
Checklist by scenario
Before any migration: build the pre-migration checklist
- Inventory DNS: Export or record A, AAAA, CNAME, MX, TXT, NS, and any relevant CAA records. Note the purpose and current destination of each record.
- Confirm ownership and access: Verify access to the domain registrar, DNS provider, current host, new cloud host, email platform, CDN, analytics, and deployment tools. Check that the domain is not unexpectedly locked if a registrar transfer is also planned.
- Back up the application: Create an application backup, database dump, and copy of user uploads, configuration files, environment variables, and scheduled-job definitions. Store at least one copy outside the current host.
- Record the live state: Capture the current CMS version, plugins or extensions, runtime version, database engine, redirects, cron jobs, server rules, and integrations. Record current uptime and representative page-load measurements for comparison.
- Map URLs: Crawl the current site or export its URL list. Include canonical URLs, XML sitemaps, important landing pages, media paths, robots.txt, and pages that receive organic traffic. This becomes the SEO comparison set.
- Review email: Document MX, SPF, DKIM, DMARC, and any verification TXT records. Do not replace email records with the new web host's defaults unless email is intentionally moving too. The SPF, DKIM, and DMARC guide explains the records that commonly need protection.
- Lower DNS TTL: If your DNS provider permits it, reduce the TTL on records that will change before the migration. Do this early enough for the previous, longer TTL to age out. A lower TTL can make a later change easier to reverse, but it cannot control resolvers that retain records beyond the requested period.
- Plan SSL: Confirm how the destination will issue and renew the certificate. Prepare every hostname that needs coverage, including the www hostname, API subdomains, and other public endpoints. Do not assume that a certificate at the old host will be available at the new one.
When moving a site but keeping the registrar
Create the site on the new cloud host using a temporary hostname, preview URL, or local hosts-file override. Keep the authoritative nameservers and registrar settings unchanged. At cutover, change only the web records required by the new architecture, such as the A, AAAA, or CNAME record. This minimizes the chance of accidentally changing mail, verification, or delegated DNS records.
When changing nameservers or transferring the domain
Separate the registrar transfer from the hosting cutover when possible. First reproduce the complete DNS zone at the new DNS provider, verify every record, and confirm that DNSSEC requirements are understood. If DNSSEC is enabled, coordinate the DS record and signing configuration carefully; an inconsistent DNSSEC change can make a domain unreachable even when the web server is healthy. A domain transfer can also have administrative timing and lock considerations, so do not combine it with an urgent website launch unless you have a tested recovery plan.
When migrating WordPress or another database-backed CMS
Put the destination into a controlled state while copying the database and files. For sites with frequent comments, orders, registrations, or form submissions, plan a final synchronization or brief maintenance period so new data is not lost between the first copy and the DNS change. Test the site's home page, login, search, forms, media, scheduled tasks, caching, and administrator functions on the new host.
Rollback and template deployment plan
Write the rollback steps before cutover. The simplest rollback is usually to restore the previous web DNS value, provided the old host remains intact and writable during the observation period. Record the old and new values, the exact DNS records to change, the person authorized to approve rollback, and the checks that trigger it.
For local testing, use a hosts-file entry or the platform's preview feature to send your computer to the new server without changing public DNS. Test representative URLs, redirects, cookies, headers, forms, and authenticated areas. Keep emergency redirect rules version-controlled and ready, but do not use redirects to hide a broken application or incorrect URL mapping.
What to double-check
DNS and domain behavior
After the change, query the authoritative nameservers and several public resolvers. Check the apex domain and every important subdomain over both IPv4 and IPv6 if AAAA records are in use. Confirm that the new target is correct and that old records have not created inconsistent responses. Review the practical differences among A, CNAME, MX, TXT, and NS records in the DNS records guide.
SSL, redirects, and application behavior
Open HTTP and HTTPS versions of the main hostnames. Check certificate validity, hostname coverage, redirect status codes, mixed-content warnings, security headers, and any CDN-to-origin certificate settings. Then test the application rather than only the landing page: submit a form, authenticate, upload a file, search, place a test transaction if appropriate, and inspect error logs.
Use permanent redirects only where the URL has actually changed. Preserve existing paths and canonicals whenever possible. Compare the pre-migration crawl with a post-migration crawl to find accidental 404 responses, redirect chains, noindex directives, blocked assets, changed canonicals, or a missing XML sitemap. The SSL certificate guide covers common certificate and renewal issues.
Post-migration audit table
| Area | Check | Pass condition |
|---|---|---|
| Uptime | Monitor the homepage and key transactions | No unexplained errors or timeouts during the observation period |
| DNS propagation | Query authoritative and public resolvers | Expected web records resolve consistently; mail records remain correct |
| SSL | Test each public hostname over HTTPS | Certificate is valid, trusted, correctly named, and renewable |
| Send and receive test messages; inspect authentication | Mail flows normally and SPF, DKIM, and DMARC behavior is unchanged or intentionally updated | |
| Indexed URLs | Compare crawl output, canonicals, robots.txt, and sitemap | Important URLs return expected status codes and remain eligible for indexing |
| Performance | Compare representative page loads and server response time | No unexplained regression after caching and CDN settings settle |
Keep the old hosting account available until the new environment has passed these checks and the normal DNS transition period has elapsed. The correct retention period depends on your TTLs, traffic pattern, and rollback tolerance.
Common mistakes
- Changing nameservers without copying the zone: This can remove mail, verification, and subdomain records. Recreate and verify the full zone first.
- Testing only the homepage: Broken forms, checkout flows, media, logins, APIs, and scheduled jobs may not appear on a simple page check.
- Forgetting IPv6: An old AAAA record can send some visitors to the previous server even after the A record is correct.
- Editing DNS and registering a domain at the same time: Multiple simultaneous changes make diagnosis harder. Separate them unless there is a compelling operational reason.
- Deleting the old host too soon: Keep a verified backup and a rollback path until monitoring and business-critical tests are complete.
- Replacing email records with hosting defaults: Web hosting and email hosting are separate services in many setups. Preserve MX and authentication records unless email is intentionally migrating.
- Launching with a temporary noindex or password: Remove staging restrictions deliberately, then verify robots.txt, meta robots, authentication, and access-control settings.
- Assuming DNS is instant: Different networks may observe old and new values during the transition. Use monitoring from more than one network and keep the previous environment ready.
When to revisit
Use this checklist before every planned move to cloud hosting, not only the first migration. Revisit it before seasonal planning cycles, major campaigns, platform upgrades, domain or DNS changes, CDN replacements, and changes to email providers. Provider control panels and deployment architectures can change, so confirm current instructions for load balancers, origin addresses, DNSSEC, certificate automation, and rate limits rather than copying an old screenshot or command.
Run the post-migration audit again after a major infrastructure change, an SSL renewal redesign, a nameserver update, or a performance configuration change. Keep a dated copy of the DNS inventory, crawl comparison, backup confirmation, and rollback plan in your operations documentation.
Practical next step: create a migration worksheet with four columns—record or component, current value, planned value, and verification result. Fill it in before provisioning the new cloud host. Then schedule a test deployment, perform the hosts-file checks, and do not change public DNS until the rollback owner and success criteria are written down.
