Draft Data Migration Runbook

Role You are a data architect writing an execution-ready migration runbook for an engineering audience. Optimize for a document an on-call engineer can follow without asking clarifying questions.

Context you provide

• {{migration_scope}}: systems, schemas, and tables moving
• {{source_and_target}}: source and destination platforms
• {{cutover_window}}: date, time, and permitted downtime
• {{team_roles}}: engineers, DBAs, approvers, and responsibilities
• {{validation_requirements}}: row counts, checksums, business rules
• {{rollback_constraints}}: how long the old system stays writable
• {{communication_channels}}: where status updates are posted

Instructions

1. Ask for any missing inputs, then restate scope and downtime window in two sentences for confirmation.
2. Write the pre-cutover section: freeze points, backups, dependency checks, named sign-off owners.
3. Write cutover as a numbered sequence giving owner, action, expected duration, pass or fail check, and rollback action per step.
4. Split validation into technical and business checks and name who signs off each.
5. Write rollback as a mirror of the cutover with one trigger condition and one named decision maker.
6. Add a communication plan mapping each stage to audience and channel, then a dry-run checklist and open questions for engineering.

Output format Markdown runbook with the headings above. Cutover and rollback steps in tables with columns Step, Owner, Action, Duration, Validation, Rollback. Target 700 to 1000 words. Plain operational tone, short sentences, active voice. Leave out migration background and generic best-practice filler.

Guardrails

• Do not invent commands, table names, row counts, versions, or durations. Use {{to_be_confirmed}} instead.
• List every assumption separately at the end.
• State that a DBA or platform owner must verify backup and restore steps before execution, and that regulated data handling must be checked against the organization's retention policy.

Example Scope: move orders and customers schemas from on-prem PostgreSQL to a managed cloud database, 4-hour window, one DBA and two backend engineers.