---
title: "Moving Zones in Days While Customer DNS Takes Months"
canonical: https://dxdev.com/blog/thousands-of-domains-to-a-layer-above/
datePublished: 2026-07-06
---
The technical half of putting Cloudflare in front of a legacy platform took days. Our zones, our certificates, our origin config: batch after batch, scripted, done. If that had been the whole project, this would be a short post.

The other half is thousands of customer domains, and it's still going.

## The DNS we can't log into

Our customers can point their own domains at their sites, so their DNS lives in their registrar accounts, managed by them. Volunteers, treasurers, someone's nephew who set it up in 2014. When the platform moves behind Cloudflare, every one of those domains needs its records changed by a person we can't log in as, on a timeline we can't control, for a migration they never asked for.

No script fixes that. The technical migration was days of work. Shepherding thousands of strangers through a change on registrars we can't access is the project.

## What the campaign looks like

These are the pieces that made it tractable, in the order we built them.

**A canary batch first.** A handful of domains moved onto the new path and got watched. The first thing a migration teaches you is what you got wrong, and you want that lesson at a blast radius of five domains, not five thousand.

**Bulk migration of everything we control.** All company-managed domains moved in scripted batches. AI agents ran the batches while we did other work, and each batch verified itself before the next started. What we control moves fast, which is exactly why the rest is the project.

**A live migration board.** It lists every customer-managed domain, its current state, and what it's waiting on. Automated checks notice when a customer's DNS change actually lands, so the board updates itself instead of relying on people telling us they did the thing. Half of them wouldn't tell us, even after doing it.

Redacted, one slice of it looks like this. [Domains move in batches of 50](/everyday-ai/work-after-the-switch/), and the board is the source of truth for which ones are safe to touch next.

| domain (redacted) | state        | waiting on          | days |
|-------------------|--------------|---------------------|------|
| ****alpha.org     | RELAY_ACTIVE | customer DNS change | 22   |
| ****beta.com      | EMAIL_2_SENT | customer to act     | 9    |
| ****gamma.net     | CERT_REISSUE | ACME retry          | 1    |
| ****delta.org     | MIGRATED     | nothing             | done |

The `days` column is the one to watch. A row that has sat in `RELAY_ACTIVE` for three weeks is a customer who is never going to move on their own, and that is the whole reason the relay below has to be permanent.

**Deadline emails, staged.** First notice, then a second warning with a date. Writing these is its own skill. The audience doesn't know what DNS is, and the email has to get them to either act or forward it to whoever can.

**An apex relay.** It keeps a domain that's mid-flight or late working instead of going dark. That made the relay itself production infrastructure, so it got monitoring, alerting, and a backup with a restore we actually ran end to end. A fallback you have never restored from is only a wish.

Even with all of that, nearly every batch unearthed some nuance nobody predicted. A site "waiting for propagation" actually needed a certificate reissued. Staff screens confidently showed a stale state. Cleanup jobs left old renewals running. Those forty tickets turned out to share one root cause, and they earned [their own post about the state machine we should have written first](/blog/every-batch-found-a-new-nuance/).

## Why bother, beyond the crisis

The trigger for all this was bot swarms, which is its own post. The durable win is different: every pointer to our production server now resolves through Cloudflare. When we eventually move that server, and we will have to, thousands of customer DNS configs don't need to change again. The next migration touches infrastructure only, with no long tail and no email campaign. One layer of indirection, bought once, paid for by exactly one round of this pain.

The long tail takes months no matter how urgent the trigger felt. Ours started as bot swarms and became a campaign we're still running. The board is open in a tab as we write this, and a handful of rows have sat amber for weeks, waiting on a volunteer who hasn't opened the second email.

## If you're about to do the same

Before putting a layer in front of a platform with customer-managed domains, find out who controls each domain's DNS, and plan for a long tail that no script can move. Expect to need a tracked board, staged notices, and a relay with a tested restore for the domains that stay late. The payoff is that a later server move needs no customer DNS changes.