Website Migration Checklist: Move Hosting Providers With Minimal Downtime

Overview

If you only remember one idea, make it this: a safe migration is mostly preparation. The actual move often takes less time than the planning around backups, DNS, SSL, email, and testing. Many migration problems happen because the website owner changes DNS too early, forgets about mail records, or assumes the new host copied everything correctly.

This checklist is meant to help you move a website to a new host with minimal interruption. It applies whether you are moving a small brochure site, a WordPress installation, a custom app, or a site backed by a database. It also helps when you need a website migration without downtime as much as possible, knowing that some short transition period may still happen depending on your DNS setup, caching, and application behavior.

Before you begin, separate these three layers clearly:

• Domain registrar: where your domain name is registered.
• DNS provider: where your records such as A, CNAME, MX, and TXT are managed.
• Hosting provider: where your website files, database, and application runtime live.

Those services may be with one company or split across several. Knowing which one you are changing is the first step in any good hosting migration guide.

It also helps to set a success definition before you touch anything. A successful migration usually means:

• The website loads correctly on the new host.
• HTTPS works without certificate errors.
• Forms, logins, carts, and dynamic pages work.
• Email still sends and receives for the domain.
• DNS records are complete and correct.
• You can roll back if something important fails.

If you need a refresher on DNS basics before the move, see DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS, and SRV. If your change also includes moving the registration itself, read How to Transfer a Domain Name Without Breaking Your Website or Email.

Checklist by scenario

Use the scenario that matches your move. In practice, many migrations combine more than one of these.

Scenario 1: Moving website hosting only, keeping the same domain registrar and DNS provider

This is often the safest path because you only change the web destination, not the entire DNS authority.

1. Inventory the current setup. Record your current host, IP addresses, nameservers, active DNS records, SSL method, cron jobs, redirects, databases, application versions, and any CDN or firewall settings.
2. Export or back up everything. Save website files, databases, media uploads, configuration files, and server-specific settings. Keep one local copy and, if possible, one offsite copy.
3. Lower DNS TTL in advance if appropriate. If you control your DNS, lowering the TTL for the records you plan to change can shorten the visible transition later. Do this well before the migration window rather than minutes before it.
4. Build the destination first. Create the new hosting account, provision the site, set the runtime version you need, and confirm storage, PHP or Node settings, database access, and file permissions.
5. Restore the site on the new host. Import files and databases. Update application config if database names, users, paths, or environment variables changed.
6. Test the site before DNS changes. Use a temporary URL, a hosts file override, or another safe preview method provided by the host. Confirm page rendering, admin login, assets, internal links, APIs, and forms.
7. Install or prepare SSL. Make sure the new host can issue or import the certificate you need after cutover. If you use a proxy or CDN, plan that sequence too.
8. Update only the required DNS records. Usually that means changing the A record, AAAA record, or CNAME that points web traffic to the new host.
9. Monitor both hosts during propagation. Keep the old hosting active until traffic has clearly shifted and the new environment is stable.
10. Run post-migration checks. Review logs, uptime, error reporting, and real user flows before cancelling the old service.

Scenario 2: Moving hosting and DNS to a new provider

This adds risk because you are changing the website destination and the DNS control plane.

1. Export the full DNS zone. Save every record from the current provider, including records unrelated to the website such as MX, SPF, DKIM, DMARC, verification TXT records, subdomains, and third-party service records.
2. Recreate the DNS zone at the new DNS provider before switching nameservers. Do not rely on memory. A missing TXT or MX record can break email or external services.
3. Verify record values and TTLs. Pay special attention to root domain records, www, mail subdomains, and any wildcard entries.
4. Set up the website on the new host and test privately. Validate the same items you would in a hosting-only migration.
5. Switch nameservers only after the new DNS zone is complete. This is one of the most common failure points in a website migration checklist.
6. Check propagation from multiple locations. A DNS propagation checker can help you confirm that nameserver and record changes are visible more broadly. For more context, read DNS Propagation Time Guide: How Long Changes Take and How to Check.
7. Confirm web and email separately. Website success does not guarantee email success. Test both.
8. Keep the old DNS and hosting available temporarily. Do not cancel either immediately after the switch.

Scenario 3: Moving a WordPress site

WordPress adds its own set of details, especially around plugins, caching, and serialized data.

1. Update WordPress core, themes, and plugins if it is safe to do so before the move. If the site is fragile, document versions instead and avoid unnecessary change during the migration window.
2. Back up files and database together. You need both for a complete restore.
3. Check PHP version and extensions on the new host. Mismatch issues are common when you change hosting providers.
4. Review caching and security plugins. Some plugins store absolute paths, generated cache files, or host-specific rules that need to be cleared or regenerated.
5. Search for hard-coded URLs. If the domain stays the same, this is less painful, but staging environments and temporary preview URLs can still create mixed content or redirect loops.
6. Re-save permalinks if needed. This can resolve rewrite-related issues after restore.
7. Test forms, e-commerce checkout, media uploads, and admin actions. Public pages may look fine while important workflows fail quietly.

If you are still choosing a destination, compare options in Best Web Hosting for Beginners Compared and Shared Hosting vs VPS vs Cloud Hosting: Which One Should You Choose?.

Scenario 4: Moving a static site or website builder connection

These moves are often simpler, but DNS mistakes can still cause downtime.

1. Confirm what the new platform requires. Some builders want nameserver changes, while others ask you to point specific A records or a CNAME.
2. Do not delete old records until you understand the new model. Builder documentation varies, and replacing the wrong record can affect mail or subdomains.
3. Test redirects, canonical URLs, and HTTPS. Static sites are light, but domain setup still matters.
4. Verify custom domain status in the platform dashboard. Many platforms show pending verification, certificate issuance, or DNS mismatch messages that are easy to overlook.

