How to Migrate a Website to Cloud Hosting: A Step-by-Step Checklist

Overview

A website migration changes the environment that serves your pages, applications, databases, or email. The visible site may remain the same, but its files, server configuration, IP address, database connection, caching layer, and security settings can all change underneath it.

The safest approach is to keep the current hosting account available until the new cloud website hosting environment has been tested and the new traffic path is stable. Avoid treating the old host as disposable immediately after copying the site. It is your fallback while DNS records update and while you confirm that visitors, administrators, forms, payment flows, and integrations work as expected.

Before beginning, document the current setup. Record the domain name, DNS provider, hosting account, application version, database type, PHP or runtime version where relevant, scheduled jobs, email records, SSL configuration, redirects, third-party integrations, and any IP allowlists. This inventory gives you a reference point if the new environment behaves differently.

Migration methods vary by platform. A static website may require only a file transfer and DNS update. A WordPress site usually requires files, a database, configuration values, media, rewrite rules, and sometimes a search-and-replace operation for the domain. A custom application may also need environment variables, deployment commands, workers, queues, object storage, or database migrations. For WordPress-specific steps, see How to Migrate a WordPress Site to Cloud Hosting.

What to track

1. Build a migration inventory

Create a simple document containing the current and target values for each important component. Include:

• Primary domain, www variant, subdomains, and any parked or redirected domains.
• DNS records, including A, AAAA, CNAME, MX, TXT, and verification records.
• Website files, uploads, themes, plugins, dependencies, and private configuration files.
• Database names, users, character sets, connection details, and estimated size.
• Business email records and any services that depend on the domain.
• Scheduled tasks, background workers, webhooks, API integrations, and monitoring checks.
• Existing redirects, canonical settings, robots.txt rules, XML sitemaps, and analytics tags.

Do not copy secrets into an unsecured checklist. Record where credentials are stored, then use the appropriate secure access method during the migration.

2. Create and verify backups

Make at least one complete backup before changing production settings. For a database-backed site, back up the database separately from the site files. If the host provides snapshots, treat them as one recovery option rather than the only copy. Confirm that the backup can be downloaded, identify its creation time, and test restoring a small sample or a complete copy in a non-production environment when practical.

A backup is useful only if you know how to restore it. Write down the commands, control-panel steps, credentials, and dependencies required for recovery. Define a rollback point before the migration begins: for example, the last verified backup and the old hosting configuration that can continue serving the site.

3. Prepare the target cloud environment

Provision the application runtime, database, storage, firewall rules, user accounts, and deployment method before moving live traffic. Match the current runtime versions initially unless there is a clear reason to change them at the same time. Separating a hosting move from a major software upgrade makes troubleshooting more focused.

Configure the target with a temporary hostname, provider preview URL, or hosts-file override. This allows you to test the site without waiting for public DNS changes. Confirm file permissions, database connectivity, environment variables, upload limits, rewrite rules, caching behavior, and error logging.

4. Transfer files and database content

Put the site into maintenance mode or choose a short content freeze if the application receives ongoing changes. This prevents new orders, comments, form submissions, or editorial updates from being written to the old database after the backup is taken.

Transfer the site files using the method supported by your hosting environment, then import the database into the target. Update configuration values for the new database host, name, user, password, storage path, and runtime settings. If the domain or directory structure changes, review absolute URLs and serialized data carefully rather than performing an indiscriminate text replacement.

5. Test before changing DNS

Use the temporary access method to test representative pages, not just the homepage. Check navigation, search, login, contact forms, file uploads, images, APIs, checkout or subscription flows where applicable, and administrative functions. Review server and application logs for warnings that may not appear in the browser.

Test on both desktop and mobile layouts. Confirm that HTTP requests redirect correctly to HTTPS, that the preferred hostname is consistent, and that important pages return the expected status codes. Compare page titles, metadata, canonical URLs, structured data, robots.txt, and the XML sitemap with the current site. A migration should not accidentally block crawling or remove valuable redirects.

For background on securing the destination, use the SSL Certificate Setup Guide. SSL should be configured and tested on the target before production traffic is directed there.

6. Plan DNS and email changes

Identify which DNS records should point to the new cloud host. The website may use an A record, AAAA record, CNAME, or a provider-specific configuration. Change only the records required for the web migration. MX, SPF, DKIM, DMARC, verification, and mail-related records should remain correct unless email is moving as part of the same project.

