What a Green Status on a Domain Migration Actually Measured

A customer told us their site was down, four days after we had migrated their domain and marked the job complete.

A complete status in this work is not a guess. It comes from a tool that checks. It ran, it came back green, and the migration moved on to the next domain in the batch. That green result sat there, trusted, for four days while the site was broken behind it the whole time.

The mistake in the checking tool was subtle enough that it took a real customer complaint to surface it. The check was supposed to confirm that the public internet could reach the site at its new home. What it actually did was ask the platform we had just moved the domain onto whether that platform believed the domain was set up correctly. Those sound like the same question. They are not. A platform can be right about its own settings while the outside world, for a completely separate reason, still can’t reach the site through it. Asking the platform “is this right” tells you what the platform thinks. It tells you nothing about what a stranger on the internet sees when they type in the address.

The same blind spot, pointed the other way

Once we had named that, a second problem turned up from the opposite direction. The same check had been flagging roughly a thousand domains as still pending when they had actually migrated correctly. It inferred status from the platform’s settings instead of from a real lookup from outside.

Same root cause, opposite symptom. One customer saw “done” when it wasn’t. A thousand others sat in a queue marked “not done yet” when they were.

Rerunning it would not have helped

The obvious move was to rerun the same check across everything, faster or more often. That wouldn’t have helped. A check that only asks the system it is validating gives the same wrong answer every time you ask.

What caught the real state of things was leaving that system entirely. We made independent lookups from the outside, the way an ordinary visitor’s computer would, and cross-checked them against a second, separate method. Only an answer that came from outside the thing being tested could prove anything about what a real visitor would see.

If you rely on a “verified” or “passed” status, find out what produced it. Either it checked with something outside the system being verified, or it asked the system about itself. A green light from inside a system tells you what that system believes. When that belief has to match what is true for the people depending on it, the check has to come from somewhere else.

dxdev LESSON · paste into your AI coding agent
LESSON: A check that asks the same system it is checking will only confirm what that system already believes
WHAT TO SHARE: Describe a verification step in your process, what it checks, and exactly how it checks it (what it asks, and of whom).
ASK YOUR AGENT TO:
1. Trace each verification step back to the actual system it queries, and name whether that system is the same one the step is meant to be validating.
2. Flag any check where a failure could be invisible because the check and the thing being checked share the same underlying path.
3. Propose an independent way to verify the same outcome, one that does not pass back through the system in question.
RETURN: A short table of verification step, what it actually asks, whether it is independent, and a safer alternative if it isn't.
BOUNDARY: Analysis only. No agent reruns a migration, changes a customer's live configuration, or declares an issue resolved; a person confirms before anything is communicated externally.