Three weeks ago I helped migrate a friend's WordPress site from a shared host to a VPS. The move itself went fine — files transferred, database imported, SSL renewed. But traffic dropped 80% for 3 days because I forgot two DNS records.
I've done this migration a dozen times. I still made this mistake. That's why I'm writing it down.
What I Forgot
The site had email running on Google Workspace. During the migration, I updated the A record to point to the new server. I also updated the CNAME for www. But I forgot:
- The MX records — they were set on the old host's DNS panel, not on the domain registrar
- The TXT records — including the SPF record and a Google site verification
The A record worked fine, so the website loaded. But email bounced for 3 days. And Google Search Console started showing verification errors, which slowed down re-indexing.
The fix took 10 minutes once I noticed. The bigger problem was that I didn't notice for 3 days.
How to Actually Check Your DNS Records
I now do this on every migration:
- Before migration: run a DNS lookup on the old setup. Screenshot everything.
- Migrate.
- After migration: run the same lookup on the new setup. Compare.
The tool shows A, AAAA, CNAME, MX, TXT, and NS records side by side. It takes about 3 seconds per domain.
If I'd done this three weeks ago, I would have caught the missing MX and TXT records before the move, not after.
DNS Records, Simplified
Every domain has 6 main record types. Here's how I think about them:
| Record | What It Does | If You Break It |
|---|---|---|
| A | Points domain to server IP | Website won't load |
| AAAA | Same for IPv6 | IPv6 users can't reach you |
| CNAME | Alias for a subdomain | WWW or subdomains stop working |
| MX | Routes email | Email bounces |
| TXT | Verification + SPF/DKIM | Google verifications fail, spam filters flag you |
| NS | Who runs the DNS | Nothing works |
Before this migration, I would have told you A and NS are the only ones that matter. Now I know MX is just as important.
The One Rule I Follow Now
Screenshot your DNS records before any change, and check them after.
I keep these screenshots in a Notion doc named "DNS history — [domain]". When something breaks 6 months later, I know exactly what changed.
You can do the same manually, or just paste the output of our DNS lookup tool into a text file.
Why TTL Matters (and Where to Set It)
TTL (Time To Live) tells DNS resolvers how long to cache a record. If you set it to 86400 (24 hours), then even if you update the record, ISPs will keep using the old value for up to 24 hours.
My rule: 24 hours before a migration, set TTL to 300 seconds (5 minutes). Do the migration. Wait 24 hours. Set TTL back to 3600 or 86400.
This single trick reduces "waiting for DNS to propagate" pain from hours to minutes.
What I Do Now (Full Checklist)
Before every migration, this is my actual list:
- Log in to the current DNS provider
- Take a screenshot of every record
- Run a DNS lookup and save the output
- Lower TTL to 300
- Wait 24 hours
- Migrate files + database
- Update A record to new server
- Recreate MX, TXT, CNAME records on the new DNS provider
- Run the same DNS lookup and compare to the screenshot
- After 24 hours, set TTL back to normal
Steps 1-3 take 5 minutes. Skipping them cost me 3 days of traffic.
A Tool I Wish I'd Had Earlier
Before this incident, I used to check DNS with the command line. Now I use our DNS lookup tool because it shows everything in one screen — no scrolling through terminal output.
If you're about to migrate a site, do this first:
- Run the current DNS check
- Save the output
- Do the migration
- Run it again
Three minutes of work that can save you three days.