---
title: "Our Plan Said We Could Always Go Back. Nobody Had Ever Gone Back."
canonical: https://dxdev.com/blog/2026-06-06_a-way-back-nobody-had-rehearsed/
datePublished: 2026-06-06
---
The migration checklist had an item that read "rollback exercised once for real", and it was still unticked. The plan promised that any customer address we had moved could be moved back. Nobody had tried it.

## What I found when I looked

We were moving customers' web addresses from an old server to a new setup in phases. A fallback existed on paper. The first job was working out what had actually been tested. One backup route, the recovery of a middle piece, had been run. Moving an address back to the old server had not. It was a paragraph.

The fallback only works if the old server still holds a credential for that address. Take that away and a visitor gets an error page instead of the site.

I went looking for something safe to rehearse on. I believed three of my own test sites were in the right state, and I had believed it for long enough that it cost me several rounds of work before I checked. They were not. An earlier tidy-up had already removed everything from the old server for all three, so they had no way back at all. The sites that did qualify were four expired test sites that we look after ourselves, each still holding its full set. I picked one that was half moved.

## The rehearsal

The rehearsal had four steps, each checked before the next:

1. Finish the move.
2. Prove the way back still exists, without changing anything.
3. Move it back and confirm that both the registrar's own records and the public internet agreed.
4. Put it back exactly as I found it.

The old server kept serving the site securely through the whole thing, and the test site ended the rehearsal exactly as it started. Run the same step-two check on a site that had already been tidied up and it failed straight away. That contrast made the case: cleaned up means no way back, kept means an instant way back.

## What changed in the plan

The written procedure now begins with the read-only check. If it fails, the way back is gone and the procedure says to stop. I also filed a ticket for a waiting period before any tidy-up, because the credential that makes going back possible is the exact thing the tidy-up deletes.

## The label that stood the AI down

One more thing went wrong during the rehearsal. The AI assistant saw a status reading "disabled" next to the browser and decided it had no browser to use, so it stood down. The label only meant that one feature was switched off, and the browser itself worked. The status name was renamed to say what it actually turns off.

## Where AI fits

The AI ran each step, checked the result after every one and wrote the procedure down from what really happened. It did not decide which site was safe to rehearse on, and its confident memory about which test sites qualified was wrong until it was checked. The status label showed how a word can talk an AI out of a tool it needs.

## The human decision

I chose the subject and the moment. A real customer's site was never in play, and I would not have handed that choice to a tool. Deciding whether the plan was now proven enough to rely on was also mine.

## The lesson

Before you rely on a fallback, use it once on something safe, and find out what it needs in order to work. Then make sure the cleanup that comes later does not remove it. The plan now opens with a single read-only check, and a single check is all it takes to tell you whether the way back still exists.

The Build Log companion has the exact steps of the rehearsal.