Website Migration Checklist: Move Hosts Without Losing Traffic, Email, or Files

Overview

This article gives you a practical website migration checklist you can return to each time you move website hosting. The goal is simple: complete a host migration checklist that protects files, databases, traffic, forms, SSL, and email while reducing downtime.

Before starting, separate three different tasks that are often confused:

• Hosting migration: moving site files, databases, and application settings to a new server.
• DNS change: pointing the domain to the new host by updating nameservers or DNS records.
• Domain transfer: moving the domain registration itself to a new registrar, which is a separate process.

Not every site move requires all three. In many cases, the safest path is to move the site first, test it on the new host, then update DNS later. If you also plan to move the domain registration, treat that as its own project and timeline. For related steps, see Domain Transfer Checklist: How to Move Your Domain Without Downtime and How to Change Nameservers Safely Without Breaking Your Website or Email.

A reliable migration usually follows this sequence:

1. Audit the current site and services tied to the domain.
2. Prepare backups and access credentials.
3. Build the destination environment.
4. Copy files, databases, media, and settings.
5. Test the new host before going live.
6. Update DNS carefully.
7. Monitor uptime, traffic, forms, email, and errors.

If you remember one principle, make it this: do not cancel the old host until the new site is live, tested, and stable. Keeping both environments active during the cutover gives you room to fix unexpected issues without pressure.

Checklist by scenario

Use the list below as your core host migration checklist, then apply the scenario notes that match your setup.

Universal pre-migration checklist

• List every service connected to the site: web hosting, DNS host, registrar, CDN, SSL, email hosting, transactional email, analytics, backups, staging, and firewall or security tools.
• Record current logins and access methods: hosting panel, SFTP, SSH, database access, CMS admin, DNS provider, domain registrar, CDN account, and email provider.
• Export a full backup of site files and at least one separate database backup.
• Save a copy of DNS records, including A, AAAA, CNAME, MX, TXT, SPF, DKIM, and subdomain records.
• Document the current PHP version, server software, cron jobs, redirects, SSL status, caching rules, and custom configuration files.
• Check disk usage and database size so the destination plan can handle the site comfortably.
• Lower DNS TTL in advance if your DNS provider allows it and if you expect to switch records soon.
• Pause major site changes during the migration window, especially plugin installs, theme edits, or content imports.
• Set a migration window when traffic is usually lighter.
• Keep the old hosting account active until after testing and monitoring are complete.

Scenario 1: Moving a standard WordPress site

This is the most common case for people searching for how to move a website to a new host. WordPress migrations are straightforward when the sequence is controlled.

• Check WordPress core, theme, and plugin versions before moving.
• Remove unused plugins, themes, and old backups that add bulk or confusion.
• Export the database and copy the wp-content directory carefully, including uploads.
• Confirm the new host supports the required PHP version, memory limits, and database version.
• Update wp-config.php with the new database name, user, password, and host if needed.
• Search for hard-coded URLs in the database or theme settings if the temporary staging domain differs from the final domain.
• Re-save permalinks after launch if pages return 404 errors.
• Test forms, media uploads, caching, image optimization, backups, and security plugins.

If you are building or rechecking a new install during the move, WordPress Setup Checklist for New Websites: From Hosting to Launch is a useful companion.

Scenario 2: Moving a custom PHP site or CMS

• Compare PHP extensions and server modules between old and new environments.
• Copy environment variables, config files, and secret keys securely.
• Review file permissions after upload.
• Test scheduled tasks, contact forms, session handling, file upload paths, and image processing.
• Check custom redirects and rewrite rules in server configuration files.
• Verify dependency versions if the project uses Composer, Node, or build tools.

Scenario 3: Moving an ecommerce site

Ecommerce migrations need a tighter launch window because orders, inventory, customer accounts, and transactional emails change frequently.

• Put order handling at the center of the plan.
• Avoid a long content freeze if orders are still coming in; instead, choose a short cutover window.
• Back up the database immediately before final sync.
• Test checkout, tax and shipping logic, payment gateway callbacks, transactional email, login, password resets, and order notifications.
• Verify SSL and mixed-content issues before switching traffic.
• Check robots directives so staging does not get indexed and live pages are not blocked.

Scenario 4: Site move with email on the same domain

This is where many migrations go wrong. A site may load fine after DNS changes while business email silently stops working.

• Identify whether email is hosted with the current web host, a separate email provider, or a productivity suite.
• Export or back up mailboxes if they are tied to the old host.
• Copy MX, SPF, DKIM, and any other email-related DNS records exactly unless you intend to change email providers.
• Do not replace DNS records blindly when pointing the website to the new host.
• Send and receive test messages after cutover using multiple addresses.

Scenario 5: Moving to a host with a different control panel

• Map old tools to new ones before migration: file manager, databases, SSL, email, cron, redirects, backups, and DNS.
• Expect menu names and workflows to differ even when the underlying tasks are the same.
• If you are moving away from a familiar interface, compare workflows ahead of time so nothing is overlooked. Best cPanel Alternatives for Website Owners and Developers can help frame those differences.

Launch checklist for all scenarios

