Website Migration Checklist: Move Hosting Providers Without Breaking SEO or Email

Overview

A website migration can mean several different things: moving files and databases to a new server, changing only DNS, switching email providers, transferring the domain registration, or all of them at once. Problems usually happen when those tasks are bundled together without a sequence.

The safest approach is to separate the migration into layers:

• Hosting layer: application files, database, media, server configuration, cron jobs, environment variables, caching, and SSL.
• DNS layer: A records, CNAME records, MX records, TXT records, nameserver changes, TTL settings, and any CDN or proxy settings.
• SEO layer: URL structure, redirects, canonicals, sitemaps, robots.txt, structured data, and search console verification.
• Email layer: mailboxes, aliases, forwarding rules, SPF, DKIM, DMARC, webmail access, and mail client settings.

If you treat each layer as a separate checklist, the move becomes much easier to validate. That is especially useful for SMBs and creators who need to buy domain and hosting, update a site, and keep operations simple without losing contact form messages or search traffic.

Before you start, define the exact type of migration:

• Same domain, new hosting provider
• Same hosting provider, new domain
• Same domain and site, but new DNS hosting service or managed DNS provider
• Site migration plus mailbox migration
• Site migration plus domain transfer to a new registrar

Do not transfer everything on the same day unless there is a strong reason. In many cases, keeping domain registration, DNS, hosting, and email changes staged across separate windows reduces risk. If your move also includes a registrar change, it helps to review a dedicated domain transfer checklist before you begin.

One more practical rule: lower DNS TTL values in advance if you can. That gives you more flexibility during cutover. If you need a refresher on timing, see DNS Propagation Explained: How Long It Takes and How to Check It.

Checklist by scenario

Use the scenario that matches your move. If your migration includes several changes, complete the shared checklist first, then the relevant scenario-specific items.

Universal pre-migration checklist

• Inventory the current setup: hosting account, registrar, DNS provider, CDN, SSL source, email host, forms, payment tools, analytics, search tools, and any third-party integrations.
• Export or document all DNS records before changing anything: A, AAAA, CNAME, MX, TXT, SRV, and verification records.
• Take full backups of site files, database, media uploads, and any configuration files.
• Record software versions and dependencies: PHP or runtime version, database version, extensions, framework requirements, cron jobs, and scheduled tasks.
• Create a staging or temporary URL on the new host and test the site there before cutover.
• List all critical URLs: homepage, product or service pages, lead forms, login pages, checkout flows, thank-you pages, and top organic landing pages.
• Capture baseline data: indexed pages, top-ranking URLs, current page speed pattern, form submissions, and email delivery behavior.
• Reduce TTL on key DNS records ahead of the planned move if your current provider allows it.
• Plan a rollback path: old host still active, backup ready, and previous DNS values documented.

Scenario 1: Move website to new host, keep the same domain and email provider

This is the most common website migration checklist for small business sites and WordPress projects.

• Set up the new hosting environment to match application requirements.
• Copy files and import the database.
• Update configuration values such as database credentials, environment variables, writable directories, and cache settings.
• Install or prepare SSL on the new host.
• Test the site on a staging domain or by editing your local hosts file.
• Verify forms, transactional emails, logins, search, uploads, checkout, and any member-only areas.
• Confirm canonical tags, meta robots, robots.txt, and sitemap output.
• At cutover, update only the records needed to point the website to the new server.
• Leave MX records untouched if email is staying where it is.
• Monitor logs, uptime, response errors, and form submissions immediately after the switch.

If you are deciding between hosting models before migrating, these comparisons may help: Shared Hosting vs Cloud Hosting for Small Business and Best Cloud Hosting for WordPress.

Scenario 2: Hosting migration without downtime for WordPress

WordPress adds a few familiar failure points: serialized URLs, plugin caching, image paths, and plugin-specific settings.

• Put a content freeze in place for the migration window if possible, especially on high-activity sites.
• Export both files and database, including uploads and custom directories.
• Check permalink structure on the new host.
• Clear and rebuild caches after migration: page cache, object cache, CDN cache, and any plugin cache.
• Search for hard-coded URLs in theme settings, widgets, page builders, and custom code.
• Verify XML sitemap generation and robots settings.
• Test plugins that call third-party services, including forms, SMTP, memberships, ecommerce, booking tools, and analytics tags.
• Re-save permalinks if needed, but do not change URL structure unless that is part of a planned SEO migration.

Scenario 3: Website migration SEO checklist when URLs change

If the migration includes a redesign, platform change, folder changes, or a move from one domain to another, SEO risk increases. The key is preserving URL intent and redirect logic.

• Export a list of existing live URLs, especially top-performing pages.
• Map every important old URL to the best new destination on a one-to-one basis where possible.
• Avoid redirecting many pages to the homepage. That weakens continuity for users and search engines.
• Implement 301 redirects for permanent moves.
• Update internal links so they point directly to final URLs rather than relying on redirects.
• Update canonical tags to reflect new destinations.
• Generate and submit a current XML sitemap.
• Keep search console and analytics access active before and after migration.
• Check robots.txt carefully so staging blocks do not accidentally reach production.
• Monitor crawl errors, soft 404s, redirect chains, and indexed page count after launch.

Scenario 4: Email migration checklist

Email is often the most sensitive part of a hosting move because a website can tolerate a short issue window more easily than a missed sales inquiry or support message.

