How to Migrate a Website to New Hosting Without Losing Files, Email, or SEO

Overview

A hosting migration is more than copying a website folder. A typical site may include web files, a database, scheduled tasks, SSL settings, email mailboxes, DNS records, analytics, redirects, and third-party integrations. Missing one of these dependencies can create problems that are not immediately visible.

The safest approach is to separate the move into four stages:

1. Inventory: Record what exists before changing anything.
2. Build: Create and configure the site on the new host without changing public DNS.
3. Test: Check the copy using a temporary address or local hosts-file preview.
4. Cut over and verify: Point traffic to the new server, then monitor the old and new environments until the move is confirmed.

Keep the old hosting account active during the transition. Do not cancel it immediately after the new site appears to work. Visitors, mail servers, and DNS resolvers may not all switch at the same time, and a final backup may be needed if the old site receives new orders, comments, registrations, or other data during the change.

Before starting, confirm that the new plan supports your application. Compare PHP versions, database type and version, storage limits, inode or file-count limits, cron jobs, server access, SSL certificate setup, email features, and required extensions. Hosting-panel labels vary: one provider may call a feature “Domains,” while another uses “Websites,” “Sites,” or “Virtual Hosts.”

Checklist by scenario

For any website

• Record the domain registrar, DNS provider, current nameservers, and DNS records.
• List every domain and subdomain, including www, staging, shop, blog, and API addresses.
• Export or download a complete backup of website files and databases.
• Record email addresses, aliases, forwarding rules, autoresponders, and mailbox storage requirements.
• Make a list of external services: payment processors, email marketing, analytics, security tools, webhooks, CDN settings, and API integrations.
• Capture the current PHP, database, CMS, plugin, and theme versions where applicable.
• Record important scheduled tasks, server-side scripts, environment variables, and file permissions.
• Check that you can access both the hosting account and the domain or DNS account before beginning.

For a WordPress site

1. Put the site into maintenance mode only if necessary. A complete offline period is often avoidable when the new copy is prepared before DNS changes.
2. Back up the wp-content directory, configuration file, and database. The database contains posts, pages, settings, users, and other important content.
3. Copy the entire WordPress installation, including hidden files such as .htaccess when relevant.
4. Create a database and user on the new host, then import the database using the provider’s database tool or a command-line method.
5. Update the new configuration with the database name, username, password, host value, and table prefix required by the new environment.
6. Check site URLs, permalink settings, media files, plugin licenses, caching, and security settings before launch.
7. Disable or pause background jobs that could create conflicting data while testing, then re-enable them after the cutover.

A managed WordPress migration tool may automate some of these steps, but do not assume it handles email, DNS, custom cron jobs, external databases, or unusual server rules. Read the tool’s scope and retain your own backup.

For a static site or developer project

• Copy the production build rather than an unfinished source directory, unless the new host is intended to build the project.
• Confirm the required runtime, build command, environment variables, redirects, and output directory.
• Check case-sensitive paths, asset URLs, form endpoints, serverless functions, and any API origin restrictions.
• Recreate deployment hooks and confirm that the new host serves the correct index file for nested routes.

For email hosted with the old provider

Decide whether email will remain where it is or move with the website. If it remains, preserve the existing mail-related DNS records and change only the web records. If it moves, create mailboxes before changing MX records, copy messages where possible, and document passwords or account setup requirements. Review SPF, DKIM, and DMARC after the change; the reference guide on SPF, DKIM, and DMARC setup can help organize that review.

What to double-check before and after DNS cutover

Build the new site completely before changing the domain’s public DNS. Many hosts provide a temporary URL, preview URL, staging address, or server IP. If none is available, a local hosts-file entry can let you test the domain against the new IP from one computer without changing public DNS. Remove that temporary entry after testing.

Review DNS records individually rather than replacing the entire zone without checking it. Common records include:

• A or AAAA records: Point the domain or subdomain to the new server where appropriate.
• CNAME records: Preserve aliases and third-party services that still need to receive traffic.
• MX records: Keep or change mail delivery deliberately; an incorrect change can interrupt email.
• TXT records: Preserve verification, SPF, and other service records.
• CAA records: Check them if they restrict which certificate authorities may issue certificates.

Lowering DNS TTL before a migration may help some resolvers refresh sooner, but it does not provide an exact switching time. Resolver behavior and provider controls vary. Plan for a period in which some visitors may still reach the old server.

After DNS changes, continue checking both hosts. If the site accepts user-generated data, perform a final database or content sync after the last meaningful write to the old server. Keep a dated migration log with DNS changes, tests, errors, and the time each issue was resolved.

Common mistakes

• Canceling the old host too early: Keep it available until traffic, mail, and data have been verified from the new environment.
• Copying files but not the database: This produces an older or incomplete version of a content-managed site.
• Changing nameservers without documenting the zone: Mail, verification records, and subdomains can disappear if they are not recreated.
• Testing only the homepage: Broken internal links, forms, redirects, checkout steps, and admin screens may remain hidden.
• Forgetting server compatibility: A different PHP version, missing extension, database setting, or rewrite rule can cause errors after launch.
• Leaving staging controls enabled: Remove temporary passwords, noindex directives, debug mode, and hosts-file entries from production.
• Ignoring email authentication: Web hosting and email hosting can be separate systems. Verify mail records instead of assuming they moved with the site.
• Overlooking SEO settings: Check canonical URLs, redirects, XML sitemaps, robots.txt, structured data, and analytics tags. A migration should preserve URL paths whenever possible.
• Relying on one backup: Keep at least one independently stored copy and confirm that it can be opened or restored. See the website backup and restore guide for a repeatable process.

When to revisit

Use this checklist before every hosting change, not only during an emergency. Revisit it before a renewal decision, a major redesign, a domain transfer, a platform upgrade, or a move from shared hosting to VPS or cloud hosting. It is also useful before seasonal traffic periods, when a site may need different resource limits or stronger monitoring.

Update your inventory whenever you add a subdomain, mailbox, payment integration, scheduled task, plugin, database, or third-party service. Hosting dashboards and migration tools change their labels and capabilities, so confirm the current instructions in your provider’s documentation before following an older procedure. For ongoing checks, pair the migration log with uptime monitoring and resource tracking using the guides to website uptime and hosting resource usage.

Final action plan: make a complete inventory, create and test the new copy, document DNS and email records, schedule the cutover, run the verification table, and keep the old host until the site and mail have remained stable. A careful, staged move is usually more reliable than trying to complete every change at once.