• Preview the site on the new host before updating DNS using a hosts file, temporary URL, or staging method.
• Confirm the homepage, top landing pages, blog posts, forms, scripts, CSS, images, and downloads all work.
• Install or validate SSL on the new host before sending live traffic there.
• Update DNS only after testing passes.
• Watch for propagation issues and keep the old host online during the transition.
• After cutover, crawl key pages and review analytics, Search Console, server logs, and uptime checks.

What to double-check

This is the section to review slowly. These are the details most likely to cause hidden damage after an otherwise successful site transfer without downtime.

DNS records

Do not assume the new host will recreate every DNS record automatically. Check:

• Root domain and www records
• Subdomains such as blog, shop, app, or staging
• MX records for email routing
• TXT records for SPF, DKIM, domain verification, and third-party services
• CNAME records for CDN or SaaS tools

If you need a safer walkthrough, use How to Change Nameservers Safely Without Breaking Your Website or Email.

SSL and HTTPS behavior

• Confirm the certificate is active for both the root domain and www version.
• Force HTTPS only after the certificate is valid.
• Test for mixed-content warnings on pages with images, scripts, fonts, or embedded media.
• Recheck redirects from HTTP to HTTPS and from non-preferred to preferred hostnames.

For follow-up troubleshooting, see How to Set Up SSL on Your Website and Fix Common HTTPS Errors.

Database connections and dynamic features

• Log in and out of the site.
• Submit every important form.
• Test search, filters, comments, carts, checkout, and account areas.
• Review error logs for connection issues, missing tables, or permission problems.

Redirects and canonical signals

Preserve URL structure whenever possible. If URLs must change, add 301 redirects deliberately and verify canonicals on key pages. Traffic loss often comes not from the host move itself but from accidental URL changes, broken redirects, or noindex tags left in place.

Performance and caching

• Check that server-side caching, CDN settings, and compression are working as intended.
• Clear old cache layers after launch.
• Compare page speed and uptime before and after migration.

For monitoring, Best Website Speed Test Tools for Monitoring Core Web Vitals and Uptime is a practical next step.

Backups and rollback readiness

• Confirm backups on the new host are actually running.
• Keep the old environment intact until the new one is stable.
• Know how to restore both files and databases if the launch needs to be reversed.

Common mistakes

If you want to move website hosting smoothly, avoid these predictable errors.

Changing too many variables at once

Moving hosts, changing DNS, redesigning the site, switching themes, replacing plugins, and transferring the domain at the same time makes troubleshooting harder. Stage major changes separately whenever possible.

Forgetting email records

This is one of the costliest mistakes for small businesses. The website may look fine while email delivery fails because MX or TXT records were overwritten.

Cancelling the old host too early

Do not close the previous account on launch day. Keep it active until traffic, files, forms, and email are confirmed stable over a reasonable monitoring period.

Testing only the homepage

A migration can appear successful while deeper pages, media files, forms, or admin functions fail. Test representative pages from each template and workflow.

Ignoring noindex, robots, or staging protections

Staging controls are useful before launch, but harmful if they remain in place afterward. Check search engine visibility settings, robots directives, and any password protection on the live site.

Skipping a content freeze or final sync

If content, orders, or user data continue changing on the old host after the initial copy, the new server may go live with stale information. Plan a final sync close to cutover.

Not documenting the original setup

When a site uses custom cron jobs, rewrite rules, third-party integrations, or special DNS records, undocumented details are the first things to disappear in a move.

If your next step is choosing infrastructure before migrating, broader planning resources such as How to Start a Website on a Budget: Domain, Hosting, and Builder Costs Explained can help frame tradeoffs around hosting, builder, and domain decisions.

When to revisit

This checklist is most useful when treated as a living process, not a one-time read. Revisit it whenever the underlying tools, hosting model, or risk level changes.

• Before renewing or switching hosts: review what is currently tied to your hosting account, especially backups, email, SSL, and DNS.
• Before seasonal campaigns or peak sales periods: avoid rushed migrations when traffic is sensitive.
• When changing panels, stacks, or workflows: moving from shared hosting to VPS, cloud, or managed WordPress often changes where settings live.
• When adding ecommerce, memberships, or critical forms: more dynamic features mean more launch checks.
• When DNS or email providers change: repeat your record audit before touching nameservers.
• After major plugin, theme, or application updates: compatibility can shift between the old and new hosting environments.

For the next migration, save a copy of your own finalized checklist with account locations, DNS records, required software versions, cron jobs, and test pages. That turns this general website migration checklist into a site-specific runbook you can reuse.

Action plan:

1. Create a migration document with every service tied to your domain.
2. Back up files, databases, DNS records, and mail settings.
3. Build and test the new host before any DNS changes.
4. Cut over during a low-risk window.
5. Monitor speed, forms, SSL, email, and rankings after launch.
6. Only then retire the old hosting account.

If your workflow includes staging before launch, Best Staging Tools for WordPress Sites: Safe Ways to Test Changes Before Going Live is a useful companion resource. Used together, staging and a careful cutover plan make site transfer without downtime much more realistic.