• Identify where email currently lives: same host as the site, separate hosted email provider, or an external mail server.
• Document all mailboxes, aliases, groups, forwarders, autoresponders, and shared inboxes.
• Export or sync mailbox data if mail is moving to a new provider.
• Record current MX, SPF, DKIM, and DMARC records.
• Plan client updates for desktop and mobile mail apps if server names or credentials change.
• Preserve old mailbox access during the transition period if possible.
• Lower TTL on MX records before cutover when feasible.
• Test sending and receiving from internal and external accounts after the switch.
• Check spam authentication alignment if SPF or DKIM changed.
• Verify website forms still send to the correct inbox and do not silently fail.

If you need help understanding how to point a domain to hosting without disturbing mail, review How to Point a Domain to Your Hosting Provider. Many migration problems come from replacing all DNS records when only the web records needed updating.

Scenario 5: Move DNS to a new provider or managed DNS platform

Changing DNS hosting is separate from changing web hosting. It can improve control and resilience, but only if records are copied accurately.

• Export the full zone file from the current provider if possible.
• Recreate every active record at the new DNS provider.
• Double-check MX, SPF, DKIM, domain verification, and service-specific TXT records.
• Review TTL values and routing settings.
• Enable DNSSEC only after confirming provider support and a correct setup path.
• Validate records before changing nameservers.
• Monitor propagation and service behavior after cutover.

If you are evaluating options for managed DNS, see Best Managed DNS Providers: Speed, Failover, DNSSEC, and Pricing Compared.

What to double-check

These are the items most likely to be missed during a migration, even on well-run projects.

DNS records beyond the website

Teams often remember the A record and forget the rest. Double-check:

• MX records for inbound mail
• SPF, DKIM, and DMARC TXT records
• Verification records for search tools, email tools, and SaaS platforms
• Subdomains such as blog, shop, app, staging, or help center
• CDN, proxy, or firewall-related records

SSL and mixed content

Confirm the certificate is active on the new host and that all site resources load over HTTPS. Mixed content warnings can break trust and also interfere with scripts, forms, or analytics.

Redirect behavior

Test with and without www, with HTTP and HTTPS, and on key old URLs. The desired outcome is usually one clean redirect path to the final canonical version, not several hops.

Forms and transactional messages

Submit every important form after cutover. Contact forms, quote requests, account emails, password resets, and ecommerce notifications are all easy to overlook. A site can appear healthy while leads quietly disappear.

Performance and caching

A new host may be faster, but it can also behave differently. Check cache headers, image optimization, CDN routing, compression, and page generation behavior. If you are comparing providers before moving, a practical resource is Web Hosting Pricing Comparison: Intro Rates vs Renewal Rates Across Popular Hosts, especially if predictable long-term cost matters as much as raw speed.

Search and analytics continuity

Verify analytics tracking, search console ownership, sitemap access, and conversion events. Migration success should be measured, not assumed.

Backups on the new host

Do not assume backups are active just because the new environment is live. Confirm retention, restore method, and whether backups cover both files and databases.

Common mistakes

Most migration issues are procedural rather than technical. These are the mistakes worth watching for every time.

• Changing hosting, DNS, registrar, and email all at once. A staged move is easier to test and easier to reverse.
• Skipping a record inventory. Rebuilding DNS from memory is how mail and third-party services get lost.
• Not testing on the destination first. Production should not be the first complete test environment.
• Leaving a staging noindex or password rule in production. This is a common cause of sudden traffic drops after launch.
• Replacing one URL structure with another without redirect mapping. This is where SEO damage usually starts.
• Forgetting cron jobs, scheduled tasks, and background workers. Sites may load normally while automations fail in the background.
• Assuming email will keep working because the website does. Website routing and mail routing are separate.
• Canceling the old host too early. Keep it available until DNS settles, logs are reviewed, and data consistency is confirmed.
• Ignoring renewal and transfer details. If your move includes registrar changes, check renewal timing and transfer locks before acting. Helpful reading: Domain Name Renewal Costs by Registrar and Best Domain Registrars for Small Business Websites.

One final mistake is treating migrations as one-off emergencies instead of repeatable operations. The more standardized your checklist becomes, the less likely you are to miss a small but expensive detail.

When to revisit

This checklist is most useful when it is maintained, not just read once. Revisit and update it in these situations:

• Before seasonal planning cycles: if you expect traffic spikes, product launches, campaigns, or holiday demand, validate your hosting, DNS, and rollback process before making changes.
• When workflows or tools change: new email provider, new CDN, new form platform, new analytics setup, or a new deployment process all change migration risk.
• Before a redesign or CMS change: URL structures, templates, redirects, and media handling often shift during a redesign.
• When your hosting model changes: for example, moving from shared hosting to cloud web hosting, or from unmanaged infrastructure to a more managed platform.
• When adding new subdomains or services: support portals, regional sites, staging, app endpoints, and email authentication changes should be reflected in your DNS and migration notes.

A practical way to keep this useful is to turn it into a living runbook:

1. Create a master checklist for all migrations.
2. Keep a current DNS record export with each domain.
3. Maintain a short list of critical pages, forms, and user journeys to test after launch.
4. Store rollback instructions with account access details in a secure internal location.
5. After each migration, add one or two lessons learned so the checklist improves over time.

If you are preparing an upcoming move, start with the simplest sequence: choose the new host, build and test the destination, lower TTL where possible, migrate content, switch only necessary DNS records, verify forms and email, then monitor. That order will not remove all risk, but it will make your next website migration more predictable and much easier to manage.