Checklist
Write invariants before the migration
A migration can be perfectly formatted and completely wrong.
When it fits
- A transformation can produce syntactically valid output while breaking business rules.
When to avoid it
- Missing invariants create false confidence; involve domain owners where correctness depends on rules the implementation team may not know.
Checklist
- Each invariant states what must remain true, not how the script happens to work.
- The invariant can be checked automatically or with a defined inspection method.
- Pre-change baseline values are captured when comparison matters.
- Staged output is checked before commit.
- Authoritative post-change state is checked again.
Why it matters
Before running the change, write the properties that must remain true across it: uniqueness, required relationships, totals, allowed status transitions, referential links, permission boundaries or another domain invariant. Validate them on staged output and again after application. Prefer checks that fail loudly over manual visual confidence.
An example
A business-partner migration may require every active sales-area assignment to keep exactly one valid partner role mapping.
Check your result
A technically successful transformation still fails the gate when a declared business invariant is violated.
Keep this limit in mind
- Missing invariants create false confidence; involve domain owners where correctness depends on rules the implementation team may not know.
Connected ideas
Useful withStage the mutation before committing it
Evidence and sources
Google SRE's two-phase mutation pattern explicitly separates generating candidate changes from validating their correctness before applying them.
Validation rules must encode the invariants that actually matter; a passing schema check can still permit a semantically wrong change.
Improve and Optimize Data Processing Pipelines · Two-Phase Mutations