Operations
AuraScore 81/100

Distributed Database Zero-Downtime Migration Cutover Checklist

Systematize database schema transformations, replication sync verification, and instant rollback procedures.

Use prior to executing complex schema migrations or storage re-platforming in high-throughput production environments. It guarantees operational safety, data consistency, and deterministic rollback triggers for database administrators.

Template

Role: Lead Database Operations Architect and Release Engineering Director

Context

  • Source database technology: {{source_database_engine}}
  • Target schema definition: {{target_schema_version}}
  • Maximum allowable replication lag: {{max_replication_lag_seconds}}
  • Scheduled execution window: {{cutover_maintenance_window}}
  • Data consistency validation query: {{data_integrity_validation_rule}}
  • Downstream application ecosystem: {{dependent_microservices}}

Task

Author a comprehensive operational cutover and contingency checklist for executing a zero-downtime database migration that ensures continuous data integrity, minimal replication lag, and explicit rollback readiness.

Method

  1. Establish pre-migration synchronization checks evaluating read/write replicas against {{max_replication_lag_seconds}}.
  2. Formulate schema backward-compatibility verification items for {{target_schema_version}} operating on {{source_database_engine}}.
  3. Outline step-by-step connection draining and dual-write verification for {{dependent_microservices}}.
  4. Design data integrity audit checkpoints using {{data_integrity_validation_rule}} across distributed partitions.
  5. Detail latency and lock-contention threshold monitoring steps throughout {{cutover_maintenance_window}}.
  6. Specify the point-of-no-return operational criteria for irreversible cutover commits.
  7. Detail deterministic rollback execution checks if replication or integrity metrics breach defined boundaries.

Constraints

  • MUST include explicit numerical thresholds for aborting the migration process.
  • MUST format checklist items using markdown checkboxes [ ] categorized by migration phase.
  • MUST NOT permit destructive DDL operations without an explicit dual-verification step.
  • Total checklist items across all phases must be between 18 and 24 items.

Output format

1. Pre-Cutover Synchronization & Readiness Phase

(6-7 discrete checks covering replication lag, backup validation, and connection pooling)

2. Live Cutover & Traffic Diversion Phase

(6-8 discrete operational commands covering dual-write validation, schema locking, and traffic routing)

3. Post-Cutover Integrity Verification Phase

(4-5 deep audit steps executing data integrity checks and latency validation)

4. Abort Criteria & Rapid Rollback Execution Checklist

(3-4 fast-fail operational checks to revert routing and re-establish primary state)

Self-review

  • Confirm all context variables ({{source_database_engine}}, {{target_schema_version}}, {{max_replication_lag_seconds}}, {{cutover_maintenance_window}}, {{data_integrity_validation_rule}}, {{dependent_microservices}}) are integrated.
  • Check that rollback procedures do not depend on data destroyed during forward migration.
  • Ensure each checklist item defines an observable operational metric.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

business-strategy
business-operations
software-engineering-debugging
database
migration
operations