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

Overview

A website migration moves your site’s files, database, configuration, domain routing, or all three from one hosting environment to another. The destination may be managed cloud hosting, a virtual server, a website builder, or a platform designed for static deployments. The details differ, but the risk areas are similar: missing data, incorrect configuration, broken URLs, interrupted email, expired certificates, and unclear recovery steps.

Before choosing a migration method, write down what currently exists. Record the domain names, subdomains, DNS records, email services, databases, scheduled jobs, third-party integrations, analytics tools, forms, payment connections, and any services that depend on the site. This inventory prevents a common error: moving the visible website while overlooking an important background service.

It is also useful to separate the migration into four phases:

1. Prepare: document the current setup, select the destination, and create recoverable backups.
2. Build: copy the site and configure it on the new cloud hosting environment.
3. Validate: test the site without changing public traffic.
4. Switch and monitor: update DNS, confirm SSL, watch for errors, and retain a rollback path.

If you are still comparing infrastructure options, review managed cloud hosting versus shared hosting before beginning. The right destination depends on how much control, maintenance, and operational responsibility your project requires.

Checklist by scenario

Before every migration

• Confirm ownership and access for the domain registrar, DNS provider, current host, and new host.
• Record the current DNS zone, including A, AAAA, CNAME, MX, TXT, and any verification records.
• List the site’s important URLs and note which pages receive traffic, leads, purchases, or downloads.
• Check the current PHP, runtime, database, web server, and application versions if the site uses a server-side stack.
• Export configuration files and document environment variables without exposing secrets in shared notes.
• Create a complete backup of website files and databases. Store at least one copy outside the current host and confirm that the backup can be opened or restored.
• Schedule the cutover during a period when you can test the site afterward. Avoid starting immediately before a launch, campaign, or other high-risk event.

A detailed backup process is covered in the website backup strategy guide. A backup is only useful for migration planning if you know what it contains and how to restore it.

For a static website, landing page, or portfolio

• Build the production files locally or in your chosen deployment workflow.
• Check that asset paths, image references, fonts, forms, and downloadable files work from the production domain.
• Review build settings, including the output directory, redirects file, environment variables, and any required headers.
• Test both the root domain and the www version if both are configured.
• Confirm that the hosting platform supports your required redirects and custom domain configuration.

For a platform-specific comparison of common static deployment approaches, see how to deploy a static website. A simple landing page may not require the same migration process as a database-backed application.

For a content management system or database-backed site

• Put the application into maintenance mode or pause content edits during the final database export, if the platform supports it.
• Export the database and copy uploads, themes, plugins, extensions, and configuration files.
• Recreate database users, permissions, scheduled tasks, queues, and required runtime settings on the new host.
• Update the application’s connection details and confirm that serialized settings, media paths, and site URLs are correct.
• Test logins, publishing, search, forms, comments, ecommerce functions, and administrative actions before switching traffic.
• Plan a final synchronization if the old site may receive new orders, submissions, or content after the initial copy.

For online stores, account for order data and payment-related integrations before the cutover. The guide to hosting for online stores provides additional considerations for ecommerce infrastructure.

For a domain or DNS change

• Identify where DNS is managed; it may be the registrar, the current host, a CDN, or a separate DNS provider.
• Lower the relevant DNS record time-to-live ahead of the switch if your provider allows it and if you understand the effect.
• Point the required records to the new destination, keeping unrelated records unchanged.
• Verify that email records remain intact. A website migration should not remove MX, SPF, DKIM, or other mail-related records.
• Allow for DNS caching and continue checking from more than one network or DNS lookup tool.

Use the domain pointing guide when the new provider gives you specific A, AAAA, CNAME, or nameserver instructions.

What to double-check

SSL and canonical access

Confirm that the new host has issued or imported an SSL certificate for every required hostname. Test the HTTPS version directly, then check that HTTP redirects to HTTPS if that is your intended setup. Also decide whether the canonical domain is the root domain or the www version, and make the other version redirect consistently.

Do not assume SSL is complete because the homepage loads. Check inner pages, asset requests, form submissions, redirects, and any subdomains that should remain active. For background on certificates and domain records, review the domain and DNS resources on Solitary Cloud.

URLs, redirects, and indexing

Compare a sample of old URLs with their new equivalents. Preserve paths where possible. When a path must change, create a relevant permanent redirect rather than sending visitors to the homepage. Check trailing slashes, uppercase characters, query parameters, pagination, feeds, sitemap files, robots directives, and canonical tags.

Review important pages manually in a browser and crawl the site if it is large enough to justify a crawler. A migration can appear successful while a small set of high-value URLs returns an error.

Function, performance, and monitoring

Test navigation, search, contact forms, authentication, file uploads, payments, webhooks, transactional email, analytics, and integrations. Then compare the new site with the old environment using the same pages and test conditions. Review response behavior, page loading, image delivery, caching, database queries, and large assets rather than relying on a single score.

The website speed test guide explains which performance measurements are useful and how to interpret them. Set up uptime monitoring for the homepage and, where appropriate, a representative application path. Check application logs and server logs after the DNS change for repeated errors, failed requests, or resource limits.

Common mistakes

• Changing DNS before testing: Build and validate the new environment first using a staging URL, temporary hostname, hosts-file test, or another private method supported by your setup.
• Keeping only one backup: Retain the original site until the new environment has passed the agreed observation period. Keep a separate copy of essential files and database exports.
• Forgetting email: Website DNS and email DNS may share the same zone. Copy records carefully and test mail delivery separately.
• Ignoring background jobs: Cron tasks, queues, webhooks, and scheduled publishing often need explicit recreation on cloud hosting.
• Testing only the homepage: A homepage check will not reveal broken forms, missing media, failed logins, or incorrect redirects.
• Changing too many variables: Avoid redesigning, changing URL structures, upgrading every dependency, and migrating hosts at the same time unless you have a strong reason. Fewer simultaneous changes make failures easier to isolate.
• Having no rollback decision: Define what constitutes a failed migration, who can change DNS back, and which data must be synchronized before rollback.

For teams that need a safer separation between testing and live traffic, the staging versus production guide explains the basic workflow.

When to revisit

Revisit this checklist before each major hosting change, domain transfer, platform redesign, or infrastructure upgrade. It is especially useful before seasonal planning cycles, product launches, marketing campaigns, or periods when the site is expected to handle more traffic or transactions.

Update the checklist whenever your workflow or tools change. Add new integrations, subdomains, deployment steps, monitoring checks, and recovery instructions as they appear. Remove obsolete records and document who has access to critical accounts. A short, current checklist is more valuable than a comprehensive document that no longer matches the site.

Before you act, make a copy of this sequence for the specific project. Fill in the current host, destination, DNS provider, backup location, test URLs, maintenance window, and rollback owner. Complete the preparation and validation steps before changing public DNS. After the switch, monitor the site, verify business-critical functions, and keep the old environment available until you are confident the migration is stable.