Zero-Downtime Migration Planner

What it does

Generates a phased migration plan for moving from one system to another — database schema changes, API version upgrades, service replacements, or infrastructure moves. The plan includes the parts that engineers usually forget until they’re mid-migration: rollback procedures, data integrity verification, and the specific order of operations that avoids downtime.

The Prompt

Create a migration plan for the following change.

Migration type: [DATABASE SCHEMA / API VERSION / SERVICE REPLACEMENT / INFRASTRUCTURE MOVE / OTHER]

Current state:
[DESCRIBE WHAT EXISTS NOW — schema, service, infrastructure. Be specific: "PostgreSQL 14, users table with 50M rows, 3 services reading, 1 writing"]

Target state:
[DESCRIBE THE END STATE — what it should look like after migration]

Constraints:
- Downtime tolerance: [ZERO / MAINTENANCE WINDOW OF X HOURS / DEGRADED SERVICE ACCEPTABLE]
- Rollback requirement: [MUST BE ROLLBACK-SAFE WITHIN X HOURS / BEST EFFORT / ONE-WAY IS ACCEPTABLE]
- Data volume: [APPROXIMATE SIZE — rows, GB, throughput]
- Team: [HOW MANY ENGINEERS, AVAILABILITY — dedicated sprint or part-time]

Generate the plan:

## 1. Migration Strategy
Choose and justify the approach: big bang, parallel run, strangler fig, expand-contract, blue-green, or dual-write. Explain WHY this strategy fits the constraints. If the constraints make zero-downtime impossible, say so explicitly.

## 2. Pre-Migration Checklist
Tasks that must complete BEFORE any data moves:
- Schema/infrastructure preparation steps
- Monitoring and alerting setup for the migration itself
- Runbook creation
- Communication plan (who needs to know, when)
List each with estimated time and owner role.

## 3. Phase Plan
Break the migration into discrete, independently deployable phases. For EACH phase:
- What changes (code, schema, config, infrastructure)
- Deployment steps in order
- Verification: how to confirm this phase succeeded (specific queries, health checks, metric thresholds)
- Rollback: exact steps to undo this phase if verification fails
- Duration estimate
- Risk level: LOW / MEDIUM / HIGH

## 4. Data Integrity Verification
Specific checks to run after migration completes:
- Row count comparisons
- Checksum or hash verification approach
- Business logic validation queries (e.g., "sum of all account balances should match")
- Edge case checks (nulls, Unicode, timestamps at boundaries)

## 5. Post-Migration Cleanup
What to remove after the migration is verified stable:
- Old schema/tables/columns
- Feature flags or dual-write code
- Monitoring adjustments
- Suggested bake time before cleanup (how long to keep the old system available)

## 6. Risk Register
Top 3 risks specific to this migration:
- Risk description
- Likelihood: LOW / MEDIUM / HIGH
- Mitigation already in the plan
- Contingency if mitigation fails

Usage Notes

• Be brutally specific in the “current state” section. “We have a users table” is useless. “PostgreSQL 14, users table with 50M rows, 12 columns, 3 indexes, written by auth-service at ~200 writes/sec” gives the model what it needs.
• The phase plan structure ensures each step is independently rollback-safe. If you can’t roll back a phase, you’ve scoped it too large.
• For database migrations specifically, add: “We use [MIGRATION TOOL — Flyway/Liquibase/Alembic/raw SQL]. Generate migration scripts in that format.”
• The data integrity section catches the class of migration bugs that pass all tests but corrupt data silently. Don’t skip it.
• Pair with the Architecture Review prompt if you’re unsure whether the target state is the right design.