--- title: "Groups of 50 Domains and a Fallback Path With a Restored Backup" canonical: https://dxdev.com/everyday-ai/work-after-the-switch/ datePublished: 2026-07-05 --- We clicked back to the migration board, the tab that stayed open as we wrote, and another amber row stopped us: a customer was still waiting to change one small setting. That row was the real job. Putting a large platform behind Cloudflare, a service that can stand between a website and the wider internet, was a separate piece of work, and it took days. The records we controlled, the paperwork needed to keep sites trusted, and the destination they pointed to could all 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. ## The part that belonged to someone else Thousands of customers use their own web addresses for their sites. Those addresses live in accounts that belong to the customers, and we cannot sign in and make the change for them. The account might be in the hands of an organization volunteer, a club treasurer, or the person who set it up years ago and has not thought about it since. They did not ask for this migration. They have their own schedules. The name for that little setting is DNS. It is the line in the internet's address book that tells visitors which door to use when they type a web address. Changing it is simple for someone who knows where to find it. A lot of people do not know where to find it, do not know which login still works, or never see the first email. ## What we tried first We treated 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 the larger group. Then the domains we controlled moved through scripted batches while we worked on other things. It worked, which was the trap. It never reached 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 drew on every customer's patience, because each one 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. ## The board 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 waiting for people to write back and say they had done it. The addresses moved in groups of 50. The board showed which group was safe to touch next. It also made the stuck cases visible. A row that had been amber for three weeks 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. 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. ## What 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](/blog/the-batch-aging-out-with-no-alarm/). 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. The lasting reason for the work is calmer. 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 and will not become another long campaign. That is what we keep coming back to when we see an amber row. When a change depends on settings customers own, the frustrating, human part can be the main work. It needs a live board, an honest answer to what happens if nobody replies, and a fallback whose backup has actually been restored.