A hosting migration can be straightforward when it is treated as a controlled project rather than a single DNS change. This cloud hosting migration checklist helps creators and small businesses plan backups, copy files and databases, verify SSL and email, test the new environment, switch traffic safely, and monitor the result on a recurring schedule.
Overview
Moving a website to new hosting changes the environment in which your files, database, email, domain records, and security settings operate. The safest approach is to separate the migration into four phases: preparation, staging, cutover, and monitoring.
Preparation creates a reliable copy of the existing site and records the settings you may need to reproduce. Staging puts that copy on the new host so you can test it without changing the live website. Cutover moves visitors to the new server through DNS changes. Monitoring confirms that pages, forms, transactions, email, redirects, and performance continue to work after the switch.
Before starting, record the current hosting account, domain registrar, DNS provider, content management system, database type, PHP or application runtime version, SSL setup, email provider, scheduled tasks, and third-party integrations. This inventory reduces the chance of overlooking a service that is not visible in the website files.
If you want a broader process for moving to cloud hosting, see the website hosting migration checklist. For decisions about the destination environment, compare managed hosting and unmanaged hosting before committing.
What to track
Backups and recovery files
Create at least one complete backup before making changes. For a database-driven site, this usually means a copy of the website files and a database export. Keep the backup separate from both the old and new hosting accounts, and note when it was created. Check that the archive can be opened and that the database export contains recent content.
Do not cancel the old hosting account immediately. Keep it available during the agreed rollback period so you can restore service or retrieve a missed file if testing reveals a problem.
Files, database, and application settings
Confirm that all media, uploads, themes, plugins, configuration files, and custom code have transferred. Check database credentials, table prefixes, environment variables, file permissions, and runtime versions. A site may load while still having broken admin functions, missing images, or incompatible extensions.
For WordPress hosting, review the site URL, permalink structure, active plugins, scheduled tasks, caching, and administrator access. If you are moving to a VPS or another scalable environment, also check server-level services such as web server rules, database services, firewall settings, and automated backups. The cloud hosting guide for developers can help structure that infrastructure review.
DNS, SSL, and domains
List every DNS record before the migration, including the main website record, the www host, mail records, verification records, subdomains, and any records used by external services. Copying only the main website record can interrupt email or connected tools.
Install and test the SSL certificate on the new host before directing public traffic there. Test both the secure and non-secure versions, confirm that HTTP redirects to HTTPS as intended, and check for mixed-content warnings. Verify that the domain is attached to the correct site and that both preferred hostname versions behave consistently.
Email and business functions
Website hosting and email may be managed by different providers. Identify where mailboxes, forwarding, spam filtering, and mail records are hosted before changing DNS. Send test messages in both directions and confirm that existing accounts remain accessible.
Test every business-critical interaction: contact forms, booking requests, payments, account registration, search, downloads, newsletter signups, analytics, and integrations. A homepage that loads is not enough evidence that a migration succeeded.
Redirects, analytics, and search visibility
Preserve existing URLs whenever possible. If URLs must change, create one-to-one 301 redirects from old addresses to their most relevant new destinations. Avoid sending every old page to the homepage. Test important redirects manually and review for chains or loops.
Confirm that analytics, cookie tools, search verification, XML sitemaps, robots directives, and canonical URLs remain intact. Keep any temporary no-index or password protection used on the staging site away from production.
Cadence and checkpoints
Use a simple migration log with the task, owner, date, result, and follow-up action. The following checkpoints provide a practical schedule.
- One to two weeks before cutover: inventory services, select a migration window, confirm access to the registrar and DNS provider, export DNS records, and create a recovery plan.
- Several days before cutover: copy the site to the new host, import the database, configure the application, install SSL, and test the site through a temporary address or hosts-file override.
- One day before cutover: take a fresh backup, check forms and payments, confirm email settings, lower DNS caching time if appropriate for your provider, and notify anyone responsible for site changes.
- During cutover: place the site in maintenance mode if needed, pause content edits, perform a final database export for active sites, update DNS, and record the exact change time.
- Immediately after cutover: test the homepage, representative internal pages, secure connections, forms, logins, checkout or booking paths, redirects, email, analytics, and mobile layouts.
- After 24 to 72 hours: review error logs, uptime checks, traffic, crawl errors, database activity, resource usage, and support messages. Keep the old environment available until this review is complete.
- After one to two weeks: confirm that DNS has settled for your users, remove temporary migration settings, document the final configuration, and establish the new backup and monitoring routine.
For high-traffic stores or sites with frequent orders, use a maintenance window and a final data synchronization step. The exact timing depends on how quickly the application changes data and how much disruption the business can tolerate.
How to interpret changes
Not every post-migration warning indicates a hosting failure. Compare changes with the migration timeline and isolate one variable at a time.
- Pages return errors: inspect application and web server logs, database credentials, runtime versions, permissions, and rewrite rules.
- Images or downloads are missing: compare the file inventory, upload paths, storage permissions, and any external media configuration.
- Forms fail: test the mail transport, sender address, DNS authentication, API keys, and spam filtering. A successful form submission does not always mean delivery.
- Some visitors see the old site: check DNS records, propagation at different resolvers, cached content, and whether multiple records point to different servers.
- The site is slower: compare page templates, cache behavior, database queries, image delivery, server resources, and whether a CDN or optimization layer is configured correctly. The guide to speeding up WordPress on cloud hosting covers useful follow-up checks.
- Search traffic or indexing changes: verify redirects, canonical tags, sitemap availability, robots directives, and the status of important URLs before assuming the hosting move is the only cause.
Define a rollback threshold before cutover. For example, you might return DNS to the old host if checkout, login, email, or a critical integration remains unavailable after a defined troubleshooting period. Rollback is easier when the old site is unchanged, backups are verified, and DNS records are documented.
When to revisit
Review this checklist monthly during the first few months after migration, then at least quarterly. Revisit it sooner when you change hosting plans, move from shared or managed hosting to VPS hosting, add a new subdomain, launch an ecommerce function, change email providers, install major application updates, or alter DNS.
At each review, confirm that backups complete and can be restored, SSL remains valid, domain and email records are documented, uptime and error monitoring are active, storage and resource usage remain appropriate, and the rollback procedure still reflects the current setup. Check a representative set of pages, forms, logins, and business workflows rather than relying only on an uptime indicator.
Keep a dated migration record with the hosting provider, server details, DNS provider, renewal responsibilities, application versions, and recovery contacts. When the site outgrows its current plan, use observed traffic and resource patterns to decide whether to optimize, scale within cloud hosting, or evaluate a VPS for small business. A planned review is safer than waiting for a performance or availability problem to force the next move.
