What I learned moving 500 domains to Cloudflare

Earlier this year I moved a little over 500 domains to Cloudflare for a marketing agency that had been collecting them for fifteen years. Client sites, campaign domains, typo domains, a few that nobody could explain. They were spread across four registrars and three DNS hosts, and renewals were arriving at a rate of about two a week.

It took six weeks. Nothing went down for longer than a few minutes. Here’s what I learned and the checklist I now use for every move, whether it’s one domain or five hundred.

Bulk transfers are mostly a spreadsheet job

The technical part of moving a domain is small. The hard part is knowing what you have. Before touching anything, I built a spreadsheet with every domain, its registrar, its current DNS host, its expiry date, whether it had email, and whether anyone still wanted it.

That last column saved real money. 140 of the domains were for campaigns that had ended years ago. The agency let them lapse instead of transferring them, which knocked a few thousand dollars a year off their renewals.

For the rest, Cloudflare will scan and import existing DNS records when you add a domain. It’s good, but not perfect. It misses records it can’t discover, which usually means subdomains nobody links to. I exported the zone file from the old host for every domain and compared the two. On about one domain in fifteen, the import had missed something.

The .au quirks

Australian domains are their own little world. At the time of the move, Cloudflare’s registrar didn’t support .com.au or .au, so those stayed with an Australian registrar and only the nameservers moved. That’s fine. You still get Cloudflare’s DNS, caching and security, you just renew somewhere else.

Two other things caught me out. First, .au domains are tied to an eligible registrant, usually an ABN. A handful were registered to ABNs of businesses that had since closed, which meant the agency’s clients technically weren’t eligible to hold them. Sorting that out took longer than everything else combined. Second, the auth code for a .au domain is sent to the registrant contact, and on old domains that was often an email address that no longer existed.

Email is where it goes wrong

A website being down for ten minutes is annoying. Email silently bouncing for a day is a disaster, and you don’t find out until someone asks why you didn’t reply. Every domain with an MX record got extra attention: I checked MX, SPF, DKIM and DMARC records matched exactly before switching nameservers, then sent a test email in and out straight after.

One domain had DKIM keys stored as two separate text strings, which the import had joined incorrectly. Mail still arrived, but outgoing mail started failing authentication. The DMARC reports caught it the next morning, which is a good argument for having DMARC reporting set up before a move.

The checklist

1. Inventory every domain: registrar, DNS host, expiry, email or not, still needed or not.
2. Export the full zone file from the current DNS host.
3. Lower TTLs on important records to five minutes, a day ahead.
4. Turn off DNSSEC at the registrar before changing nameservers, then turn it back on through Cloudflare afterwards.
5. Add the domain to Cloudflare and compare its imported records against the zone file, line by line.
6. Check MX, SPF, DKIM and DMARC records character by character.
7. Switch nameservers. Test the website, then send email in and out.
8. Transfer registration later, once DNS has been stable for a week. Never move both on the same day.

The DNSSEC step matters more than it looks. If you change nameservers with DNSSEC still on at the registrar, resolvers will treat your domain as tampered with, and it disappears from the internet until it’s fixed. I learned that one on a test domain, thankfully.

If you’ve got a pile of domains spread across too many accounts, send me the list. I’ll tell you what’s worth keeping and what a move would involve.