Moving two domains from GoDaddy to Cloudflare sounded like an afternoon task. It took most of two days — not because anything was fundamentally broken, but because DNS is a distributed system and distributed systems have failure modes that only reveal themselves when you're standing in them.
I learned more about how the internet actually works during this migration than I had in years of using it.
Why Move to Cloudflare?
We'd already deployed both sites to Cloudflare Pages. Keeping DNS at GoDaddy while hosting on Cloudflare meant every request had to cross an extra hop — DNS lookup at GoDaddy, then resolution to Cloudflare, then delivery. Moving DNS to Cloudflare meant the whole chain would be under one roof, with better performance, free SSL, and a cleaner dashboard.
Step One: Changing Nameservers
GoDaddy doesn't let you delete nameservers — you have to replace them. This sounds obvious in retrospect, but my first instinct was to try to delete the existing ones (ns51.domaincontrol.com, ns52.domaincontrol.com) before adding Cloudflare's. GoDaddy blocked the deletion. The right move was to go into "Change Nameservers," select "Enter my own nameservers," and replace both with the Cloudflare pair (randall.ns.cloudflare.com and sonia.ns.cloudflare.com).
Done. That part took about two minutes once I understood what I was doing.
The Error 522
After switching nameservers for a client's site, the site came up — but only at the www subdomain, not at the apex domain. The apex returned a Cloudflare Error 522: connection timed out.
What was happening: When I'd first set up the domain in Cloudflare, there was a leftover A record pointing the apex to the old GoDaddy hosting server (50.63.x.x). Cloudflare was dutifully proxying requests to that server — which no longer existed because I'd just cancelled the hosting.
The fix: delete the old A record, add a CNAME pointing the apex to the Cloudflare Pages deployment URL. Cloudflare's "CNAME flattening" handles the rest — at the DNS level, it converts the CNAME to an A record with Cloudflare's Anycast IPs so external resolvers see a valid response.
The Router Cache Problem
After cancelling the GoDaddy hosting for alfredandsabrina.com, the site stopped resolving from my home network. Cellular worked fine; home WiFi didn't. Chrome showed DNS_PROBE_FINISHED_NXDOMAIN.
Running nslookup alfredandsabrina.com revealed the problem immediately: my home router (192.168.4.1) had cached a negative DNS response from when the site was briefly unreachable, and was returning NXDOMAIN from its local cache without even querying upstream.
The fix was a DNS flush on my Mac (sudo dscacheutil -flushcache + sudo killall -HUP mDNSResponder) followed by waiting for the router to clear its own cache. Cellular worked the whole time because it routes through a different DNS resolver that had already updated.
SSL: Pending, Then Fine
Cloudflare issues SSL certificates automatically, but there's a delay while they verify domain ownership. For alfredandsabrina.com, the SSL status sat at "pending" for longer than expected. Checking from cellular (which bypassed the router cache issue) confirmed the site was actually live and serving HTTPS correctly — the "pending" status was a dashboard display artifact from the domain verification getting briefly stuck.
The fix: delete the custom domain from the Cloudflare Pages project and re-add it. This reset the verification state from a stuck "undefined" status back to clean "initializing" → "pending" → "active."
What I Actually Learned
DNS feels like magic until something breaks. Then you realize it's just a massive distributed key-value store with TTL-based caching at every layer. Once you have that mental model, every problem becomes diagnosable: which cache is stale, and how do I flush it?
Both sites are now fully live — HTTPS, custom domains, no hosting bills. The migration took two days because I was learning as I went. The second time would take about twenty minutes.