Skip to content
netscanner
Menu

Tools

Guides
deenfrit

Checklist: migrate your domain and website without downtime

Moving a domain, DNS or website is quick when it is well prepared. This checklist guides you through every step before, during and after the switch, so your website and email keep working throughout.

Updated on

What exactly is moving?

Before you start, clarify which of the four layers are changing. They are independent of each other:

  1. Registration: Which registrar is the domain registered with, e.g. Hostpoint?
  2. DNS hosting: Which name servers answer queries for the domain, e.g. Cloudflare?
  3. Web hosting: Which server hosts the website?
  4. Mail hosting: Who receives and sends the emails?

A common scenario: the domain stays registered with Hostpoint, DNS moves to Cloudflare, the website moves to a new host and mail hosting stays the same. The WHOIS lookup shows the current registrar and name servers.

Timeline at a glance

  • One week before: Create an inventory, export the zone, prepare the new server and the new zone.
  • 24–48 hours before: Lower the TTL, clarify the DNSSEC status.
  • Migration day: Switch name servers or update records, test website and email.
  • First week after: Monitor Search Console, redirects and DMARC reports, raise the TTL again.
  • After one to two weeks: Cancel the old hosting.

For migration day, choose a time with little visitor traffic when you, and ideally the support teams of both providers, are available. A Friday afternoon before a long weekend is a bad choice.

Before the migration: preparation (1–7 days before)

Inventory of all DNS records

Not all names in a zone can be listed from the outside. DKIM selectors or rarely used subdomains stay invisible if you don’t know the name. So export the zone directly from your current DNS provider, ideally as a zone file.

  • Zone exported from the current provider and saved
  • A and AAAA noted for the root domain, www and all subdomains
  • CNAME records recorded (e.g. www, autodiscover, shop, tracking domains)
  • MX records noted with priorities
  • TXT records recorded: SPF, verifications (Google, Microsoft and others)
  • DKIM selectors noted (e.g. google._domainkey, selector1._domainkey)
  • _dmarc, _mta-sts and _smtp._tls recorded
  • SRV and CAA records noted

With NetScanner’s DNS lookup, you can compare the publicly visible records with your export.

Lower the TTL and clarify special cases

  • TTL of the records that will change lowered to 300 seconds 24–48 hours in advance
  • DNSSEC status checked: is a DS record stored at the registrar?
  • If DNSSEC is active: DS record removed and its TTL waited out (or key transfer planned with the new provider)
  • CAA records allow the new host’s certificate authority
  • Login credentials for the registrar and the old and new providers at hand

Our guide to DNS propagation explains why the TTL lead time is necessary.

Prepare the website

  • Full backup of files and database created
  • Website set up on the new server and tested via the local hosts file
  • SSL certificate on the new server planned (many hosts only issue it once the domain points to them)
  • If URLs change: list of 301 redirects from old to new created
  • Contact forms: which server does the new host use to send email?

During the migration

Move DNS to Cloudflare, keep the registration at Hostpoint

  1. Add the domain to Cloudflare. Cloudflare imports existing records via a scan, but does not necessarily detect all of them.
  2. Compare the new zone record by record with your export and add anything missing, especially DKIM selectors and verifications.
  3. Set mail records (MX targets, mail server hostnames) to “DNS only”. The Cloudflare proxy only forwards web traffic, not email.
  4. In your registrar’s control panel, e.g. at Hostpoint, replace the name servers with the two assigned by Cloudflare. The registration stays with the registrar; only the delegation changes.
  5. Do not delete the old zone and do not change it anymore. Some resolvers will keep querying the old name servers for a while.

Switch the website

  1. Freeze content changes on the old website, and keep an eye on orders for online shops.
  2. Transfer the latest state of the database and files to the new server.
  3. Change the A and AAAA records (or the CNAME) to the new server.
  4. Have the SSL certificate issued as soon as the records point to the new server.

Right after the migration: verify

  • WHOIS shows the new name servers
  • All records in the new zone match the inventory
  • Website reachable with and without www, HTTP redirects to HTTPS
  • SSL certificate valid for the root domain and www
  • Old URLs redirect to the new ones with a 301
  • Security headers set; check redirects, headers and cookies with the HTTP header checker
  • Email tested in both directions with external addresses (e.g. Gmail and Outlook.com); SPF, DKIM and DMARC pass in the header of the received email
  • Contact forms send email, and the new web server is included in the SPF record

The email checker tests all mail records at once: MX, SPF with lookup count, DMARC, common DKIM selectors as well as MTA-STS and TLS-RPT. For background on the records, see our guide How to set up SPF, DKIM and DMARC.

In the days after

  1. Search Console: Check whether the property is still verified (was the verification TXT record carried over?). Resubmit the sitemap and watch the error reports for 404 pages. If the domain itself changes, also use the “Change of Address” tool.
  2. Raise the TTL: Once everything runs smoothly, set the TTL back to 3600 seconds or more.
  3. Enable DNSSEC: Turn it on at the new DNS provider and add the new DS record at the registrar.
  4. Read DMARC reports: New sending sources show up here first.
  5. Cancel the old hosting: After one to two weeks at the earliest, and only once a current backup is safely stored.

Common pitfalls

  • Missing DKIM or verification records: They are rarely in the host’s documentation, only in the old zone.
  • Proxy on mail hostnames: A mail server name proxied through Cloudflare cannot be reached for email.
  • Outdated DS record: If the old zone’s DS record stays at the registrar, resolution fails for validating resolvers.
  • Local delivery at the old host: If a mailbox for the domain is still set up on the old web server, it often delivers form emails locally instead of sending them to the MX. Remove the mail domain there.
  • Deleting the old zone too early: Resolvers with cached old NS records then get no answer at all.

Frequently asked questions

Do I have to transfer the domain to the new provider?

No. Registration, DNS and hosting are separate services. You can keep the domain at your registrar and only point the name servers to a different DNS provider such as Cloudflare.

Why does email stop working after the migration?

Usually the new zone is missing MX, SPF, DKIM or DMARC records. Compare the new zone with the export of the old one and check the mail records specifically.

When can I cancel my old hosting?

Only once all records point to the new servers, the old name servers no longer receive queries, and your website and email have been tested. Allow one to two weeks of buffer for this.

What do I need to watch out for with DNSSEC?

If DNSSEC is active, remove the DS record at the registrar before switching name servers, or transfer the keys in an orderly way. An outdated DS record makes the domain unreachable for validating resolvers.

More tools

Related guides