Lowering DNS TTL before the migration may help some resolvers check for changes sooner, but it does not guarantee immediate propagation. Keep the old site available while different networks may still resolve the old address. If you also need to move business email, treat that as a separate workstream with its own backup and verification checklist. The article Subdomain vs Subdirectory can also help when the migration involves changing site structure.

7. Enable SSL and switch traffic

Install or provision the certificate for every hostname that needs HTTPS, including the www variant or relevant subdomains. Test certificate coverage, renewal configuration, mixed-content warnings, and redirects from HTTP to HTTPS.

When the target is ready, update the required DNS records. Record the exact time of the change, the previous values, and the person responsible. Do not delete the old environment yet. During the transition, monitor both hosts so that you can distinguish an application problem from a DNS resolution delay.

8. Validate the live migration

After the domain begins resolving to the cloud host, repeat the critical tests using the public domain. Confirm that the correct certificate is served, forms deliver successfully, users can log in, transactions complete, scheduled tasks run, and integrations still accept requests from the new server. Check the browser console, application logs, database errors, CPU and memory usage, storage capacity, and response times.

Use a short, written sign-off list. A migration is not complete merely because the homepage loads; it is complete when the site's important user and operational paths have been verified.

Cadence and checkpoints

Use checkpoints to turn a one-time move into a controlled operational process.

• Before migration: capture the inventory, verify backups, document DNS, and record baseline behavior for key pages and transactions.
• During preparation: test the target with a temporary URL, confirm SSL, and resolve application or permission errors before touching production DNS.
• Immediately after DNS changes: check the public site, DNS responses, HTTPS, forms, authentication, integrations, and logs.
• Within the first day: review traffic, error rates, resource usage, failed jobs, email delivery signals, and important conversion or transaction paths.
• During the first week: check crawlability, redirects, indexing signals, backups, monitoring alerts, and cache behavior. Compare these with the pre-migration baseline rather than relying on memory.
• Monthly: verify backups, certificate renewal, DNS records, uptime checks, disk usage, software updates, and unused accounts or access keys.
• Quarterly or after major changes: test restoration, review capacity, confirm disaster recovery steps, and reassess whether the hosting configuration still matches traffic and application needs.

Keep a migration log with timestamps, DNS values, deployment identifiers, test results, incidents, and rollback decisions. This makes future changes safer and gives the next operator enough context to repeat the process.

How to interpret changes

Not every difference after a migration indicates a failed move. DNS resolution can vary by resolver, and caches may temporarily serve older responses. Separate transition effects from persistent application issues by checking the public domain from more than one network and by comparing results over time.

A sudden increase in server errors usually warrants an application, database, permission, or runtime review. A site that loads but feels slower may need investigation of database queries, caching, image delivery, TLS configuration, geographic distance, or resource limits. A drop in organic visibility should prompt checks of redirects, canonical URLs, robots.txt, sitemap availability, status codes, and accidental noindex settings before assuming that the cloud host itself caused the change. For broader performance planning, see How to Choose Web Hosting for Better Core Web Vitals.

When email stops arriving, inspect MX and authentication records before changing website DNS again. When only one subdomain fails, compare its record and SSL coverage with the primary domain. When uploads or scheduled jobs fail, check filesystem permissions, paths, cron configuration, and service accounts.

Use thresholds that reflect the website's purpose. For a brochure site, availability and form delivery may be the most important signals. For an ecommerce or application site, checkout completion, background jobs, database health, and error rates deserve priority. The goal is not to collect every metric; it is to detect problems that affect users or recovery.

When to revisit

Revisit this checklist before every hosting change, not only during a full provider migration. It is useful when moving from shared hosting to managed cloud hosting, changing regions, adding a CDN, introducing a new deployment pipeline, changing domain structure, or upgrading the application runtime.

Schedule a monthly or quarterly review of the recurring items: backup restoration, DNS accuracy, SSL renewal, monitoring coverage, storage growth, resource consumption, access permissions, and rollback documentation. Revisit sooner after an outage, security incident, major traffic increase, redesign, database change, or email provider change.

For the next migration, start by duplicating the inventory and checklist rather than relying on the previous project notes. Confirm what has changed, preserve the current rollback option, test the target privately, and only then schedule the DNS cutover. That small habit turns website migration from a high-risk event into a repeatable cloud hosting procedure.