A hosting migration is complete only when the new environment is stable, the domain resolves correctly, visitors can use every important feature, and the old host can be retired safely. This reusable cloud hosting migration checklist helps you track the work before, during, and after moving a WordPress or business website.
Overview
Moving a website to cloud web hosting involves more than copying files. A reliable migration preserves the site’s database, media, configuration, URLs, search visibility, email delivery, and security settings while changing the infrastructure underneath. The exact process varies by platform, but the control points are broadly the same.
Use this checklist as a working record rather than a one-time list. Before migration, document the current environment and create recovery points. During the move, validate the new site without exposing it prematurely. After the DNS cutover, monitor both technical behavior and real user journeys. Keep the record available for later migrations, recurring reviews, and troubleshooting.
If you are comparing providers before starting, the cloud web hosting comparison checklist can help you assess capacity, support, control panels, security, and operational fit.
What to track
1. Inventory the current website
Record the details that could affect the move or a rollback:
- Domain names, subdomains, aliases, and the current DNS provider.
- WordPress core version, themes, plugins, PHP version, and scheduled tasks.
- Database type and name, database users, table prefixes, and connection settings.
- Uploads, media files, custom files, server-side scripts, and application configuration.
- Transactional email, mailbox hosting, contact forms, payment integrations, APIs, and analytics.
- Redirect rules, canonical settings, robots directives, XML sitemaps, and security controls.
Also note which services are hosted separately. Domain registration, DNS hosting, website hosting, and email hosting do not have to be with the same provider. Keeping this distinction clear prevents an unnecessary domain transfer or an accidental email outage.
2. Create and test backups
Make at least one complete backup of the database and website files before changing production. Keep a copy outside the current hosting account, and record when it was created and how it can be restored. A backup that has never been tested is only an assumption, so restore it in a temporary environment when practical.
For WordPress, verify that the backup includes the database, the wp-content directory, configuration details, and any files used by the active theme or plugins. If the site accepts orders, registrations, comments, or form submissions, define how new data created during the migration window will be captured or reconciled.
3. Build and inspect the destination
Set up the new cloud hosting environment before changing DNS. Match the required runtime versions, database settings, storage paths, file permissions, cron jobs, and environment variables. Use a temporary hostname, hosts-file entry, or staging address to inspect the site without directing public traffic to it.
Do not treat staging as a simple visual preview. Confirm that logins work, forms send correctly, media loads, search works, scheduled tasks run, and integrations can reach their required endpoints. The guide to staging and production environments provides a useful framework for separating testing from live traffic.
4. Track the data transfer
Transfer files and import the database using a method appropriate to the site’s size and access requirements. Check file counts, archive sizes, database tables, character encoding, and ownership or permissions after the transfer. Compare important pages and media assets against the original rather than assuming a successful upload means a complete migration.
For a site that changes frequently, reduce the gap between the final backup and the DNS cutover. A maintenance window, temporary form pause, or final database synchronization may be appropriate. Document the chosen method so everyone understands which version is authoritative.
5. Validate DNS, SSL, and email
Before cutover, lower the relevant DNS time-to-live value if your DNS provider permits and if you have enough lead time. Prepare the required A, AAAA, CNAME, MX, TXT, and verification records. Change only the records needed for the website unless you intentionally plan a broader DNS migration.
Confirm that the certificate covers the live hostname and common variants such as the www and non-www versions where applicable. Test HTTP-to-HTTPS behavior, mixed-content warnings, secure cookies, and administrative URLs. Preserve email continuity by checking MX, SPF, DKIM, and DMARC records before and after the change. For detailed record planning, see the managed DNS setup guide.
6. Record the post-cutover checks
After pointing the domain to the new host, test from more than one network or resolver if possible. Check the homepage, representative content pages, redirects, login, search, forms, checkout or booking flows, file downloads, images, and integrations. Review server, PHP, application, and security logs for errors that may not appear in the browser.
Check that analytics and search-related tools still receive data. Confirm that the robots file and sitemap are available, canonical URLs are correct, and no staging protection or noindex directive has carried into production. If the site uses a CDN or cache, purge it deliberately and verify that cached content reflects the new origin.
Cadence and checkpoints
Use a simple migration log with four statuses: not started, in progress, verified, and blocked. Assign an owner and timestamp to each critical check. A practical schedule is:
- One to two weeks before: inventory services, confirm access, test backups, prepare the destination, and document DNS and email records.
- One to three days before: copy the site, test staging, confirm SSL issuance or installation, review redirects, and lower DNS TTL if appropriate.
- During cutover: complete the final backup or synchronization, make the DNS change, record the exact time, and keep the old host available.
- First hour: verify DNS responses, HTTPS, the homepage, key transactions, forms, authentication, and error logs.
- First day: check traffic patterns, email delivery, scheduled jobs, monitoring alerts, and customer-facing workflows.
- First week: review crawl errors, redirect reports, performance, resource use, backup completion, and application logs.
Keep the old hosting account active until the new site has passed the agreed observation period and the rollback decision is no longer needed. The correct period depends on traffic and business risk; a low-change brochure site and a busy transaction site should not use the same assumption.
How to interpret changes
A migration issue is easier to diagnose when you separate DNS, application, infrastructure, and content symptoms. If some networks reach the old site while others reach the new one, propagation or resolver caching may be involved. If all visitors reach the new host but pages fail, inspect the application configuration, database connection, runtime version, permissions, and logs.
A sudden increase in redirects, missing pages, or crawl errors often points to incomplete rewrite rules, changed URL paths, or an incorrect canonical configuration. Slow pages may result from cache settings, database queries, image handling, DNS configuration, or insufficient resources; do not assume that changing hosts alone explains the result. The guide on speeding up a slow website offers a broader diagnostic sequence.
Define rollback triggers before the cutover. Examples include failed checkout or booking flows, widespread server errors, missing customer data, broken email, or an inability to restore the new environment. Rollback should mean restoring the previous DNS destination and preserving any data created during the test period, not simply deleting the new account.
When to revisit
Review this checklist monthly during the first few months after migration, then at least quarterly for a business-critical site. At each review, confirm that backups complete and can be restored, SSL remains valid, DNS records are documented, scheduled tasks run, resource usage is understood, and monitoring still covers the important user journeys.
Revisit the migration record immediately when the hosting plan, DNS provider, domain registration, email system, WordPress version, payment integration, CDN, or deployment process changes. A major redesign, plugin replacement, traffic increase, security incident, or new regional audience is also a reason to repeat the relevant tests.
Keep a current copy of the inventory, DNS records, access ownership, backup location, rollback steps, and last successful verification. When it is time to transfer a domain to a new host, this documentation turns a risky, improvised move into a controlled change. Before closing the old hosting account, run one final backup, confirm email and DNS independence, and retain the migration log with the date and outcome.
