Moving a website to cloud hosting does not require a long outage. With a controlled sequence of backups, staging checks, DNS preparation, SSL validation, and post-launch monitoring, you can reduce migration risk and keep visitors, search engines, and internal teams working through the change. This zero-downtime website migration checklist gives you a repeatable process for moving a site to new hosting and a maintenance routine to use whenever infrastructure changes.
Overview
A website hosting migration changes more than the server that delivers pages. Depending on the application, it may also affect databases, file storage, environment variables, scheduled jobs, email records, DNS, SSL certificates, redirects, caching, analytics, and deployment workflows. Treat the move as an operational change rather than a simple file transfer.
The safest approach is to separate the migration into four stages: preparation, staging, traffic cutover, and verification. The existing site remains available while you copy and test the new environment. During cutover, DNS is updated to point visitors to the new host, but the old environment stays ready for rollback until the new setup has been verified.
This workflow applies to content management systems, static sites, ecommerce websites, and web applications, although the exact commands and platform settings will vary. If you are comparing infrastructure options before starting, review managed cloud hosting versus shared hosting and how to choose hosting for WordPress, static sites, and web apps.
What to track
1. Create a migration inventory
Record everything the current website depends on before copying it. At minimum, document:
- Domains and subdomains, including www, staging, API, and asset hostnames.
- DNS records for the website, email, verification services, and third-party integrations.
- Application files, uploads, media, themes, plugins, and build artifacts.
- Databases, database users, connection settings, and character-set requirements.
- Environment variables, API keys, webhook endpoints, and payment or form integrations.
- Cron jobs, queues, background workers, server-side scripts, and scheduled backups.
- Redirect rules, canonical settings, robots directives, XML sitemaps, and analytics tags.
- Email services and the records that support them, such as MX and related authentication records.
This inventory becomes a baseline for testing. It also prevents a common migration failure: the pages load, but a less visible service such as contact forms, scheduled publishing, transactional email, or image processing has stopped working.
2. Back up before making changes
Take a complete backup of the website files and database, then confirm that the backup can be retrieved. A backup that exists only as an untested archive is not a reliable rollback plan. Keep a separate copy outside the current server when practical, and record the backup time and the steps needed to restore it.
For frequently changing sites, plan how to capture updates made between the initial copy and the final cutover. A static site may only need a fresh build. A database-driven site may require a final database export, temporary maintenance mode, replication, or a short write freeze to prevent new orders, comments, or submissions from being missed.
3. Build and test a staging environment
Configure the new cloud hosting environment without changing public DNS. Use a temporary hostname, protected preview URL, or local hosts-file entry so the team can inspect the new site. Do not assume that a successful file transfer means the application is ready.
Test representative pages and actions: the homepage, navigation, search, forms, login, checkout if applicable, media files, downloads, account areas, and error pages. Check database queries, file permissions, caching, image handling, scheduled tasks, and external integrations. Confirm that production secrets are stored securely and that staging does not accidentally send real emails or index private content.
For a performance baseline, compare response times, page weight, caching behavior, and key user journeys before and after the move. The Core Web Vitals optimization guide can help structure a broader speed review.
4. Prepare DNS and SSL
Lowering DNS time to live ahead of the migration may help resolvers refresh records sooner, but it cannot guarantee that every visitor switches at the same time. Plan for a period during which some users still reach the old server and others reach the new one.
Install or configure the SSL certificate on the new environment before cutover. Test both the preferred hostname and any redirecting hostnames over HTTPS. Check for mixed content, incorrect certificate coverage, redirect loops, and application settings that generate HTTP URLs.
5. Define the rollback point
Write down the conditions that would trigger a rollback, who can authorize it, and how it will be performed. A rollback might mean restoring the previous DNS record, re-enabling the old deployment, or routing traffic through an earlier release. Keep the old hosting environment unchanged until the new site has passed the agreed observation period.
Cadence and checkpoints
Use this timeline as a practical cloud hosting migration checklist. Adjust the schedule to the size and traffic pattern of the site.
One to two weeks before migration
- Confirm the inventory, ownership, access credentials, and maintenance window.
- Export and test backups.
- Provision the new environment and configure runtime versions, storage, database, firewall rules, and deployment access.
- Copy the site and run staging tests.
- Document DNS records, redirects, cron jobs, email settings, and rollback steps.
One to three days before migration
- Complete an end-to-end rehearsal using a recent copy of the production data.
- Verify SSL, caching, forms, authentication, integrations, monitoring, and backups on the new host.
- Prepare the DNS change and confirm access to the domain registrar or DNS provider.
- Notify relevant teams about the cutover window and validation responsibilities.
During cutover
- Capture a final backup and, where necessary, pause writes briefly.
- Perform the final file and database synchronization.
- Confirm the new application is healthy using its temporary address.
- Update the required DNS records.
- Check the site from more than one network or monitoring location.
- Watch logs, error rates, forms, orders, authentication, and resource usage.
After cutover
Keep monitoring active while DNS changes propagate. Do not immediately cancel the old hosting account or delete the previous deployment. Confirm that both the bare domain and www version behave as intended, redirects preserve paths, and no important subdomain was overlooked. For ongoing checks, see the website uptime monitoring guide.
How to interpret changes
Compare the new environment with the baseline rather than judging the migration only by whether the homepage loads. A successful migration should preserve content and behavior while maintaining acceptable performance, security, and operational visibility.
Investigate a sudden increase in server errors, slow database requests, failed background jobs, or missing assets before declaring the move complete. A page that is visually correct may still have broken forms, blocked scripts, incorrect canonical URLs, or a database connection that fails only under real traffic.
Pay particular attention to traffic and search signals. A temporary fluctuation can occur while DNS and caches update, but persistent drops in important landing pages, indexed URLs, or conversions deserve investigation. Check redirect responses, sitemap availability, robots directives, canonical tags, and analytics collection. Avoid changing several unrelated SEO settings at the same time; isolating variables makes a migration problem easier to diagnose.
Also compare cloud resource usage against the expected workload. Sustained memory pressure, CPU saturation, storage growth, or unexpected bandwidth use may indicate an incorrect configuration, an unoptimized application, or a new workload that needs capacity planning. Review the cloud cost checklist for small websites after the first complete billing or reporting cycle.
When to revisit
Revisit this migration checklist after the first day, again after the first week, and then monthly or quarterly depending on how often the site changes. The first review should focus on errors, forms, transactions, email delivery, DNS, backups, and resource usage. The later review should confirm that monitoring still works, certificates renew correctly, scheduled jobs run, and the rollback documentation remains accurate.
Use the checklist again before major platform upgrades, domain changes, database moves, redesigns, traffic campaigns, or a switch between hosting providers. Update the inventory whenever a new integration, subdomain, scheduled process, or data store is added. An outdated inventory is one of the main reasons a migration plan misses an important dependency.
To close each review, record four items: what changed, what was tested, what remains uncertain, and who owns the next action. That short record turns a one-time website hosting migration into a repeatable operating process. When the next move is required, you will have a current baseline, a tested backup, known checkpoints, and a practical rollback path instead of starting from memory.
