A DNS Inventory Checklist Before Moving Your Domain or Website

A website migration can fail outside the website. Mail stops arriving, a newsletter platform loses domain verification, or a certificate stops renewing a month later. These failures often begin with an incomplete DNS inventory. Before moving a domain between DNS providers or pointing it to a new VPS, record the services that depend on its zone and who can verify each one.

Separate the changes you are making

Transferring a domain registration, changing authoritative nameservers, and changing a website's A record are different operations. A project can involve one, two, or all three. Write down which are actually necessary. Moving a website to LayerOne does not automatically require moving the domain registration or replacing the existing DNS provider.

Make a short change statement such as: move the public web application and its uploads, preserve the existing mail provider, and keep the current authoritative DNS service. That sentence gives every later record edit a purpose and makes accidental scope expansion easier to spot.

Create a service-oriented record list

Export the zone where the provider allows it, then annotate the export. Include the root domain, www, API names, asset hosts, MX destinations, mail-authentication TXT records, certificate authorization records, and service verification entries. Record wildcard behavior and delegated subdomains separately because a simple list of visible website names can miss them.

For each entry, capture its type, exact name, value, TTL, business purpose, and responsible person. A TXT value is not automatically disposable just because it looks random. Ask the service owner whether it remains necessary. Preserve an original copy of the inventory before making cleanup edits so the migration record stays useful for rollback.

Write a verification task for every service

Consider a small agency using a website, external email, a client portal, and a newsletter service under one domain. Its checklist should contain four separate user journeys: open the website and submit a test form, send and receive a permitted test email, sign into the portal, and confirm domain verification in the newsletter provider. A homepage returning 200 cannot stand in for these other checks.

If nameservers are changing, compare the destination zone before delegation changes. Pay special attention to DNSSEC coordination, provider-specific alias features, and any automation authorized to edit the old provider. DNS tokens embedded in a certificate renewal system may need their own planned transition.

Keep a retirement date, not a guess

Retain access to the old DNS configuration and hosting environment for an agreed observation period. Watch for delayed failures such as scheduled jobs and certificate renewals. Record which operator can restore a missed entry and where the original value is stored. When the migration is complete, remove obsolete credentials through the relevant providers and document the new source of truth.

The DNS specification explains zone responsibility and delegation. Pair this inventory with our VPS recovery planning article and the LayerOne documentation before scheduling the cutover.