toolkit

Scenario · The bigger jobs

Can this rebuild go live?

A rebuilt site is ready to replace the live one, and someone has to sign it off.

Moving a rebuilt site's domain over from the old one is the one window that doesn't reopen — once it happens, the old site is gone for good. This runs the pre-launch checklist that decides whether it's actually safe to flip the switch, archiving the old site first, grading the new one against every row that matters, and recording the handful of answers that only a person can give. A blocking item that comes back needing a second look is treated the same as an outright failure, on purpose, because the cost of being wrong here is the highest it will ever be.

What to ask for

Migration gateThe migration gate for a WordPress-to-Cloudflare migration.Old vs new page parityOld vs new page parity across two hosts.Cutover readinessCutover readiness for a replacement site — everything wrong with a new build in its own right, before a domain is pointed at it.What the old site didWhat the old site was doing that the new one has to keep doing — the audit that runs while the old site still exists.Pre-cutover site archiveArchives the old site before it stops existing, hash-bound and content-addressed.

See it work

A real run of Cutover readiness:

REVIEW — 0 blocker(s) · 1 to review
  [warn] no Strict-Transport-Security header on the target — browsers will honour a plain-http first request to the live domain until they see one

  report: ./out/cutover-readiness-cutover-readiness.html
  json:   ./out/cutover-readiness.json

The captured report, exactly as a run hands it to a client —open the full report ↗

The pre-live gate. It runs before DNS moves, and it is the one window that does not reopen: the old site exists until the switch and then never again.

  1. Archive the old site first. Every page’s HTML, headers and screenshots, hash-bound, before anything else runs. This step is item zero because it cannot be redone afterwards.
  2. Capture what only exists now — the old site’s real-world speed data, its DNS records, and its plugin and stack inventory. All of it belongs to whoever hosts the domain today.
  3. Run the gate. One command grades the rebuild against the checklist and returns a verdict per row, with the blocking rows called out.
  4. Answer the manual rows. The ones a tool cannot know are recorded against the file that proves them, so the same question is not asked again on every run.
  5. Read the one-sentence answer at the top of the report: ready, or not ready and what is stopping it.

The checklist itself

The full 117 checks across 10 phases live in the migration checklist, and they stay there rather than being restated here.

That is deliberate. scripts/migration-checklist.test.mjs recounts that table on every run and fails the build when the summary and the rows disagree — a guarantee that only works against one canonical table. A paraphrase here would be a second copy with no such gate, and the row ids the gate reports against would stop matching what anyone can look up.

Who can overrule a REVIEW

A blocking row that returns REVIEW stops the gate exactly as a FAIL does. The verdict vocabulary is defined in the result contract, and the sign-off mechanism records a human answer against a manual row — but it cannot record an override for an automated row that graded REVIEW, which means there is currently no written answer to “who says ship anyway”.

That gap is real and is named here rather than papered over. Until it is decided, treat a blocking REVIEW as a FAIL.

What this does not cover

The post-live phase. Roughly a third of the checklist is questions only a human can answer — where the backup is, whether the rollback was tested — and the gate records those answers rather than deriving them. Phase 9, everything after the domain moves, is not written yet.

← All scenarios