Stop 5 of 10 · Weekly
Migration runbook
A cutover runbook generated from the architecture, rehearsed against failure injections Claude plays in role, with a rollback section that names the point of no return.
The document that gets written last and matters most
Calverton County cuts over on a Sunday in March. Fadi has the architecture, the compliance mapping and a signed order. What he does not have is the forty-page runbook that says exactly what happens between the Friday freeze and the Monday morning the records division opens for business.
The runbook is generated from the architecture, which is the whole reason the architecture document was written properly in stop two. What it cannot be generated from is the customer's environment, so it is written in placeholders and filled in the county's own change record.
Generate the structure, then rehearse it
Using the Calverton County architecture document and decision log in this Project, write the cutover runbook for the records platform migration. Phases: preparation in the two weeks before, the Friday change freeze, the pre-cutover validation, the cutover itself, post-cutover validation, and the first week of hypercare. Every step has: an owner by role, the console or command named generically, the exact action, the expected result, the expected duration, and what to do when the result is different. Use placeholders for anything that would be an endpoint, an address or an account identifier. Mark the go and no-go decision points explicitly, with the criterion written as a number where a number is possible. Then, separately, list the steps whose duration you have estimated rather than derived, because those are the ones I will time in the rehearsal.
You are running a cutover rehearsal for the Calverton County migration. I am the cloud architect. Use the attached runbook. Play the incident. Deliver one injection at a time, wait for my response, and do not tell me what the right answer is. Injections should be realistic for this design: replication lag, a validation count mismatch, an identity federation failure, an integrator who is unreachable, a dependency nobody documented. After each of my answers, note whether the runbook actually covers it and which step number. At the end, give me every injection the runbook did not cover and every decision that had no named owner.
The second half of that prompt is the deliverable. A rehearsal that produces a good feeling produces nothing. A rehearsal that produces five uncovered injections produces five runbook lines.
The rollback section
Written before the cutover section, not after. It names the point of no return, what rollback costs on either side of it, who authorises it, how long it takes, and what the county tells its own users in each case.
Write the rollback section for this runbook. Name the point of no return precisely: the moment after which rolling back means reconciling data rather than flipping a switch. Give me rollback before that point and rollback after it as two different procedures with different owners, different durations and different customer communications. If any part of the design makes rollback harder than the county has been told, say so plainly here rather than in the risk register.