> ## Content Index
> Fetch the complete content index at: https://thecloud.market/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# DNS Migration Checklist Before Changing Web Hosts
- URL: https://thecloud.market/blog/dns-migration-checklist-before-changing-web-hosts/
- Published: 2026-09-28T06:32:29.000Z
- Updated: 2026-09-28T06:35:47.000Z
- Description: Use this DNS migration checklist to preserve website routing, business email, SSL, DNSSEC and rollback when moving to a new host.
- Author: INDUKURI JAYENDRA VARMA
- Tags: DNS, Website Migration, Email Security, SSL

**A DNS migration checklist protects website routing, business email, certificates and verification records when a website moves to a new host.** The safest approach is to change only the records required for the move, keep the old service available during validation, and retain a tested rollback path. As of 28 September 2026, The Cloud Market's free DNS health check is a read-only, point-in-time diagnostic that can record the public state before and after a cutover.

## What changed in this guide?

- **September 2026:** The guide now distinguishes a website-record change from a full nameserver migration.
- **September 2026:** TTL and DNSSEC guidance now depends on the existing configuration instead of prescribing one universal value.

## Do you need to move DNS when changing web hosts?

**A website move does not automatically require a nameserver change.** If the current DNS provider is reliable and the business wants to keep it, update only the website records that must point to the new host. This is usually the root A or AAAA record, the `www` CNAME or address record, and any application subdomains that are moving.

A nameserver migration is a broader change. It moves authority for the entire DNS zone to another provider, so every active record must exist at the new provider before delegation changes. A full zone move affects website routing, mail, domain verification, certificates and third-party services at the same time.

| Migration type            | What changes                                     | Primary risk                                                                   |
| ------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------ |
| Website records only      | Selected A, AAAA or CNAME records                | Visitors reach the wrong or unprepared server                                  |
| Full nameserver migration | Authoritative DNS provider and the complete zone | Missing records disrupt websites, email or verification services               |
| Registrar transfer only   | Domain registration management                   | DNS changes only if nameservers or DNSSEC data are altered during the transfer |

## Which DNS records belong in the migration inventory?

**A migration inventory should record each active hostname, record type, value, priority, TTL, purpose and service owner.** Export the existing zone when the provider supports it, but also create a readable inventory because an export does not explain which business service owns each record.

| Record        | Typical purpose                                    | Migration check                                                                       |
| ------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------- |
| A and AAAA    | IPv4 and IPv6 website or application endpoints     | Confirm the destination serves every hostname over both published protocols           |
| CNAME         | Aliases such as www, blog or provider verification | Keep third-party aliases unless the related service is also moving                    |
| MX            | Incoming business-email routing                    | Preserve values and priorities during a website-only migration                        |
| TXT           | SPF, DMARC, ownership and service verification     | Copy exact values and confirm which teams or providers still use them                 |
| DKIM records  | Public keys for mail signatures                    | Inventory known selectors from each mail provider; public discovery may be incomplete |
| CAA           | Certificate-authority restrictions                 | Confirm the destination's certificate authority is permitted                          |
| NS and SOA    | Zone authority and operational metadata            | Change only as part of a planned DNS-provider migration                               |
| DS and DNSKEY | DNSSEC chain of trust                              | Coordinate the new signing data with the DNS provider and registrar                   |

## What is the safe DNS migration sequence?

### 1\. Record the current public baseline

