Website Migration Checklist: Move Hosting Providers Without Losing Traffic or Data

Overview

Website migration is the process of moving a site from one hosting environment to another. The domain may remain with the same registrar, or the move may also include a domain transfer. These are separate tasks: changing hosting usually involves updating DNS records, while transferring a domain changes the registrar responsible for managing it.

The safest approach is to treat migration as a staged project rather than a single switch. First, document the current environment and create recoverable backups. Next, build and test the site on the new host without changing public DNS. After validation, lower the risk of downtime by planning the DNS change, watching traffic and errors, and keeping the old hosting account available until the migration is confirmed.

Your migration plan should identify four things before any work begins:

• What is moving: website files, databases, media, configuration, cron jobs, SSL settings, and email services.
• What is staying: the domain registrar, DNS provider, email provider, CDN, or third-party integrations.
• What can break: database connections, forms, login sessions, rewrite rules, payment flows, email delivery, and scheduled tasks.
• How you will recover: a tested backup, documented DNS records, administrator credentials, and a clear rollback decision.

If you are comparing hosting environments before the move, review the practical differences between shared hosting, VPS, and cloud hosting. The new plan should support your software versions, storage needs, traffic patterns, backups, and access requirements rather than simply offering more resources.

What to track

1. Inventory the current website

Record the website’s domains and subdomains, hosting account, DNS provider, registrar, CMS version, PHP or runtime version, database type, SSL configuration, CDN, email provider, and third-party services. Note every hostname that visitors or systems use, including www, an API subdomain, staging, mail, and any custom application endpoint.

Export or copy the current DNS zone before making changes. Include A, AAAA, CNAME, MX, TXT, and any verification records. This is especially important when email hosting for the domain is separate from web hosting. Removing or overwriting MX, SPF, DKIM, or DMARC records can affect mail even when the website itself appears healthy.

2. Create and verify backups

Make a complete backup of the website files and database. If the site uses WordPress, include the uploads directory, configuration file, plugins, themes, and any custom code. Keep at least one backup outside the current hosting account. A backup is useful only if it can be restored, so verify that the archive opens and, where practical, perform a test restoration on a private environment.

Record the backup date, location, database credentials needed for restoration, and the person responsible for recovery. Take a final database backup immediately before the DNS change if the website accepts orders, registrations, comments, or other frequently changing data.

3. Prepare the new hosting account

Create the destination site using a temporary URL, preview address, hosts-file override, or another method that lets you test privately. Match the required runtime and database settings before importing content. Transfer files with the host’s migration tool, SFTP, SSH, or a control panel backup, depending on the environment.

Import the database and update only the settings required for the new environment. Check file ownership and permissions, environment variables, connection strings, rewrite rules, cache configuration, and scheduled jobs. Do not assume that a cPanel backup or automated migration includes external DNS records, email accounts, cron jobs, firewall rules, or server-level configuration.

4. Test functionality and performance

Use a test checklist that reflects real user journeys. Load the homepage and important landing pages, search the site, submit forms, log in and out, upload media, place a test order if applicable, and confirm transactional email behavior. Inspect browser-console errors, server logs, database errors, broken images, redirects, and mixed-content warnings.

Run a basic hosting speed test before and after the move using comparable pages and conditions. A change in speed may result from caching, CDN configuration, application settings, or server resources, so record the test method rather than relying on a single score. For related optimization work, see this guide to caching, CDN use, and image optimization.

5. Protect SEO signals

Most hosting changes do not require a URL change. Preserve the existing domain structure, canonical URLs, robots.txt behavior, XML sitemap, metadata, internal links, and status codes. Crawl the new copy before launch and compare its important URLs with the current site.

If URLs must change, prepare one-to-one, permanent redirects from old URLs to their closest relevant destinations. Avoid sending every old page to the homepage. Keep a list of changed URLs and check for redirect chains, loops, soft 404s, and accidental noindex directives. A hosting migration that also changes URLs is a larger SEO migration and needs separate validation.

6. Plan DNS and SSL

Confirm the destination IP addresses or CNAME targets supplied by the new host. Decide whether DNS remains with the registrar, moves to the host, or is managed through a service such as Cloudflare. If you use Cloudflare, review its DNS and proxy settings before changing the origin; the relevant setup considerations are covered in this Cloudflare guide.

Install or enable SSL on the new host before public traffic arrives. Test both the preferred hostname and any redirects between HTTP, HTTPS, the root domain, and www. Confirm that certificates cover required subdomains and that applications generate secure links.

Cadence and checkpoints

Use these checkpoints to control the migration:

1. One to two weeks before: inventory services, confirm the new host supports the application, document DNS, review the migration window, and create a tested backup.
2. Several days before: copy the site to the new host, configure SSL, recreate email and scheduled tasks where required, and test the site privately.
3. Immediately before launch: take a fresh database backup, pause nonessential content changes, confirm DNS values, and record the rollback plan.
4. During the DNS change: monitor DNS answers, HTTP status codes, SSL, forms, logins, email, and server resources from more than one network where possible.
5. For the next 24 to 72 hours: compare traffic, conversions, crawl activity, errors, latency, and email delivery with the pre-migration baseline.
6. After stabilization: retain the old hosting account until the agreed validation period has passed, then remove it only after confirming that no overlooked service depends on it.

DNS changes do not make every resolver update at the same time. Avoid judging the migration from one device or one network. Maintain a written change log with timestamps, DNS values, test results, and observed errors.

How to interpret changes

A brief difference in traffic or response time is not automatically a failed migration. First separate DNS propagation or measurement variation from a genuine application problem. Check whether the affected users resolve the old or new destination, then inspect the relevant server logs.

Common patterns provide useful clues:

• Pages return 404: compare document roots, rewrite rules, case-sensitive filenames, and permalink configuration.
• Pages return 500 or show a blank screen: review runtime versions, missing extensions, file permissions, environment variables, and application logs.
• Forms or orders fail: check API credentials, outbound mail, payment callbacks, firewall rules, and webhook URLs.
• Email stops arriving: compare MX records and mail-provider authentication records. Do not change mail DNS merely because web hosting changed.
• Search visibility falls: inspect robots.txt, noindex settings, canonicals, redirects, sitemap availability, and whether important pages return the expected status code.
• The site is slower: compare origin response time, caching, CDN routing, database load, image delivery, and application logs before changing multiple variables.

Rollback is appropriate when the new environment cannot serve critical functions and the cause cannot be corrected within the planned window. Point DNS back to the old host, restore any paused services, and preserve logs from the failed attempt. Do not delete the destination copy; it may contain evidence needed for the next migration.

When to revisit

Revisit this checklist before every hosting change, domain transfer, major platform upgrade, or infrastructure redesign. A quarterly review is useful even when no migration is planned: confirm that backups still run, restoration instructions still work, DNS documentation is current, SSL renewals are covered, and monitoring alerts reach the right people.

Review it immediately when traffic patterns change, the site adds a subdomain, email moves providers, the CMS or runtime changes, a CDN is introduced, or the application begins using queues, webhooks, scheduled jobs, or external APIs. These additions expand the migration surface and can be missed by a simple file-and-database copy.

For your next move, create a one-page runbook containing the inventory, backup location, DNS records, test URLs, owners, maintenance window, rollback trigger, and post-launch checks. Work through the runbook in order, record each result, and keep the old environment available until traffic, functionality, email, SSL, and SEO signals remain stable. That habit turns a risky hosting transfer into a repeatable website maintenance process.