How to Migrate a Website to a New Host Without Losing Traffic or Email
Moving a website to a new host is manageable when you treat it as a controlled handover rather than a single switch. This website migration guide explains how to back up files and databases, build and test the new environment, protect email, time the DNS change, verify SSL and redirects, and monitor traffic after the move.
Overview
Changing web hosting does not normally require changing your domain name. Your domain can remain with the same registrar while its DNS records point visitors to the new hosting account. That separation is useful: it lets you migrate the site first and change the destination only after the replacement is ready.
The safest workflow has four broad phases:
- Prepare: choose the new host, record the current configuration, and create verified backups.
- Build: copy the website files and database to the new server, then test the site privately.
- Cut over: lower risk by planning the DNS change, preserving email records, and switching traffic during a quiet period.
- Verify and monitor: check pages, forms, analytics, search visibility, email, SSL, redirects, and server errors before cancelling the old account.
The exact controls vary by platform. A WordPress migration usually involves files, a database, configuration values, plugins, themes, and uploads. A static site may require only the published files. An ecommerce site or application can also need environment variables, scheduled jobs, payment integrations, webhooks, and a final database sync. If you are comparing replacement providers, use a structured web hosting comparison checklist rather than judging a plan only by its introductory offer.
Before starting, make a simple inventory of your domain, subdomains, DNS records, email accounts, databases, cron jobs, SSL certificates, analytics tools, redirects, and third-party integrations. This list becomes your migration checklist and helps prevent small but consequential omissions.
What to track
Backups and recovery points
Create at least one complete backup before touching the live site. For a typical WordPress installation, that means the website files and a database export. Keep a copy outside the current hosting account so a hosting failure or accidental deletion does not remove both the site and its backup. Record when the backup was made and confirm that the database file can be opened or restored in a test environment.
Do not rely on a backup that you have never tested. Save the current wp-config.php values or equivalent application settings securely, but do not publish passwords or private keys in a shared document.
Files, database, and configuration
Transfer the correct document root, including images, uploads, theme files, verification files, and any custom scripts. Import the database into the new host and update the application’s database name, username, password, and host value as required. WordPress users should check that the site URL settings, permalink structure, media library, and active theme are intact.
Review differences between the old and new server environments. PHP or database versions, file permissions, memory limits, rewrite rules, caching layers, and image-processing tools can affect how a site behaves. If the new host offers a staging address, use it for testing; otherwise, point a temporary subdomain or local hosts-file entry to the new server without changing public DNS.
DNS and email records
List every record currently used by the domain before changing anything. Common records include the website’s A or AAAA record, a CNAME for www, MX records for email, and TXT records used for SPF, domain verification, or other services. The DNS records guide explains the role of these record types and provides a useful reference before a cutover.
If email is hosted separately from the website, do not replace the domain’s MX records with the new host’s defaults unless you intentionally plan to move email too. Preserve the existing MX, SPF, DKIM, DMARC, and mail-related records where applicable. If email will move, treat it as a separate project: document mailboxes, aliases, forwarding rules, authentication records, and the final delivery test.
Traffic, SEO, and site functions
Record important URLs, especially pages that receive organic traffic, conversion forms, checkout paths, and frequently linked resources. Confirm that the new server preserves URL structure. If URLs must change, prepare permanent redirects before the DNS switch and map each old URL to its closest relevant destination rather than sending every page to the homepage.
Track a baseline for sessions, conversions, indexed landing pages, uptime alerts, and key response or loading checks. These values do not need to be perfect measurements; their purpose is to make unusual changes easier to spot after migration. For performance-related checks, the WordPress speed guide covers hosting, caching, images, and CDN considerations.
Cadence and checkpoints
Before the migration
- Choose a migration window that avoids a major campaign, product launch, or expected sales peak.
- Confirm the new hosting account supports the site’s CMS, application version, database, SSL, storage, and resource needs.
- Export files and the database, then verify the backup.
- Copy the site to the new host and create the required database and users.
- Document DNS records, email settings, redirects, analytics, integrations, and scheduled tasks.
- Check that the new server has a working SSL setup or a clear certificate installation path.
During the cutover
Lowering DNS time-to-live before the change may help some resolvers refresh the destination sooner, but it does not guarantee an immediate switch for every visitor. Make the DNS change only after the new copy is ready. Update the relevant A, AAAA, or CNAME record while leaving email records unchanged unless mail is part of the move.
For sites with frequent orders, comments, registrations, or form submissions, pause writes briefly or perform a final database export immediately before the switch. Otherwise, activity that reaches the old server after the initial copy may be missing from the new database. Keep the old host active while DNS changes propagate and while you complete verification.
Immediately after the change
Open the domain with and without www, test both HTTP and HTTPS, and inspect several representative page types. Submit a test form, log in, search the site, open media files, test checkout if relevant, and confirm that analytics records a visit. Check the browser certificate and look for mixed-content warnings.
Run a small set of redirects from your URL inventory. Confirm that canonical tags, robots directives, XML sitemaps, structured data, and verification tags remain correct. Review server logs and hosting error reports for missing files, database errors, PHP warnings, 404 responses, and unusual spikes in failed requests.
How to interpret changes
A short period of mixed DNS results can be normal after a cutover. Compare results from different networks or DNS-checking tools rather than assuming that one device represents every visitor. The important question is whether the new host is consistently serving the intended site and whether critical services remain available.
If traffic falls, first separate technical visibility from ordinary demand changes. Check whether the homepage and top landing pages return the correct status, whether redirects are looping, whether the site is blocked from crawling, and whether canonical or domain settings changed. Confirm that analytics tracking was not removed during the file or template transfer.
If email stops arriving, inspect MX records before changing mailbox settings. A website migration should not affect mail delivery when the domain’s mail records remain correct, but an accidental DNS replacement can. Test inbound and outbound messages from more than one address and verify that forwarding and aliases still work.
If the site is slower, compare the application configuration rather than assuming the provider alone is responsible. Check caching, database connections, image handling, plugins, external scripts, server location, and resource limits. For a small business site, also compare the new recurring cost and included services against your original budget using this web hosting cost guide.
When to revisit
Do not treat migration as complete the moment the homepage loads. Monitor the site closely for the first day, then review it again after several days when caches, scheduled tasks, search crawlers, and less frequently used forms have had time to run. Keep the old hosting account available until you have a verified backup on the new host and are satisfied that traffic, email, and business functions are stable.
Revisit this checklist monthly or quarterly as part of normal site operations. Confirm that backups still run, restoration instructions are current, SSL renewals are working, DNS records match your inventory, forms deliver successfully, and analytics is receiving data. Review it immediately before another host change, domain transfer, platform upgrade, redesign, or major marketing campaign.
For the final handover, record the new host’s login location, DNS provider, renewal dates, backup schedule, database details, SSL status, and support contacts in a secure operations document. Then update your wider website maintenance checklist. A well-documented migration is easier to troubleshoot, repeat, and reverse if the new environment does not meet expectations.
Practical next step: before requesting cancellation from the old host, complete one written verification pass: test the site, test email, review DNS, confirm analytics, inspect redirects, and create a fresh backup from the new server. That final checkpoint turns a risky hosting change into a controlled site-operations task.
