A hosting migration does not end when the new server loads your homepage. Use this recurring checklist to prepare backups, test DNS and email, protect search visibility, verify performance, and know when to roll back or revisit the migration.
Overview
Moving a website to a new host can improve reliability, capacity, security, or operational control, but the change touches more than website files. A migration may also affect databases, domain records, SSL certificates, email delivery, scheduled tasks, analytics, redirects, and search-engine discovery.
The safest approach is a staged migration rather than a single “switch” event. Build a complete backup, prepare the destination, copy the site, test it before changing DNS, and monitor both hosts during the transition. Keeping the old hosting account available for a defined rollback period gives you a recovery option if an unexpected problem appears.
This checklist is designed for business websites, WordPress installations, application deployments, and static sites. The exact commands will vary by platform, but the control points remain broadly useful. For a fuller procedural walkthrough, see How to Move Your Website to a New Host: Complete Migration Checklist.
What to track
1. Inventory the current environment
Before choosing a migration window, record what the existing website actually uses. Include the domain and subdomains, DNS provider, hosting control panel, application version, database engine, PHP or runtime version, SSL configuration, cron jobs, CDN, firewall rules, analytics, forms, and third-party integrations.
Do not assume email is hosted with the website. Document the MX records and any TXT records used for SPF, DKIM, or DMARC. If email is managed elsewhere, preserve those records while updating only the web-related entries. The guide to SPF, DKIM, and DMARC can help separate website DNS changes from mail authentication requirements.
2. Create and verify backups
A hosting migration backup should include both the site files and the database. For a WordPress site, also account for uploads, configuration files, themes, plugins, and any server-level rules. Export databases in a format that can be restored by the destination environment, and keep a separate copy outside the current hosting account.
A backup is not complete until it has been checked. Confirm that the archive opens, the database export contains recent data, and the restoration process is understood. If practical, restore the backup to a temporary environment before the migration. Keep a dated copy of the original backup so later files cannot overwrite your last known-good version.
3. Prepare the new hosting environment
Match the destination to the application’s requirements before transferring traffic. Check the supported runtime, database version, storage permissions, memory limits, rewrite rules, scheduled tasks, and available SSL certificate options. A hosting control panel can simplify account creation and DNS management, but verify each setting instead of relying on defaults.
Copy the website to a temporary hostname, preview URL, or hosts-file test environment. Avoid making the staging copy publicly indexable. Use access controls where possible, and remove test credentials and temporary files before launch.
4. Lower DNS TTL before the change
DNS records are cached according to their time to live, or TTL. Before the migration, review the relevant A, AAAA, CNAME, and other records and reduce the TTL for the web records if your DNS provider allows it. Make this change early enough for existing caches to age out. A lower TTL does not force every resolver to update immediately, so plan for a period during which visitors may reach either host.
Keep mail records unchanged unless the mail service is also moving. For a practical explanation of A, CNAME, MX, TXT, and related records, read DNS Records Explained: A Practical Guide to Connecting a Domain to Hosting.
5. Test content, functions, and SEO signals
On the new host, test representative pages rather than only the homepage. Check navigation, forms, search, logins, checkout or booking flows, media files, downloadable documents, APIs, contact notifications, and scheduled jobs. Review server and application logs for missing files, permission errors, database warnings, and failed background tasks.
Compare the staging site with the live site for titles, meta descriptions, canonical URLs, robots directives, XML sitemaps, structured data, internal links, and image references. Confirm that the staging environment is not accidentally blocking the production site after launch. Preserve existing URL paths wherever possible. If URLs must change, create one-to-one permanent redirects and update internal links, canonicals, and the sitemap.
6. Plan SSL and email validation
Install and test the SSL certificate on the destination before switching traffic. Check both the root domain and the www or other active hostnames, then confirm that HTTP redirects to HTTPS where intended. Certificate installation alone is not enough: mixed-content warnings, incorrect redirects, or an incomplete certificate chain can still affect visitors.
Send and receive test messages using the domain after the DNS change. Verify MX, SPF, DKIM, and DMARC records, contact forms, password resets, and transactional messages. If the site sends mail through a separate provider, confirm that the new server is authorized to use the required sending configuration.
Cadence and checkpoints
Before migration day
- Record the current DNS zone and hosting configuration.
- Create, download, and verify files and database backups.
- Prepare the destination account, runtime, database, SSL, and access controls.
- Copy the site and complete functional, technical, and SEO tests.
- Document the DNS change, responsible contacts, maintenance window, and rollback decision.
During the DNS cutover
Choose a period when the site receives fewer changes, orders, or submissions. If the website is database-driven, place it in maintenance mode or temporarily restrict writes while taking the final database backup. Copy that final data to the destination, verify it, and then update only the required DNS records.
Record the exact time of the change. Check DNS responses from more than one network or resolver, and test the site by domain name rather than only by server IP. Keep the old host active. Do not cancel it simply because the first test succeeds.
After the switch
Monitor the old and new environments during the first hours, then perform another review after DNS caches have had time to refresh. Check uptime, response errors, server logs, database writes, forms, email, SSL, redirects, analytics, and search-console coverage if available. Compare key page templates and important conversion paths with their pre-migration behavior.
Keep a migration log containing DNS changes, test results, errors, fixes, and decisions. This creates a useful record for future maintenance and makes it easier to identify whether a later problem began during the migration or afterward. Continue backups on the new host before closing the old account.
How to interpret changes
Not every difference indicates a failed migration. DNS propagation can make results inconsistent for a period, while cached pages or CDN content may temporarily hide a fix. Compare results across several networks and check authoritative DNS responses when investigating a record problem.
A sudden increase in server errors, missing pages, failed forms, database warnings, or authentication problems usually requires immediate investigation. Review application and web-server logs first, then compare permissions, environment variables, runtime versions, rewrite rules, and database credentials between the two hosts.
Search visibility should be evaluated separately from technical availability. Confirm that important URLs return the expected status, redirects point directly to the correct destination, canonicals use the production domain, and the new sitemap is accessible. If pages disappear from search tools or organic traffic changes unexpectedly, look for accidental noindex directives, blocked resources, redirect chains, changed URLs, or incomplete content transfers before assuming the host itself is responsible.
Define rollback criteria in advance. Examples include an unresolved checkout failure, widespread application errors, broken mail delivery, missing customer data, or an SSL problem affecting core pages. If rollback is required, restore the previous DNS records, preserve logs, and avoid deleting the destination copy until the cause is understood.
When to revisit
Review the migration checklist at least once after the first day, again after the first week, and then on a monthly or quarterly cadence. The first review should focus on errors, forms, email, SSL, redirects, and data consistency. The later review should examine uptime records, resource usage, backup success, security updates, renewal dates, and recurring application errors.
Revisit the checklist immediately when the website changes hosting plans, adds a subdomain, moves email, changes its CDN or DNS provider, upgrades its runtime, launches a major application feature, or replaces its CMS. A migration that was safe for a small static site may need a different process when the site gains a database, customer accounts, or frequent transactions.
For ongoing reliability, pair this review with a broader website security checklist and a periodic performance review. If the new environment is shared hosting, also watch resource limits and page response patterns; the guide to speeding up a slow website on shared hosting covers practical follow-up checks.
Finally, keep one current migration runbook with owners, access details, backup locations, DNS instructions, test URLs, rollback steps, and the date of the last successful restore test. Updating that document after each infrastructure change turns a one-time hosting migration into a repeatable reliability practice.
