Moving a website to cloud hosting is manageable when you separate the work into preparation, staging, DNS, verification, and monitoring. This hosting migration checklist gives small businesses, creators, and developers a repeatable process for moving a site with minimal interruption while protecting files, databases, email, search visibility, and customer access.
Overview
A migration is more than copying website files from one server to another. A successful move also accounts for databases, application settings, domain records, SSL certificates, email, scheduled tasks, redirects, analytics, and any integrations that depend on the old host.
The safest approach is to keep the current website live while you prepare and test a complete copy on the new platform. You then lower the risk of downtime by changing DNS only after the new environment is ready. The old hosting account should remain available until the new site has been verified and DNS changes have had time to take effect.
This workflow applies to many hosting setups, including managed hosting, WordPress hosting, VPS hosting, and other cloud hosting environments. The exact control-panel labels will vary, but the underlying sequence remains similar. If you are still comparing platforms, review managed hosting vs unmanaged hosting and consider whether your site needs the control of a VPS or the simpler maintenance model of managed hosting.
What to track
1. Make an inventory before moving
Record what exists on the current host before you change anything. At minimum, note:
- Domain names and subdomains, including www and staging addresses.
- Website files, themes, plugins, uploads, custom scripts, and configuration files.
- Databases, database users, table prefixes, and connection details.
- DNS records for the website, email, verification services, APIs, and subdomains.
- SSL certificates and the process used to renew them.
- Email mailboxes, forwarding addresses, autoresponders, and mail-related records.
- Cron jobs, scheduled backups, queues, webhooks, and third-party integrations.
- Analytics, search tools, conversion tracking, and any uptime or security monitoring.
Take screenshots or export records where useful. A simple inventory prevents a common migration failure: the website loads, but an overlooked service such as email delivery, a webhook, or a scheduled task stops working.
2. Create and verify backups
Make at least one complete backup before beginning. For a content management system, this normally includes both the application files and the database. Download a copy outside the old hosting account, and label it with the date and time.
A backup is only useful if it can be restored. Check that the archive opens, the database export is readable, and the backup contains recent uploads. If your host offers a restore test or staging restore, use it before the migration. Do not close the old account until you have a verified fallback.
3. Prepare the new cloud hosting environment
Set up the destination without changing the public DNS yet. Match the required runtime and application settings, including the PHP or server version, database engine, file permissions, environment variables, and storage paths. For WordPress, check the site URL, permalink structure, media directory, caching configuration, and plugin compatibility.
Some hosts provide one-click app deployment or migration tools. These can reduce manual work, but review the result rather than assuming the process is complete. A migration tool may copy the site while leaving DNS, email, cron jobs, or external integrations untouched.
4. Copy files and databases
Transfer the site files and import the database into the new environment. Update connection settings carefully, and preserve file permissions that the application needs. For larger sites, use a method that can resume interrupted transfers instead of relying on a single browser upload.
Preview the new site using a temporary address, hosts-file entry, staging domain, or the preview feature supplied by the host. Avoid indexing a staging copy: use the platform's privacy setting or an appropriate noindex control, and remove that restriction before the site becomes public.
5. Confirm SSL, redirects, and email
Install and test the destination SSL certificate before switching traffic. Confirm that both the root domain and the www version behave as intended, and that HTTP requests redirect to HTTPS where appropriate. Many cloud hosting plans support free SSL, but certificate issuance still depends on correct domain validation and DNS configuration.
Review every important redirect, especially if URLs or site structure are changing. Keep a list of old URLs that need permanent redirects and test representative pages, images, downloads, and form destinations.
Email deserves separate attention. Check MX, SPF, DKIM, and any provider-specific records before changing nameservers or DNS. If email remains with a separate provider, do not remove its records simply because the website is moving. Send and receive test messages after the DNS change.
6. Keep a migration checklist
Save this compact checklist in your project notes and mark each item with an owner and timestamp:
- Inventory completed.
- Files and database backed up and restore checked.
- New server or managed hosting account configured.
- Files, database, settings, and environment variables transferred.
- Staging copy reviewed on desktop and mobile.
- SSL certificate issued and HTTPS tested.
- Redirects, forms, checkout, search, and login tested.
- Email and DNS records documented.
- Analytics, tracking, cron jobs, backups, and integrations confirmed.
- DNS change scheduled and rollback plan documented.
- Post-launch monitoring assigned.
Cadence and checkpoints
Use checkpoints rather than treating migration as one large event.
Several days before the move
Confirm the backup, audit DNS, test the destination, and record baseline observations. Useful baselines include representative page load behavior, form submissions, checkout or booking completion, indexed URL patterns, and current error reports. If the domain provider allows it, reduce the DNS record time-to-live before the change. This may help resolvers refresh sooner, but it does not eliminate DNS propagation or guarantee an immediate switch.
On migration day
Choose a period when traffic and transaction volume are relatively low. Take a final database backup, especially if the site receives comments, orders, registrations, or other changing data. If possible, temporarily pause high-risk content changes. Copy any final changes, verify the destination again, and then update the relevant DNS records or nameservers.
During the first few hours
Check the site from more than one network and device. Test the homepage, key landing pages, forms, login, media, search, checkout, redirects, and HTTPS. Monitor server errors, application logs, uptime alerts, analytics, and email delivery. DNS propagation can be uneven, so some visitors may reach the old host while others reach the new one.
For the first week
Keep the old site available, but avoid making independent content changes in both locations. Compare traffic, conversions, crawl or indexing alerts, error rates, and resource use with the baseline. Confirm that automated backups and scheduled tasks are running on the new host.
How to interpret changes
Not every post-migration warning means the transfer failed. Interpret each signal in context.
- Some visitors see the old site: DNS propagation or cached records may be responsible. Check authoritative DNS records and allow time for different resolvers to update.
- The site loads but forms fail: Inspect SMTP settings, security rules, environment variables, and third-party API keys. Test both validation errors and successful submissions.
- Pages return 404 errors: Check permalink rules, rewrite configuration, case-sensitive file paths, and the redirect map.
- HTTPS warnings appear: Confirm the certificate covers the required hostname and look for mixed-content references to HTTP assets.
- The site is slower: Compare the same pages under similar conditions. Check server resources, caching, image delivery, database queries, plugins, and whether a CDN or suitable configuration is needed. The guide on speeding up WordPress on cloud hosting provides a useful follow-up workflow.
- Email stops arriving: Review MX records first, then SPF, DKIM, mailbox routing, and spam or bounce logs. Website DNS and email DNS can be related but are not interchangeable.
- Search traffic changes: Look for altered URLs, missing redirects, blocked staging settings, changed canonical tags, robots rules, or unavailable pages before assuming the hosting move itself caused the change.
If the new site is seriously broken, use the documented rollback plan: restore the previous DNS records, keep the old host online, and investigate the destination without deleting evidence or backups.
When to revisit
Review this migration checklist at three practical intervals. First, revisit it before every hosting change, major redesign, domain move, or platform upgrade. Second, perform a light post-migration review after the first day, again after the first week, and at the end of the first month. Third, add it to a quarterly website maintenance routine so that backups, DNS records, SSL renewal, email routing, redirects, monitoring, and scheduled tasks do not become undocumented.
Return sooner when recurring data changes: traffic rises, the site adds ecommerce or bookings, a new subdomain launches, storage approaches its limit, error rates increase, or the application moves to a new runtime. These are signals to reassess capacity, backup frequency, caching, and whether your current web hosting still fits the site. For growing workloads, compare the practical limits of your plan with the guidance in how much traffic hosting can handle and review whether scalable cloud servers or VPS hosting are justified.
Finally, keep one current migration document with access owners, DNS records, backup locations, test URLs, rollback steps, and the date of the last review. That small habit turns a stressful one-time move into a controlled, repeatable part of website maintenance.
