Moving a website to cloud hosting does not have to mean accepting prolonged downtime or uncertain results. This cloud hosting migration checklist gives you a repeatable workflow for inventory, testing, DNS preparation, database cutover, rollback, validation, and post-migration monitoring. Use it before each migration, then revisit the tracking items monthly or quarterly as traffic, application dependencies, and infrastructure change.
Overview
A successful website migration to cloud hosting is a controlled change, not simply a file transfer. The destination environment must reproduce the application’s required runtime, data, security controls, scheduled tasks, and network behavior before users are sent there.
The safest general approach is to build and test the new environment while the existing website remains live. You then reduce DNS caching uncertainty, synchronize the latest data, switch traffic during a defined maintenance window or low-risk period, and keep the old environment available until validation is complete.
Before choosing a cutover time, define four measures:
- Recovery point objective (RPO): how much recent data the business can tolerate losing if the migration must be rolled back.
- Recovery time objective (RTO): how quickly the website must be restored if the new environment fails.
- Validation criteria: the technical and business checks that must pass before the migration is considered complete.
- Rollback trigger: a specific condition, such as failed transactions, corrupted data, or sustained error rates, that requires returning traffic to the original host.
For a broader recovery framework, use the Cloud Backup RPO and RTO Planning Guide alongside this migration plan.
What to track
1. Inventory the current website
Record the components that must be recreated or replaced. Include the web server, operating system, runtime versions, application code, environment variables, databases, uploaded files, object storage, DNS records, email-related records, scheduled jobs, queues, third-party integrations, monitoring, and access credentials.
Document both production and administrative paths. A public site may load correctly while an admin panel, payment callback, webhook, image processor, or scheduled task is broken. Note the source of truth for each item, its owner, and the test that will confirm it works after cutover.
2. Capture a restorable backup
Create backups of the database, user uploads, configuration files, and any other persistent data. Do not treat a backup as ready until you have confirmed that it can be restored in an isolated environment. Record the backup timestamp, storage location, encryption status where applicable, retention period, and person responsible for the restore test.
If the migration includes large media libraries or static assets, separate the transfer from the final database cutover. Object storage can be useful for durable website assets, but permissions, public access settings, lifecycle rules, and application paths must be tested. The Object Storage Backup Strategy provides a related checklist for retention and restore testing.
3. Build and test the destination
Match the application’s required versions and settings before copying production traffic. Apply operating system updates, restrict administrative access, configure firewalls, install monitoring, and create separate deployment credentials where possible. Configure TLS certificates for every required hostname, including the canonical domain, alternate hostname, and any API or administrative subdomain.
Test the site using a temporary hostname, hosts-file override, private network route, or another method that does not change public DNS. Check representative pages, forms, logins, search, file uploads, database writes, background jobs, webhooks, redirects, error pages, and administrator workflows.
4. Prepare DNS and traffic controls
List every DNS record that may be affected: A and AAAA records, CNAME records, aliases, mail records, verification records, and subdomains. Lower the time to live (TTL) ahead of the planned cutover if your DNS provider permits it and if doing so fits your operating plan. A lower TTL may help resolvers obtain the new destination sooner, but it cannot force every cached response to expire immediately.
Record the original values before making changes. Confirm who controls the authoritative DNS zone, how changes are approved, and how to reverse them. If a CDN or reverse proxy sits in front of the website, include its origin settings, cache behavior, health checks, certificates, and purge process in the plan. See the CDN and Website Caching Guide for a related performance checklist.
5. Plan the database cutover
Choose a synchronization method that matches the application and database engine. A simple site may use a final export and import; a busy application may require replication or a brief write freeze. Define when writes stop, how the final changes are copied, how consistency is checked, and when writes can safely resume.
Use a written rollback template:
- State the incident and the person authorized to roll back.
- Pause new changes and preserve relevant logs.
- Point DNS, load balancing, or the proxy back to the original environment.
- Confirm the original database is authoritative and protect any new records created during the failed attempt.
- Validate the original site and notify stakeholders.
- Record the cause, data impact, and next conditions for retrying.
Cadence and checkpoints
Use the following schedule as a practical baseline. Adapt it to the website’s traffic, data sensitivity, and release process.
| Timing | Checkpoint | Evidence to record |
|---|---|---|
| Two to four weeks before | Inventory dependencies and define RPO, RTO, validation criteria, and rollback authority. | Signed checklist, dependency map, and migration owner. |
| One to two weeks before | Build the destination, restore a backup, test TLS, and exercise application workflows. | Restore log, test results, security review, and open-issue list. |
| Several days before | Review DNS records, lower TTL if appropriate, confirm access, and notify stakeholders. | DNS export, communication plan, and confirmed maintenance window. |
| Cutover day | Synchronize data, pause or manage writes, switch traffic, and run smoke tests. | Timestamped commands, database status, DNS change, and test outcomes. |
| First 24 to 72 hours | Monitor availability, errors, latency, resource use, transactions, logs, and search visibility. | Dashboard snapshots, incident notes, and go/no-go decision on decommissioning. |
| Monthly or quarterly | Review costs, capacity, backups, certificates, dependencies, and rollback readiness. | Updated inventory and a dated review record. |
Keep the original hosting environment intact until the new system has passed the agreed observation period and a fresh backup has been verified. The exact period depends on the site’s traffic and business risk; the important point is to avoid deleting your easiest rollback path immediately after DNS changes.
How to interpret changes
Do not judge a migration only by whether the homepage loads. Compare the new environment with a recent baseline from the old one. Review response times, HTTP status codes, application errors, CPU and memory use, database connections, disk space, cache behavior, and completed business transactions.
| Observation | Possible interpretation | Next action |
|---|---|---|
| Pages load, but forms fail | Environment variables, mail delivery, CSRF settings, or API credentials may be incomplete. | Test each integration and compare configuration values without exposing secrets. |
| Traffic reaches the old host | DNS caches, an overlooked record, CDN routing, or local resolver behavior may be involved. | Check authoritative records and multiple independent resolvers before changing more settings. |
| Errors rise after cutover | The destination may have incompatible runtime settings, missing permissions, or insufficient capacity. | Correlate timestamps with deployment and database logs; use the rollback trigger if user impact is material. |
| Search traffic changes | Redirects, canonical tags, robots directives, response codes, or rendering may differ. | Crawl key URLs, compare metadata and headers, and correct technical differences promptly. |
| Costs or resource use increase | The selected instance size, storage class, backups, logs, or data transfer may not match actual needs. | Review usage by component and right-size only after confirming performance and resilience. |
Separate migration defects from normal DNS propagation and cache effects. Keep a timeline of every change so that apparent patterns can be tested rather than guessed. For service-level expectations, compare your operational results with the commitments and exclusions documented in your provider agreement; the Cloud Hosting SLA Checklist can help organize that review.
When to revisit
Revisit this cloud hosting migration checklist before every planned move, major architecture change, or hosting-provider change. It should also be updated after a database engine upgrade, domain or DNS-provider change, CDN redesign, new payment or identity integration, significant traffic increase, or change in data-retention requirements.
On a monthly or quarterly cadence, verify that:
- Backups complete and at least one recent restore has been tested.
- DNS ownership, TLS certificates, service accounts, and emergency contacts are current.
- Monitoring still covers availability, errors, latency, resource capacity, and business transactions.
- RPO, RTO, rollback steps, and migration ownership still match business requirements.
- Cloud hosting costs, storage growth, backup retention, and data transfer remain understood.
- Application dependencies and scheduled jobs are documented after each release.
To make the next migration easier, save the final checklist, DNS export, validation results, backup evidence, and rollback notes in a location accessible during an outage. Review unresolved items at the next infrastructure planning meeting. A migration plan is most valuable when it reflects the current website—not the version that existed during the last move.
Before scheduling your next cutover, assign one owner to each task, run a complete restore and rollback rehearsal where practical, confirm the maintenance window, and obtain a clear go/no-go decision. That preparation is what allows a website migration to cloud hosting to be treated as a controlled operational change rather than an emergency.
