Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Prepare a development-only migration for [specific schema change] using the project's migration workflow and installed database version. Describe the old and new read and write contracts, including existing rows and any period when both application versions may run. Prefer an additive expansion, a bounded backfill with verification, and a later contraction when that sequence fits the requirement. Inspect the actual locking and transaction behavior of each database operation. Create fixtures with valid legacy rows, null values, duplicates, and a conversion failure. Test forward migration, interruption recovery, and the earlier application's behavior during the compatibility window. Name the last point where rollback preserves all required information. If contraction discards information, document restoration or a forward repair instead of inventing a lossless down migration. Return the exact development checks, deployment order, and recovery evidence.Make this prompt yours
Use when schema and application releases overlap. Reversing DDL is not necessarily sufficient to recover transformed or discarded data.
You might also hear
- expand contract
- reversible migration
- backfill
- schema compatibility
- data loss boundary
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Limited: Original instructional template; not executed. Schema expansion/backfill/contraction is conditional advice; the prompt correctly asks for actual operation locks, old/new compatibility, and information-loss recovery rather than promising lossless down migrations.