For domain pointing patterns, see How to Point a Domain to Your Hosting Provider, Website Builder, or Server.

Scenario 5: Migrating a site that uses custom domain email

This is where many otherwise successful migrations go wrong. Website DNS changes and mail DNS changes often live in the same zone, so a hosting change can accidentally interrupt email.

1. Identify the current email provider. It may not be your web host.
2. Preserve MX records exactly unless you are also moving email. A web migration does not usually require changing MX records.
3. Preserve TXT records for SPF, DKIM, and DMARC. Missing authentication records can affect mail delivery and trust.
4. Check autodiscover or provider-specific CNAME records. Mail clients and service integrations may rely on them.
5. Send and receive test messages after cutover. Test from an external mailbox, not just internally.

If you also need to review mail setup, read How to Set Up MX, SPF, DKIM, and DMARC for a Custom Domain Email and Best Email Hosting for Custom Domains Compared.

What to double-check

Once the move is live, this is the part to slow down and verify carefully. A site can appear online while still having hidden issues.

• DNS records: Confirm A, AAAA, CNAME, MX, TXT, and any special subdomain records. If you are unsure how records differ, review DNS Records Explained.
• Nameservers vs DNS records: Know whether you changed authoritative nameservers or only edited individual records. This distinction matters when troubleshooting.
• HTTPS and SSL: Check certificate issuance, redirect behavior, mixed content warnings, and whether both apex and www variants work as intended.
• Canonical domain redirects: Confirm that only one preferred version of the site resolves as primary.
• Application config: Database credentials, environment variables, file paths, salts, API keys, and cache backends should match the new environment.
• Email continuity: Send test mail, receive test mail, and verify authentication records remain intact.
• Background jobs: Cron tasks, scheduled jobs, queue workers, and webhooks may not migrate automatically.
• Forms and transactional messages: Contact forms, password reset emails, order confirmations, and notification emails should all be tested.
• Performance: Compare load times before and after. A move that improves cost but worsens response time may not be a real upgrade.
• Security settings: Firewalls, WAF rules, malware scanning, backups, file permissions, and login protections should be enabled on the new host.
• Backups on the new host: Confirm they actually run and that restore options exist. Do not assume backup is included just because a dashboard mentions it.
• Renewal terms: Before you settle in, review how the new host handles long-term billing. Intro pricing is not the same as steady-state cost. See Web Hosting Renewal Pricing Guide: What Cheap Plans Really Cost After Year One.

A practical way to manage this stage is to create a short validation sheet with three columns: item, expected result, and actual result. That gives you a clean punch list instead of relying on memory.

Common mistakes

Most migration failures are not dramatic technical disasters. They are simple omissions. These are the ones that show up repeatedly.

• Cancelling the old host too early. Keep the old account active until traffic, logs, and user reports all suggest the new environment is stable.
• Forgetting email records. A missing MX or DKIM entry can cause more damage than a brief website issue, especially for business domains.
• Changing nameservers without copying the full DNS zone. This can break subdomains, verification records, and third-party integrations.
• Testing only the homepage. A migration is not complete until the important paths work: login, checkout, search, forms, admin, media, and API endpoints.
• Skipping backups because the host offers a migration tool. Automatic tools are useful, but they should not be your only copy.
• Ignoring TTL and propagation timing. Even a correct DNS change can look inconsistent for a while from different networks.
• Moving too many things at once. Changing host, registrar, DNS provider, email provider, and CDN in one window makes troubleshooting much harder.
• Not documenting the original state. Rollback gets much easier when you have the previous records, screenshots, and configuration notes.
• Overlooking IPv6. If you had an AAAA record before, verify whether the new host supports it. If not, adjust intentionally rather than leaving stale values behind.
• Forgetting external dependencies. Payment gateways, SSO, webhook targets, license servers, and IP allowlists may all need updates.

If you are still early in your project and have not registered the domain yet, How to Buy a Domain Name: Beginner Checklist Before You Register is a useful companion read.

When to revisit

This checklist is worth revisiting any time your infrastructure or workflows change, not only during a full migration. Keep it handy for these moments:

• Before seasonal traffic periods or launches. Migrations close to peak usage deserve extra caution and a stronger rollback plan.
• When you switch DNS providers, CDN settings, or proxy services. Even if hosting stays the same, the risk profile changes.
• When you move from shared hosting to VPS or cloud hosting. More control usually means more responsibility for security, backups, and runtime setup.
• When your application stack changes. New framework versions, different PHP releases, containerization, or build pipeline changes can affect migration steps.
• When you add custom email or third-party integrations. DNS grows more complex over time, so old assumptions stop being safe.
• When you prepare a registrar transfer. Domain transfer and hosting migration are separate operations, but many site owners end up planning them together.

For a practical action plan, do this before your next move:

1. Create a migration document with current DNS records, hosting details, SSL method, and application dependencies.
2. Decide whether the migration changes hosting only, DNS only, or both.
3. List the user journeys you will test after cutover.
4. Back up everything and verify that the backup can be restored.
5. Prepare the new environment before any public DNS change.
6. Schedule the cutover during a lower-risk window.
7. Keep the old service live until you have finished verification.

A reliable migration is rarely about speed. It is about reducing unknowns. If you treat every move as a controlled launch instead of a quick switch, you will prevent most avoidable downtime and give yourself a much better chance of a clean, uneventful cutover.