Zero Downtime Migration

---
name: zero-downtime-migration
enabled: true
description: |
  Use when performing zero downtime migration — structured runbook for executing
  zero-downtime data and service migrations. Covers pre-migration validation,
  dual-write setup, incremental data sync, cutover orchestration, and rollback
  procedures to ensure continuous availability throughout the migration process.
required_connections:
  - prefix: aws
    label: "AWS (or cloud provider)"
  - prefix: datadog
    label: "Datadog (or monitoring tool)"
config_fields:
  - key: source_system
    label: "Source System"
    required: true
    placeholder: "e.g., legacy-postgres-cluster"
  - key: target_system
    label: "Target System"
    required: true
    placeholder: "e.g., aurora-postgres-v15"
  - key: migration_window
    label: "Migration Window"
    required: true
    placeholder: "e.g., 2026-04-01 02:00 UTC"
  - key: rollback_deadline
    label: "Rollback Deadline"
    required: false
    placeholder: "e.g., 72 hours post-cutover"
features:
  - DEVOPS
  - MIGRATION
---

# Zero-Downtime Migration Skill

Execute a zero-downtime migration from **{{ source_system }}** to **{{ target_system }}** scheduled for **{{ migration_window }}**.

## Workflow

### Phase 1 — Pre-Migration Assessment

```
PRE-MIGRATION CHECKLIST
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Source system inventory complete:
    - Schema version: ___
    - Data volume: ___ GB
    - Peak QPS: ___
    - Active connections: ___
[ ] Target system provisioned and validated
[ ] Network connectivity verified (source <-> target)
[ ] Schema compatibility confirmed
[ ] Application compatibility tested against target
[ ] Rollback procedure documented and tested
```

### Phase 2 — Dual-Write Configuration

```
DUAL-WRITE SETUP
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Change Data Capture (CDC) pipeline configured
[ ] Dual-write proxy or application-level writes enabled
[ ] Write conflict resolution strategy defined:
    [ ] Last-write-wins
    [ ] Source-priority
    [ ] Custom merge logic
[ ] Dual-write monitoring dashboards deployed
[ ] Write latency impact measured:
    - Baseline write latency: ___ms
    - Dual-write latency: ___ms
    - Acceptable threshold: ___ms
```

### Phase 3 — Historical Data Sync

```
DATA BACKFILL
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Backfill strategy selected:
    [ ] Batch ETL
    [ ] Streaming replay
    [ ] Snapshot + CDC
[ ] Backfill initiated — start time: ___
[ ] Progress tracking:
    - Tables/collections migrated: ___ / ___
    - Records processed: ___ / ___
    - Estimated completion: ___
[ ] Data integrity verification:
    - Row count match: [ ] YES  [ ] NO
    - Checksum validation: [ ] PASS  [ ] FAIL
    - Sample record comparison: [ ] PASS  [ ] FAIL
```

### Phase 4 — Shadow Read Validation

```
SHADOW READS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Shadow read traffic enabled (read from both, compare)
[ ] Comparison results over 24h window:
    - Total reads compared: ___
    - Mismatches found: ___
    - Mismatch rate: ___%
    - Root causes identified for mismatches: [ ] YES
[ ] Performance comparison:
    - Source P95 read latency: ___ms
    - Target P95 read latency: ___ms
[ ] Shadow reads running clean for ___h (target: 24h minimum)
```

### Phase 5 — Cutover Execution

```
CUTOVER
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Final sync lag < 100ms confirmed
[ ] On-call team briefed and standing by
[ ] Communication sent to stakeholders
[ ] Cutover initiated — timestamp: ___

Cutover steps:
[ ] 1. Pause application writes (< 5s window)
[ ] 2. Drain remaining CDC events
[ ] 3. Verify final consistency check
[ ] 4. Switch read/write endpoint to target
[ ] 5. Resume application writes
[ ] 6. Verify writes landing on target system

Total cutover duration: ___s
```

### Phase 6 — Post-Cutover Monitoring

```
POST-CUTOVER VALIDATION (4h window)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
T+15min:
[ ] Error rates within baseline
[ ] Read/write latency within SLO
[ ] No data corruption signals

T+1h:
[ ] All application features verified
[ ] Background jobs executing correctly
[ ] Replication healthy (if applicable)

T+4h:
[ ] Metrics stable across all dashboards
[ ] No customer-reported issues
[ ] Migration declared SUCCESSFUL / ROLLBACK NEEDED
```

### Phase 7 — Rollback (if needed)

```
ROLLBACK PROCEDURE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Trigger criteria:
- Error rate > 5% for 5 minutes
- Data corruption detected
- P95 latency > 3x baseline for 10 minutes

[ ] Switch read/write endpoint back to source
[ ] Re-enable CDC from target to source (reverse sync)
[ ] Verify source system accepting writes
[ ] Notify stakeholders of rollback
[ ] Schedule post-mortem

Rollback deadline: {{ rollback_deadline }}
```

## Counter-Rationalizations

| Shortcut | Counter | Why |
|----------|---------|-----|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |

## Output Format

Produce a migration execution report with:
1. **Migration summary** (source, target, timeline, data volume)
2. **Data integrity results** (row counts, checksums, mismatch analysis)
3. **Performance comparison** (latency, throughput before vs after)
4. **Cutover log** (exact timestamps, duration of write pause)
5. **Final status** (SUCCESS / ROLLED BACK) with follow-up actions