planning-migration-strategy

Design a migration that preserves data integrity and compatibility What we migrate (schema/data/API) and why Data volume, time windows, downtime constraints Backward-compatibility requirements expand/contract dual-read / dual-write backfill in background versioned API / events </common_patterns> Identify migration objects and dependencies (tables, indexes, consumers) Select a migration pattern and justify it (why it fits the constraints) Split into phases: preparation -> compatibility -> transfer -> cutover -> cleanup Define integrity/correctness verification (checksums, counts, sampling) Explicitly describe compatibility during the migration window (which versions coexist)

Migration objects

Chosen pattern + rationale

Phases

Compatibility window

Data verification

</output_format> Data integrity verification exists (not only "ran the migration") Compatibility during the migration window is described explicitly </quality_rules>