Moving Behind Cloudflare Took Days. Getting Every Customer to Update One Setting Took Months.

I clicked back to the migration board, the tab that stayed open as I wrote, and another amber row stopped me: a customer was still waiting to change one small setting.

That row was the real job. Not the work of moving a large platform behind Cloudflare, a service that can stand between a website and the wider internet. That technical move took days. The records we controlled, the paperwork needed to keep sites trusted, and the destination they pointed to could be handled in batches. Scripts did the repetitive part. Each batch checked itself before the next began.

For a moment, that made the project look almost finished.

It was not finished. Thousands of customers use their own web addresses for their sites. Those addresses live in accounts that belong to the customers, not to us. The account might be in the hands of a league volunteer, a club treasurer, or the person who set it up years ago and has not thought about it since. I cannot sign in and make the change for them. They did not ask for this migration, and they have their own schedules.

The term for that little setting is DNS. It is just the line in the internet’s address book that tells visitors which door to use when they type a web address. Changing it can be simple for someone who knows where to find it. The hard part is that a lot of people do not know where to find it, do not know which login still works, or do not see the first email at all.

What I tried first was treating the whole move as a technical job. That was a reasonable way to start because the part under our control really did move quickly. We used a small test group first, just a few items before doing the larger group. Then the domains we controlled moved through scripted batches while I worked on other things.

That approach worked, which was the trap. It did not reach the thousands of addresses controlled by other people. The cost was time. Days of technical work turned into a campaign that would take months, with every slow reply becoming another thing to track. It also risked somebody’s patience. Each customer was being asked to spend time on a change they never requested, using an account they may have forgotten exists.

So the work changed shape. Instead of asking, “Did the script run?” I needed to ask, “Who is waiting on whom, and what happens if they never reply?”

The answer was a live board. Every customer-controlled address got a row with its current state and the next thing it needed. Automated checks could notice when a customer had made the change, so the board updated from what had actually happened instead of relying on people to write back and say they had done it.

The addresses moved in groups of 50. The board made it clear which group was safe to touch next. More important, it made the stuck cases visible. A row that had been amber for three weeks was not a small clerical delay. It was a sign that the customer might not move on their own.

That mattered because a site cannot simply disappear while a person is late. A fallback path had to keep an address working during the wait. It became a permanent working part of the system, not a temporary patch. It was watched for trouble, and it had a backup that was restored all the way through. A backup that has never been restored is like an umbrella still in its wrapper. It may be there, but you do not yet know whether it will help in the rain.

The first emails did not solve the problem either. The notices had to come in stages: a first message, then a second warning with a date. The wording could not assume that the reader knew what the setting was or where it lived. It had to help them act, or give them something clear enough to forward to the person who could.

And the board kept teaching us. Nearly every new batch brought a detail nobody had predicted. Some sites that appeared to be waiting simply needed their trust paperwork renewed. Some internal screens showed an old status with great confidence. Some cleanup work left old renewals running. Forty tickets that looked separate turned out to share one cause.

The original push came from waves of automated traffic. But the lasting reason for the work is calmer than that. Once every address points through this new front door, a future move of the systems that run the live sites will not require another round of asking thousands of customers to edit their settings. The next move can stay inside the systems we control instead of becoming another long campaign.

That is the part I keep coming back to when I see an amber row. The frustrating, human part of a change is not always a side issue after the real work. Sometimes it is the real work.

Once every address points through this new front door, the next move stays inside the systems we control. No more waiting on a stranger’s login to finish a migration we started in an afternoon.

dxdev LESSON · paste into your AI coding agent
LESSON: A fallback path that exists but has never been exercised is a hope, not a safety net
SOURCE: dxdev.com/blog/2026-07-04_work-after-the-switch
WHAT HAPPENED: Moving a large platform's controlled infrastructure behind a new front door took days, using scripted batches that checked themselves before the next one began. That made the project look almost finished, but thousands of customers controlled their own DNS settings on accounts the team had no access to, so those addresses could not be migrated on any schedule but the customer's own. The work changed from "did the script run" to "who is waiting on whom, and what happens if they never reply," tracked on a live board where automated checks, not self-reported replies, updated each row's state. Because a site cannot simply go dark while a customer is late, a fallback path had to keep an address working during the wait, and it had to become a permanent, actively watched part of the system rather than a temporary patch, complete with a backup that had actually been restored end to end rather than merely existing unverified.
THE RULE: A fallback, redirect, or backup path built to cover a dependency on someone outside your control is not proven by existing, it's proven by being exercised, restored, or failed over at least once on purpose. Treat it as permanent, monitored infrastructure from day one, not a stopgap you'll get back to later.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any fallback, redirect, or failover mechanism built to bridge a migration or an external dependency that has not actually been exercised, a real restore or failover test, to confirm it works.
  2. Any migration or rollout status tracked by relying on the other party reporting completion, rather than an automated check confirming the state actually changed.
  3. Any temporary workaround built to cover an external dependency that isn't being actively monitored or maintained as ongoing infrastructure, risking silent bit-rot while people still depend on it.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.