How to Move a Website to Cloud Hosting: A Low-Downtime Migration Checklist

Overview

A cloud hosting migration is best treated as a controlled infrastructure change rather than a simple file copy. The objective is to create a working version of the website on the new platform, verify it privately, and only then direct visitors to it.

The safest sequence is:

1. Inventory the current website and its dependencies.
2. Prepare the destination cloud hosting environment.
3. Lower DNS time-to-live (TTL) values when appropriate and record the existing DNS configuration.
4. Create independent backups and transfer the website files and database.
5. Test the migrated copy using a temporary URL, hosts-file override, or staging address.
6. Freeze or synchronize changing data, then perform the final transfer.
7. Update DNS, confirm SSL, and monitor the cutover.

Migration planning differs by website type. A mostly static website may need only files, configuration, DNS, and certificates. A WordPress site also requires its database, uploads, plugins, themes, scheduled tasks, and configuration values. An ecommerce site or application with logins and transactions needs extra care because data may change while the migration is in progress.

Before selecting the destination, confirm that the new plan supports the website's runtime, database engine, storage needs, scheduled jobs, email requirements, deployment method, and expected traffic. If you are comparing infrastructure options, see the cloud hosting versus VPS hosting comparison guide.

Checklist by scenario

For every website

• Document the current setup. Record the domain, subdomains, DNS records, web server behavior, runtime version, database details, cron jobs, redirects, SSL configuration, CDN settings, analytics, forms, and external integrations.
• Identify the authoritative DNS provider. The domain registrar and DNS host may be different. Confirm where A, AAAA, CNAME, MX, TXT, and other records are managed before making changes.
• Choose a migration window. Prefer a period with low operational activity, but do not assume traffic is the only concern. Consider support availability, scheduled jobs, sales activity, and internal change freezes.
• Create and inspect backups. Keep a copy of the website files, database, configuration, and any required certificates or keys. Verify that the database archive can be opened and that the backup location is accessible.
• Prepare rollback instructions. Write down the previous DNS values, old hosting access details, database restore steps, and the decision point for reverting.

For WordPress websites

• Copy the complete wp-content directory, including uploads, themes, and plugins, and retain the correct file permissions for the destination environment.
• Export the database and update the destination configuration with the new database name, user, password, and host values.
• Check the site's configured home and site URLs. Avoid broad search-and-replace operations until you understand how serialized WordPress data will be handled.
• Review caching, image optimization, security, backup, and redirect plugins. Some plugins store environment-specific paths or connection settings.
• Recreate scheduled tasks. A host-level cron job and a WordPress scheduled event are not always configured in the same way.
• Test administrator access, permalinks, media files, forms, transactional email, search, and any membership or ecommerce functionality.

For a safer pre-launch process, use the guidance in How to Use Staging Sites Safely Before Pushing Changes Live.

For custom applications

• Record the required language runtime, operating system packages, web server rules, environment variables, and build commands.
• Separate secrets from application code. Recreate them in the destination secret store or environment configuration rather than placing them in a public repository.
• Test database migrations against a copy before applying them to production data.
• Confirm file storage behavior, especially if uploads are written locally. A scalable deployment may require shared or object storage instead.
• Recreate workers, queues, webhooks, API credentials, cron jobs, and deployment hooks.
• Run functional tests for authentication, payments, email, uploads, background jobs, and third-party callbacks.

For DNS and the final cutover

1. Copy the current DNS zone or record set into a working document before editing anything.
2. Confirm the new server's IPv4 and, if used, IPv6 address. Check whether the provider expects an A record, AAAA record, CNAME, or nameserver delegation.
3. Lower the relevant DNS TTL ahead of the planned change if the existing value is high. This can make the transition easier to manage, but DNS caching means it does not guarantee immediate propagation everywhere.
4. Complete the final file and database sync. For sites with changing data, enable maintenance mode or temporarily pause writes during this step.
5. Update only the records required for the website. Leave mail, verification, and unrelated subdomains unchanged unless they are part of the migration.
6. Confirm the new server is receiving requests, then monitor both the new and old environments during the transition.

For record-level instructions, use How to Point a Domain to Hosting and the related guide to point a domain to cloud hosting.

What to double-check

Before DNS changes

• Open the site through a private test address or hosts-file override and test representative pages, not just the homepage.
• Verify that links, redirects, canonical URLs, robots directives, and XML sitemaps use the intended hostname and protocol.
• Confirm that the database character set, timezone, runtime version, and application configuration match the requirements of the site.
• Test error handling. A controlled 404 and application error page is preferable to exposing debug output or server details.
• Check that the new server has adequate disk space, memory, CPU headroom, and log rotation settings for normal operation.

SSL, email, and security

Install or enable an SSL certificate for the production hostname before public traffic arrives. Test the main domain, www variant, and every important subdomain that is moving. Confirm that HTTP redirects to HTTPS only when the application and proxy configuration are ready to avoid redirect loops.

Email is often overlooked because it may remain on a separate service. Preserve the required MX, SPF, DKIM, and DMARC records, and test both contact-form delivery and application notifications. Also review firewall rules, administrator access, SSH keys, API tokens, file permissions, and scheduled security updates.

After the cutover

Check status codes, response times, server logs, application logs, database connections, background tasks, and resource usage. Test from more than one network or monitoring location where possible. Watch for missing assets, redirect chains, cache problems, mixed content, failed webhooks, and forms that appear to work but do not deliver messages.

A monitoring plan makes the migration easier to verify. The website uptime and performance monitoring guide covers useful checks, while the server monitoring checklist can help structure resource review.

Common mistakes

• Changing nameservers without copying all records. This can interrupt email, verification services, subdomains, or third-party integrations.
• Testing only the homepage. Broken permalinks, media, checkout steps, login flows, and API endpoints may remain hidden.
• Relying on one backup. Keep an original backup and a separate copy, and confirm that restoration is possible before the cutover.
• Forgetting data that changes during copying. Comments, orders, form submissions, and user accounts can be lost if the final synchronization is skipped.
• Deleting the old hosting account immediately. Retain the previous environment until the new site is verified and the rollback period has passed.
• Assuming DNS is instant. Cached responses may cause visitors to reach different environments temporarily, so both environments should be safe during the transition.
• Ignoring application-specific secrets and jobs. Environment variables, cron tasks, queues, and webhook credentials are part of the application, even when they are not visible in the website files.

When to revisit

Use this checklist before every hosting migration, major platform change, or seasonal planning cycle. Revisit it sooner when the website adds ecommerce, user accounts, background processing, a CDN, new subdomains, or a different deployment workflow. It should also be updated when the hosting provider changes its control panel, runtime support, backup process, networking model, or SSL setup.

After the migration, schedule a short review rather than treating the cutover as the end of the work. Confirm that backups are running, monitoring alerts reach the right people, DNS records are documented, the old environment can be retired safely, and the new capacity matches observed usage. Keep a dated migration record with the final DNS values, configuration changes, test results, and rollback decision. That record will make the next website migration faster and less error-prone.

Practical final check: do not declare the move complete until you can load the site over HTTPS, submit its important forms, authenticate where required, verify scheduled jobs, inspect logs, confirm monitoring, and restore a backup or at least validate the documented restoration path.