**Capture the public DNS state before making changes.** Export the zone, save record values and priorities, and run a [read-only DNS health check](https://thecloud.market/dns-health-check). The baseline helps distinguish an existing issue from one introduced during migration.

### 2\. Identify the records that will actually change

**Mark each record as change, preserve or investigate.** A website-only move should normally preserve MX, mail-authentication and third-party verification records. Do not delete an unfamiliar TXT or CNAME record until its owner and purpose are confirmed.

### 3\. Prepare and test the destination privately

**Test the destination before public DNS points to it.** Use a temporary hostname or a local hosts-file override to check pages, logins, forms, checkout, uploads, APIs and redirects. Confirm how the destination will issue and renew an SSL/TLS certificate for the production hostname.

### 4\. Lower TTL only where it helps

**Lower the TTL on records that will change at least one current TTL interval before cutover.** For example, a record currently cached for four hours should be lowered more than four hours before the planned change. A provider may impose minimum or automatic TTL values, and local caches can still make an update appear later than the published TTL.

### 5\. Complete the final application-data sync

**Synchronise changing data immediately before DNS cutover.** Stores, membership sites and applications may require tested replication or a short read-only window so orders, accounts, uploads and form submissions are not divided between old and new databases. The full application procedure is covered in [How to Migrate Hosting With Minimal Downtime](https://thecloud.market/blog/migrate-hosting-with-minimal-downtime/).

### 6\. Make one controlled DNS change

**Change either the required website records or the authoritative nameservers according to the approved plan.** Avoid changing hosting, mail routing, nameservers and registrar settings in one untracked action. Record the old and new values, the time of change, and the person responsible for rollback.

### 7\. Verify end-to-end service, not only DNS answers

**Confirm that the new DNS answer leads to a working business service.** Test the website, certificate, redirects, login, forms, checkout and webhooks. Send and receive mail if email-related records changed. Query more than one public resolver and compare the result with the intended configuration.

### 8\. Keep rollback available

**Keep the old host and the previous DNS values available through a defined observation window.** If a material issue cannot be fixed safely, restore the previous DNS value and verify service again. Do not cancel the old hosting account only because one resolver returns the new address.

## How do you protect business email during a website move?

**Preserve MX, SPF, DKIM and DMARC records when email is staying with its current provider.** A website move and an email move are separate projects unless the approved plan explicitly combines them. Copy mail records exactly during a nameserver migration, including MX priorities and long TXT values.

Do not assume that a public scan can discover every DKIM selector. Confirm active selectors in the mail provider's administration panel. Multiple SPF records for the same hostname are invalid; consolidate authorised senders carefully instead of copying conflicting policies.

## How should DNSSEC be handled during a nameserver migration?

**DNSSEC requires a provider-specific rollover plan because the parent-zone DS record must match the keys used by the authoritative DNS service.** A stale or mismatched DS record can make the domain fail validation for users behind validating resolvers.

Do not disable DNSSEC casually. Follow the documented migration process of the old DNS provider, new DNS provider and registrar. Record DS and DNSKEY state before the move, verify the intended chain after the change, and keep a rollback procedure for delegation and signing data.

## What should be verified after DNS cutover?

- The intended A, AAAA and CNAME answers appear from multiple resolvers.
- The production hostname serves a valid SSL/TLS certificate.
- HTTP-to-HTTPS and canonical-host redirects work correctly.
- Website login, forms, checkout, uploads and webhooks complete successfully.
- MX, SPF, known DKIM selectors and DMARC remain present when email did not move.
- DNSSEC validates when it is enabled.
- CAA permits the certificate authority used by the destination.
- The old environment remains available for the agreed rollback window.

## What can a DNS health check confirm during migration?

**A DNS health check can compare public evidence before and after a migration, including delegation, address records, mail routing, sender policy, certificate health, DNSSEC and CAA posture.** The Cloud Market diagnostic is read-only, requires no passwords or DNS tokens, and currently accepts three checks per rolling 24 hours.

A point-in-time check cannot prove that an application is healthy behind an IP address, discover every private or selector-based record, guarantee inbox placement, or guarantee that the configuration will remain unchanged. See [What Is a DNS Health Check and Why Does It Matter?](https://thecloud.market/blog/what-is-a-dns-health-check/) for the complete diagnostic scope.

## Frequently asked questions

### Does changing web hosts require changing nameservers?

No. You can keep the current DNS provider and change only the website records. Move nameservers only when changing the authoritative DNS provider is part of the plan.

### What TTL should be used before migration?

Use a value supported by the DNS provider and lower it at least one existing TTL interval before cutover. There is no universal value that guarantees every cache will refresh at the same time.

### Will changing an A record affect email?

An A-record change normally affects only the hostname it serves. Email can still be disrupted if MX records depend on that hostname or if a nameserver migration omits mail-related records, so verify the complete dependency map.

### Should old hosting be cancelled after DNS changes?

No. Retain the old environment until the new service passes functional checks and remains stable through the agreed observation window.

### Can a DNS health check guarantee a safe migration?

No. A DNS health check provides public evidence for planning and verification. Application testing, data synchronisation, monitoring and rollback are still required.

[**Run The Cloud Market's free DNS health check**](https://thecloud.market/dns-health-check) before recording the migration baseline.

---

**Sources checked 28 September 2026:** [The Cloud Market DNS Health Check](https://thecloud.market/dns-health-check), [Cloudflare DNS TTL documentation](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/), [Cloudflare DNSSEC troubleshooting documentation](https://developers.cloudflare.com/dns/dnssec/troubleshooting/), and [Google Workspace email-authentication guidance](https://support.google.com/a/answer/10583557).