A hosting migration is easiest to manage when it is treated as a controlled release rather than a simple file transfer. This checklist shows how to inventory the current environment, build and test the new one, move databases and email safely, coordinate DNS, verify SSL and redirects, and keep a rollback plan ready so visitors experience as little disruption as possible.
Overview
Moving a website to a new web hosting provider can improve performance, reliability, support, or operational control. It can also expose dependencies that are easy to miss: scheduled jobs, environment variables, payment callbacks, cron tasks, image storage, firewall rules, and email records.
The goal is not to copy files and hope the site works. A reliable website hosting migration separates the work into four phases:
- Discovery: document the current site, services, DNS records, email setup, and access credentials.
- Preparation: provision the new hosting account, transfer the application and data, and configure a staging or temporary hostname.
- Cutover: reduce avoidable DNS delay, perform a final data sync, update records, and confirm the new server is receiving traffic.
- Verification: test the site, transactions, forms, email, certificates, logs, and performance before closing the old account.
Downtime cannot always be eliminated, particularly for sites with constantly changing data or complex integrations. However, preparation can make the change predictable and provide a clear recovery path if a problem appears.
What to track
1. Create an inventory before changing anything
Record the current hosting provider, server type, operating system, application version, runtime versions, database engine, web server, storage locations, and deployment method. Note every domain and subdomain, including administrative, API, staging, and asset hostnames.
Capture the current DNS records before editing them. Include A and AAAA records, CNAME records, MX records, TXT records for email authentication, and any verification records used by third-party services. The DNS records configuration guide can help organize this inventory.
Also list external dependencies such as payment processors, analytics platforms, content delivery networks, object storage, webhooks, monitoring services, and identity providers. A migration can appear successful while a less frequently used integration is failing in the background.
2. Back up files, databases, and configuration
Take a complete backup before beginning. For a CMS, this usually includes application files, uploaded media, the database, configuration files, and any custom code. For a modern application, include deployment manifests, environment-variable names, build instructions, dependency lockfiles, uploaded assets, and persistent storage.
Keep at least one backup outside the current hosting account and verify that it can be opened or restored. A backup that exists only on the server being replaced is not a dependable rollback plan. For WordPress sites, use the WordPress backup and restore checklist to review what should be preserved.
3. Prepare the destination environment
Match the required runtime and database versions first. Then configure users, permissions, firewall rules, SSH keys, storage, caching, scheduled jobs, and deployment access. Do not assume that a new managed hosting plan reproduces the old server's settings automatically.
Install the site on a temporary hostname, hosts-file override, or staging environment. Restrict access while testing, especially if the site contains personal data or unpublished content. Confirm that the application can connect to its database and that uploads, background jobs, search, forms, and administrative functions work as expected.
4. Plan the database and email move
For a mostly static site, a final file copy may be sufficient. For an application with orders, registrations, comments, bookings, or other changing records, identify how new data will be captured during the cutover. Options may include a short maintenance window, read-only mode, replication, or a final export and import immediately before DNS changes.
Email deserves its own plan. Determine whether mailboxes remain with the current provider, move to the new host, or use a separate email service. Document mailbox names, forwarding rules, aliases, autoresponders, spam settings, and mobile or desktop client settings. Changing web hosting does not automatically require changing mail hosting, so avoid modifying MX records unless the email service is actually moving.
5. Verify SSL, redirects, and application URLs
Install and test the SSL certificate for every required hostname, including the preferred www or non-www version and relevant subdomains. Check that HTTP redirects to HTTPS, canonical URLs are consistent, and the application does not generate links pointing back to the old host.
Review rewrite rules and redirect mappings. Preserve important paths when the site's URL structure is unchanged, and create deliberate 301 redirects when URLs must change. Test representative old URLs, login pages, forms, downloadable files, images, and API endpoints.
Cadence and checkpoints
Use a written migration checklist and assign an owner to each checkpoint. The exact timing depends on the site's size and traffic pattern, but the sequence below works for many small business sites, WordPress installations, and developer-managed applications.
Several days before cutover
- Confirm access to the domain registrar, DNS provider, current host, new host, database, and email administration.
- Review backups and perform a test restore if the site is business-critical.
- Lower DNS TTL values if appropriate and if the DNS provider allows the change. This can make planned record changes update more quickly for some resolvers, but it does not force every cached result to expire immediately.
- Complete functional testing on the new environment using a temporary hostname or local resolution override.
- Tell stakeholders when testing, cutover, and verification will occur. Choose a period with low transaction or publishing activity when possible.
During cutover
- Put the current application into maintenance or read-only mode if new data could be lost during synchronization.
- Perform the final database and file sync.
- Confirm the destination database contains the latest records and that configuration values point to production services.
- Update only the DNS records required for the website. Leave unrelated records unchanged.
- Monitor both the old and new environments while DNS changes propagate.
Immediately after the change
Test the site from more than one network or DNS resolver. Check the homepage, key landing pages, login, search, forms, checkout or booking flow, file downloads, robots.txt, XML sitemaps, analytics, and critical API requests. Inspect server logs for 404, 500, database, permission, and timeout errors.
Confirm that email can be sent and received, especially if MX, SPF, DKIM, or DMARC records were changed. Review the online DNS troubleshooting guide when records appear inconsistent across resolvers.
How to interpret changes
Do not judge a migration only by whether the homepage loads. Compare the new environment with a baseline taken before the move. Useful indicators include response time, error rate, cache behavior, CPU and memory usage, database latency, storage use, and the volume of 404 or 5xx responses.
A brief increase in DNS-related inconsistency can occur while cached records expire. A persistent split between old and new content usually indicates an incomplete DNS change, multiple authoritative configurations, a proxy or CDN setting, or an application that is still writing to the old database.
Functional failures often reveal missing configuration rather than a hosting capacity problem. A contact form that stops sending may need an SMTP setting. Broken uploads may indicate filesystem permissions or a missing storage mount. Failed scheduled tasks may result from an incorrect cron path, disabled worker, or changed runtime version.
Keep the old hosting environment available until the new site has passed an agreed observation period and recent backups from the new system have been verified. If a serious issue appears, use the documented rollback plan: restore the previous DNS values, reopen the old application if necessary, and preserve logs from both environments for diagnosis. A rollback is safer when it is a rehearsed procedure rather than an improvised reaction.
When to revisit
Review this migration checklist before any future provider change, major infrastructure upgrade, domain transfer, or redesign that alters hosting requirements. For an active website, revisit the inventory monthly or quarterly so it reflects new integrations, DNS records, scheduled jobs, certificates, email arrangements, and backup locations.
Set recurring checkpoints for backup restoration, SSL certificate status, DNS ownership, storage growth, database size, error logs, uptime alerts, and application version compatibility. Recheck these items after a major plugin or framework update, a new payment or email integration, a change in traffic patterns, or an incident.
To make the next migration easier, finish this one by updating the runbook while details are still fresh. Record what was copied, which commands or tools were used, which DNS records changed, how long verification took, and what failed during testing. Then store the runbook, backup locations, access ownership, and rollback steps somewhere the responsible team can reach without relying on the old host.
Action plan: create the inventory today, verify an independent backup, build the destination in parallel, test with a temporary hostname, schedule a controlled cutover, monitor the old and new environments together, and keep the checklist as a living infrastructure document.
