A careful website migration can move your site to better web hosting without breaking pages, losing data, interrupting email, or confusing search engines. This checklist gives you a reusable workflow for WordPress and custom websites, including backups, staging, databases, DNS, SSL, redirects, monitoring, and rollback planning.
Overview
Changing a web hosting provider is more than copying website files. A site may depend on a database, scheduled jobs, contact forms, third-party integrations, email records, SSL certificates, DNS settings, and server-specific configuration. A successful migration preserves each dependency and provides a controlled path back if testing reveals a problem.
The safest approach is to separate the migration into three phases: prepare the new environment, test the copied site, and switch traffic only after the new version is ready. In many cases, visitors can continue using the existing site while the new environment is prepared. This reduces the risk of downtime and gives you time to compare the old and new deployments.
Before you begin, record the current state of the site. Note the hosting account, domain registrar, DNS provider, database type, PHP or runtime version, installed plugins, server rules, cron jobs, email services, analytics tools, and external integrations. A simple inventory prevents small but important dependencies from being forgotten.
If you are evaluating a new provider, compare more than storage and headline performance. Review the environment required by your application, backup controls, staging options, SSL support, access methods, logs, scaling choices, and monitoring capabilities. The cloud web hosting checklist can help structure that comparison.
What to track
1. Access and ownership
Confirm that you can access the current host, new host, domain registrar, DNS provider, database, deployment repository, and email administration panel. Identify who can approve the DNS change and who will respond if the migration encounters a problem. Do not start until you know how to restore the site or contact the relevant administrator.
2. Files, databases, and uploads
Create a complete backup of the website files and database before making changes. For WordPress, include the application files, uploads directory, themes, plugins, and configuration file. For a custom application, include environment configuration, build instructions, static assets, user uploads, and any data stored outside the main repository.
Keep at least one backup outside the current hosting account and verify that it can be opened or restored. A backup that has never been tested is only an assumption. Record the backup date, database export date, and the location of each copy.
3. The staging environment
Build the new site on a temporary hostname, staging domain, or restricted server address. Import the database and files, then update environment variables and connection details for the new server. Prevent search engines from indexing the staging copy, and protect it from public access where possible.
Check that the application runs on the new runtime and that file permissions, rewrite rules, caching, and scheduled tasks behave as expected. WordPress users should also check the site URL, permalink settings, media paths, active plugins, theme functionality, and administrator login.
4. Email and DNS dependencies
List every DNS record before changing anything. Include the main address, the www hostname, mail records, verification records, subdomains, and any records used by a CDN or external service. DNS changes should not be treated as a website-only task: an incorrect mail record can interrupt email even when the website itself appears healthy.
Confirm whether email remains with the existing provider or moves with the website. If email is staying where it is, preserve the required mail records. If it is moving, plan mailbox creation, message transfer, authentication records, and client configuration separately from the web migration.
5. SSL, redirects, and application behavior
Install and test the SSL certificate on the new host before the DNS cutover. Confirm that both the preferred hostname and its alternate form behave as intended, and that HTTP requests are redirected to HTTPS if that is your chosen configuration. For DNS and certificate troubleshooting, see this guide to connecting a domain to cloud hosting.
Test important user journeys rather than only the homepage. Submit forms, log in, create test orders if applicable, search the site, download files, load images, check comments, and test integrations. Compare page titles, canonical URLs, robots directives, structured data, and XML sitemaps with the current site. Preserve existing URLs whenever possible. If a URL must change, create a relevant one-to-one 301 redirect to the closest replacement.
6. Performance and monitoring baselines
Record a small baseline before the move: representative page load measurements, server response behavior, uptime observations, error rates, database size, and resource usage during normal traffic. The purpose is not to produce a perfect benchmark; it is to make meaningful before-and-after comparisons. A hosting speed benchmark can provide a repeatable starting point.
Prepare uptime checks for the homepage, a key content page, an important form, and any critical application endpoint. Also arrange access to server logs, application logs, and error notifications. Monitoring is most useful when it is configured before the cutover, not after an incident begins.
Cadence and checkpoints
Before the migration
Review the inventory, confirm backups, lower the DNS record time to live if appropriate, and freeze nonessential changes. A content freeze is especially useful for sites with active publishing, orders, registrations, or comments. If a full freeze is not practical, plan a final database or content synchronization immediately before the switch.
Choose a low-risk cutover window that gives the team time to test the live result. Record the exact actions, owners, and decision points. Include a clear stop condition, such as a failed database import, broken payment flow, missing email, or unexpected redirect behavior.
During the cutover
Take a final backup and synchronize changes that occurred after the initial copy. Confirm that the new site is ready, then update only the required DNS records. Avoid unrelated configuration changes during this window. Keep the old hosting account active while DNS changes are being observed.
Check DNS from more than one network or resolver, but do not assume that every visitor will switch at the same moment. DNS caches can produce a mixed period in which some requests reach the old host and others reach the new host. This is why both environments should remain functional during the transition.
After the cutover
Test the live site from a normal browser and from an external network. Check the homepage, major templates, forms, authentication, media, redirects, SSL, robots.txt, sitemap files, and analytics. Review logs for server errors, database errors, missing files, and unusual traffic patterns.
Monitor the site closely during the first day and again after the initial DNS transition period. Keep a migration log containing timestamps, DNS changes, test results, errors, and fixes. This record makes later investigations faster and becomes a useful runbook for the next migration.
How to interpret changes
A migration is not complete merely because the homepage loads. Compare the new environment with the baseline and investigate meaningful differences. Higher response times may indicate a runtime mismatch, database configuration issue, missing cache, overloaded resources, or an application change. A rise in 404 errors may point to missing uploads, incorrect rewrite rules, or incomplete redirects.
Separate temporary transition effects from persistent defects. A short period of mixed DNS results may be expected, while repeated certificate warnings, broken forms, or missing pages require immediate action. If only one feature fails, inspect its dependencies rather than assuming the entire hosting platform is at fault.
Watch search performance without making premature conclusions. Confirm that important URLs remain indexable, canonical tags are correct, redirects resolve in one step where practical, and the sitemap contains the intended URLs. A hosting move should not change SEO directives accidentally.
If the new host performs worse, first compare like with like: the same page, uncached and cached states, geographic test location, traffic level, and application version. For broader technical checks, review the technical SEO hosting checklist and consider whether a CDN or caching layer is configured consistently.
Keep rollback criteria objective. Roll back when a critical function cannot be restored within the planned window, data integrity is uncertain, email is disrupted, or the new environment creates a serious security or availability problem. Rolling back DNS does not fix a bad database copy, so preserve the old site and its data until the new deployment is proven stable.
When to revisit
Revisit this checklist before every hosting change, major application upgrade, domain change, or infrastructure redesign. A quarterly review is useful for active sites, while lower-change sites can review it at least twice a year. The goal is to keep the migration information current before it is needed under pressure.
Update the inventory whenever a new subdomain, email service, payment provider, integration, cron job, CDN, or database is added. Recheck backup restoration, monitoring alerts, DNS ownership, SSL renewal, and rollback access when team members or vendors change. Also update the runbook after each migration so that future instructions reflect what actually happened.
Use this practical closeout sequence:
- Save the final backup and migration log.
- Confirm the live DNS, SSL, email, and redirect configuration.
- Compare performance, uptime, errors, and key user journeys with the baseline.
- Review search visibility signals and fix any unexpected indexing or URL changes.
- Keep the old hosting environment available until the agreed stability period has passed.
- Document the new architecture, access owners, renewal dates, and rollback steps.
For ongoing operations, pair the migration record with a website uptime monitoring checklist. When the site grows, traffic patterns, resource needs, and deployment risks may change; that is the point to reassess hosting capacity and review when an upgrade is justified.
