Cloud Hosting Migration Checklist: How to Move a Website Without Downtime

Overview

Moving a website to new cloud hosting changes more than its server. Depending on the setup, the migration may affect DNS records, databases, email routing, SSL certificates, scheduled jobs, file permissions, caching, integrations, and deployment workflows. A successful migration preserves the parts visitors and staff rely on while giving the team a clear way to reverse the change if a serious problem appears.

The safest approach is to separate the migration into four stages:

1. Prepare: inventory the current environment, reduce DNS TTL where appropriate, and create verified backups.
2. Build and test: configure the new host, copy the site, and test it through a private staging address.
3. Cut over: freeze or synchronize changing data, update DNS, validate SSL, and monitor the transition.
4. Confirm and retire: compare the old and new environments, resolve defects, and keep the old host available until the rollback window has passed.

DNS changes do not switch every visitor at exactly the same moment. Cached records, resolver behavior, and the configured TTL can produce a period in which different users reach different hosts. For background on this part of the process, see DNS propagation and troubleshooting delays and the guide to pointing a domain to a new host.

What to track

1. The current environment

Record the details of the existing web hosting account before making changes. Include the application and operating system versions, document root, database engine and name, storage locations, cron jobs, environment variables, redirect rules, caching layers, firewall settings, and external integrations. List every DNS record, not only the main website record. Mail, verification, API, subdomain, and service records can be missed during a rushed transfer.

Also identify who controls the domain registrar, DNS hosting provider, hosting account, SSL configuration, and deployment credentials. Store this information in an access-controlled location rather than in a personal notes file.

2. Backups and restore evidence

Create separate backups of website files, databases, configuration, and DNS records. A backup is useful only if it can be restored, so test at least one restoration before the cutover. Check that the database dump opens correctly, uploaded files are complete, and the backup timestamps are recent enough for the site’s change rate.

A practical backup plan should define the last acceptable data-loss point. For a mostly static site, a final file archive may be sufficient. For an ecommerce site, membership portal, or frequently updated application, plan a final database export or a short maintenance window so new orders and form submissions are not split between hosts. The website backup strategy guide provides a useful framework for deciding what to retain.

3. DNS and TTL readiness

At least one TTL period before the planned cutover, review the records that will change. Lowering the TTL can help resolvers refresh the record sooner, but it does not instantly clear caches and should not be treated as a guarantee of immediate propagation. Record the original TTL so it can be restored after the migration is stable.

Do not change nameservers unless that is part of the migration plan. Changing an A or CNAME record and changing the authoritative DNS provider are different operations with different failure modes. Confirm the target IP address, canonical hostname, www behavior, redirect rules, and any IPv6 record before the change window.

4. Staging and functional tests

Build the new site using a temporary hostname, protected preview URL, or local hosts-file entry. Test representative pages rather than only the homepage. Check navigation, search, contact forms, account login, file downloads, image delivery, payment or booking flows, webhooks, API connections, and administrative tasks.

For database-backed applications, confirm character encoding, database credentials, migrations, time zones, and permissions. For WordPress cloud hosting, check plugin behavior, scheduled tasks, media uploads, permalink handling, and caching. Disable indexing on the staging environment so the preview does not compete with the live site in search results.

5. SSL and operational services

Validate the certificate for every hostname that users may access, including the www version and important subdomains. Confirm that HTTP redirects to HTTPS, the certificate matches the domain, and mixed-content warnings do not appear. Also test email sending, DNS-based verification records, monitoring agents, backups, queues, and scheduled jobs. A site can load successfully while one of these supporting services is broken.

Cadence and checkpoints

Use a written checklist with an owner and timestamp for each checkpoint. The following cadence works for many business websites, but high-transaction or frequently deployed systems may need a more formal change process.

• One to two weeks before: inventory the environment, confirm account access, choose the migration window, check storage and resource requirements, and begin a complete backup review. Compare the planned resources with the cloud hosting sizing guide.
• At least one TTL period before: review DNS records, lower the relevant TTL if appropriate, and document the intended final values.
• Several days before: configure the destination, transfer a copy of the files and database, issue or install SSL, and complete staging tests.
• Immediately before cutover: take a final backup, pause deployments, record the current database position if applicable, and confirm that the rollback contact list is available.
• During cutover: synchronize final data, update only the planned DNS records, confirm the new host responds correctly, and watch logs, error rates, forms, transactions, and uptime.
• After DNS changes: test from more than one network or resolver, check both apex and www hostnames, inspect SSL, and compare key pages with the previous environment.
• After the observation window: restore normal TTL settings if required, remove temporary access controls, verify backups on the new host, and keep the old environment intact until the agreed rollback period ends.

Keep a migration log containing DNS changes, test results, incidents, and decisions. That record makes the next website hosting transfer faster and helps distinguish a migration defect from an unrelated application change.

How to interpret changes

Not every alert indicates downtime, and not every successful page load proves the migration is complete. Interpret signals by category.

• DNS inconsistency: Different answers from different resolvers can be normal during propagation. Confirm that the answers match the planned records and that the old host remains functional while traffic transitions.
• Application errors: A rise in server errors, blank pages, failed logins, or broken forms usually points to missing environment variables, permissions, database differences, incompatible software, or an incomplete file transfer.
• Performance changes: Compare response time, page rendering, cache behavior, and resource usage against a pre-migration baseline. Use the website speed testing guide rather than relying only on a subjective browser check.
• Security warnings: Certificate errors, mixed content, exposed staging pages, or missing security controls require immediate attention, even if the site otherwise loads.
• Data discrepancies: Missing orders, comments, leads, uploads, or account changes suggest that the final synchronization was incomplete. Stop destructive cleanup until the source and destination databases have been compared.

Define rollback criteria before the cutover. Examples include persistent transaction failures, loss of customer data, invalid SSL, a major increase in application errors, or a performance regression that cannot be explained quickly. If rollback is required, restore the planned DNS record, protect the new environment from receiving unsynchronized changes, and document which data must be reconciled afterward.

When to revisit

Revisit this checklist before every significant hosting move, DNS provider change, domain transfer, platform upgrade, or major architecture change. Do not wait for the next migration if the site has recently added ecommerce, user accounts, third-party integrations, a CDN, a new deployment pipeline, or a second region.

On a monthly or quarterly schedule, review the operational variables that made the migration safe:

• Are backups still completing and can a current backup be restored?
• Do DNS records, SSL certificates, redirects, and domain contacts remain accurate?
• Are uptime, response time, resource consumption, and error rates within the team’s expected range?
• Have new cron jobs, integrations, subdomains, or deployment steps been added to the inventory?
• Does the current cloud hosting plan still match traffic, storage, and application requirements?

Use the website uptime and performance checklist for recurring monitoring. If costs, resource usage, or traffic have changed, review the guidance on reducing hosting costs without hurting performance before changing capacity.

For the next migration, start by copying this article’s checklist into a change record, assign one owner to the DNS cutover, one owner to application validation, and one person with authority to approve rollback. A clear owner, a tested restore path, and evidence from post-cutover monitoring are the practical foundations of a website migration without avoidable downtime.