Compare the copy before you switch
On one software project, several domains were being moved to a new DNS provider. DNS is the address book of the internet: it is where a domain’s records say which server hosts the website, where its email is delivered, and which outside services are allowed to send email or prove ownership on its behalf. Moving a domain to a new provider means copying across the records the domain depends on, then switching the domain over to the new copy. A few records are expected to differ, such as the ones that name the new provider’s own servers, which the new provider sets up itself.
The new provider offered to import the existing records automatically, and it did. The import finished without an error. Most of the records were there.
Before anything was switched, every imported record was compared with the list at the old provider, one line at a time. On two of the domains, the import had missed a record that an email sending service relied on. On another, it had missed an older record that proved ownership of the domain to a third-party service. Each missing record was added by hand. Only then was the switch made. Afterwards, each record was looked up again to confirm it answered with the right value, the websites were loaded, and on one domain the email sending service was checked to confirm it still showed the domain as verified.
Nothing went wrong. That is the point of the story. The import was not broken. It did what imports usually do, and the comparison is what caught the gap.
Why a copy can be quietly incomplete
An import can only copy what it can see. For DNS, there is usually no public way for an outsider to download a domain’s full list of records, so an automatic import often works by checking common names, and it can miss anything it does not guess. One large DNS provider’s own documentation, for example, says plainly that its scan can miss records with very specific names, and that you should review your records and add any missing ones before switching.
The records most likely to be missed are the unusual ones, and the unusual ones are often the ones that matter quietly: a setting a mail service needs, a verification record added at some point for a tool nobody thinks about any more. A missing website record tends to show up quickly, because someone loads the page and it is gone. A missing email or verification record may not show up for days, and when it does, the symptom (mail landing in spam, a service asking you to verify again) points nowhere near the move.
The same shape shows up outside DNS. Moving settings from one hosting account to another, copying configuration between environments, exporting contacts from one tool into another: many of these end with a message saying it worked. Some tools also list what they skipped, and that list is worth reading. But a success message on its own is easy to read as covering everything, when it often describes only what was copied. An AI summary can carry the same gap. If the AI only looked at the result of the copy, it can only report on what it saw there. Asked to compare against the original, it can find what is missing, and that comparison is the habit below.
The habit: three lists before you switch
Before you switch anything over to a copy, ask your AI for three lists, in writing.
- The source list. Every item at the old place, taken from the old place itself. Not from the import’s report, and not from memory. If the old service can export the list, use the export.
- The copy list. Every item at the new place, taken from the new place.
- The differences. Anything in one list and not the other, and anything that appears in both with a different value. Some differences are expected, such as records the new provider manages itself, or a value you have decided to change. For each difference, either it gets fixed, or there is a written reason it is different on purpose. The result is an agreed list: what the new place should contain.
Then ask one more question for each item on the source list: “What does this record do, and how would we know if it stopped working?” You do not need to understand every answer. You need the answer to exist, because that is what tells you what to test after the switch.
A useful way to put it to your AI: “Do not switch anything yet. Show me the old list, the new list, and every difference. I want the comparison done item by item, not as a summary.”
How to check it worked
The comparison protects you before the switch. A second check protects you after it, because a record can be present and still wrong, or the switch itself can fail in a way no list shows.
After the switch, ask your AI to look up each item at the new place and confirm it gives the value on the agreed list. For most items that is the old value; for the differences you agreed, it is the new one. Then test the things those items power, from the outside, the way a user or a customer would meet them: load the website, send a test email and see that it arrives, open each outside service that needed a verification record and confirm it still shows the domain as verified. A tool reporting success is a claim, as an earlier post on success messages argues. A page that loads and an email that lands are evidence.
If the AI tells you “all records imported successfully”, treat that as the start of the check, not the end of it. The question to ask is not “did it work?” but “what is in the old list that is not in the new one?” An empty answer to that question, produced by an actual comparison, is the thing worth trusting.