Migrating a website to cloud hosting can improve resilience, performance, and room to grow, but an incomplete transfer can interrupt pages, email, analytics, or search visibility. This repeatable migration runbook explains what to inventory, back up, test, monitor, and revisit so you can move with a controlled cutover and a practical rollback plan.
Overview
A website migration to cloud hosting is more than copying files to a new server. A successful move preserves the site’s content, database, URLs, domain configuration, SSL certificate, email records, scheduled tasks, integrations, and measurement tools. It also gives you a way to detect problems before and after DNS changes take effect.
The safest approach is to treat the migration as a staged project:
- Inventory the current environment and record dependencies.
- Create and verify backups before changing anything.
- Prepare the destination and copy the site to a private staging address.
- Test functionality, redirects, performance, security, and email-related DNS records.
- Lower DNS time-to-live when appropriate, schedule the cutover, and keep the old hosting available.
- Monitor the new environment and confirm that a rollback is still possible.
Cloud hosting for websites may use different control panels, server software, database versions, caching layers, or security defaults than the old host. Document those differences instead of assuming that a site will behave identically after the move. If you use managed website hosting, confirm which parts of the migration the provider handles and which tasks remain your responsibility.
For planning context, compare this runbook with the guide to migrating a website to new hosting without downtime and review the web hosting for small business plan guide before selecting the destination environment.
What to track
1. Site inventory and dependencies
Record every component that must work after the migration. Include the domain and subdomains, website files, databases, uploads, themes, plugins, server-side scripts, cron jobs, forms, payment or booking integrations, analytics, search tools, CDN settings, and third-party APIs. Note the versions of the application runtime, database engine, and major extensions where available.
Make a URL sample that includes the homepage, key landing pages, blog posts, product or service pages, contact forms, PDFs, images, and any pages with query parameters. Export or crawl the existing URL structure so you can compare it with the new site. Pay particular attention to canonical tags, robots directives, XML sitemaps, and redirects.
2. Backups and restoration evidence
Keep at least one complete copy of the website files and one database export. If the site stores uploads outside the main web directory, back those up separately. Save configuration files, environment variables, SSL-related settings, DNS records, and custom redirect rules in a secure location without exposing credentials.
A backup is not a rollback plan until you know it can be restored. Test a restoration on the destination or a separate environment. Confirm that the database imports cleanly, uploaded media appears, user logins work, and the application can connect to its database. The website backup and restore guide provides a useful checklist for this step.
3. DNS, email, and SSL records
List the current DNS records before making changes. Include A and AAAA records, CNAME records, nameservers, MX records, and TXT records used for SPF, DKIM, DMARC, verification, or other services. Changing web hosting does not necessarily mean changing email hosting. Preserving the correct MX and authentication records is essential for business email with a domain.
Confirm how the new host will issue and renew the SSL certificate. Test both the preferred hostname and alternate versions, such as the www and non-www addresses, then check that HTTP requests redirect to HTTPS. Use the domain, DNS, SSL, and business email setup checklist when preparing the records.
4. Migration verification points
Track a small, repeatable set of checks rather than relying on a general impression that the site looks fine. Record:
- HTTP response status for important URLs.
- Redirect destinations and redirect chains.
- Page titles, canonical URLs, robots directives, and sitemap availability.
- Form delivery, transactional messages, logins, search, checkout, and other critical functions.
- Database connection errors, application errors, and failed scheduled tasks.
- Page load behavior on representative pages and devices.
- SSL validity, mixed-content warnings, and security headers where configured.
Cadence and checkpoints
Before staging
Take a fresh backup, freeze unnecessary content changes if practical, and record the current DNS zone. Verify access to the domain registrar, DNS provider, old host, new host, database, analytics, and email administration. Decide who can approve the cutover and who will investigate issues during the monitoring window.
During staging
Copy files and the database to the new environment, then protect the staging address from indexing. Update configuration values carefully, including database credentials, application URLs, cache settings, and environment-specific secrets. Do not use a staging address that can be mistaken for the public site by visitors or search engines.
Test representative pages and workflows. Check media paths, internal links, forms, user sessions, admin functions, scheduled jobs, and integrations. If the new platform changes server behavior, review file permissions and application compatibility instead of copying settings blindly.
At cutover
Choose a low-risk period that allows time for testing and support. Take a final database backup immediately before changing DNS, particularly for sites that receive orders, appointments, comments, or account updates. If possible, temporarily limit changes during the final copy so that data is not written to the old and new environments at the same time.
Update only the DNS records required for the web service. Leave email records unchanged unless email is moving too. Keep the old hosting account active while DNS changes propagate and verification is complete. Record the exact time of the change and the previous values so rollback is straightforward.
After cutover
Check the site using the domain, not only the temporary staging address. Test several networks or DNS resolvers where practical, because different users may receive different answers during propagation. Watch application logs, uptime checks, form submissions, analytics activity, search crawling signals, and support messages. Do not cancel the old hosting until the new environment has passed the agreed monitoring period and the final backup is safely stored.
How to interpret changes
A small difference in page timing may reflect caching, traffic, or a test environment. A consistent increase in server response time, however, warrants investigation of database queries, application errors, resource limits, DNS configuration, or cache behavior. Use the same representative URLs and testing conditions before and after migration so comparisons are meaningful. The website speed guide can help prioritize performance fixes after the move.
A sudden drop in organic visits should not automatically be attributed to hosting. First check whether important URLs return errors, redirects point to the wrong destinations, the site is blocked from crawling, canonical tags changed, or the sitemap is unavailable. Compare logs and analytics by landing page rather than looking only at total traffic.
Email problems often indicate a DNS or authentication issue rather than a website-file problem. Confirm MX, SPF, DKIM, and DMARC records against the email provider’s documented requirements. If only contact-form messages fail, inspect the application’s mail configuration and delivery logs separately.
Security warnings should be handled as release blockers. An invalid certificate, mixed content, exposed staging site, missing access control, or leaked credential requires immediate attention. Refer to the website security checklist and the SSL setup guide for recurring checks.
When to revisit
Review this migration record monthly during the first few months, then at least quarterly or whenever the site undergoes a significant change. Revisit it sooner when you change DNS providers, add a subdomain, move business email, install a major application update, alter caching, introduce a CDN, or experience an outage.
Use the following recurring checklist:
- Confirm that automated backups completed and that a recent restore test remains possible.
- Review uptime, response times, error logs, storage, bandwidth, and resource usage.
- Test the homepage, top landing pages, forms, login, checkout or booking flow, and key integrations.
- Verify SSL renewal, HTTPS redirects, DNS records, email delivery, and domain registration access.
- Check redirects, canonical tags, robots directives, sitemap status, and important search landing pages.
- Remove unused staging accounts, old credentials, temporary files, and unnecessary services.
- Update the inventory whenever a plugin, application, database, DNS, or hosting dependency changes.
Keep the results in a dated migration log with the person responsible, the evidence reviewed, and any follow-up action. If a check fails, identify whether the issue is caused by DNS, hosting resources, application code, content, email configuration, or security controls before changing multiple variables at once. That discipline makes the next migration, recovery, or hosting review faster and safer.
