Split a long-running migration into an online sequence
A migration that would lock a large table, split into steps that each deploy safely on their own.
The ticket
Split a long-running migration into a backwards-compatible online sequence.
Acceptance criteria
- Each step is deployable on its own
- Old and new application code both work against every intermediate state
- No step holds a lock for an unacceptable time
- The sequence and its order are documented in the description
What lands as proof
Each intermediate state tested against both the old and the new application code, which is what makes the sequence safe.
Why teams defer it
- It takes four deploys instead of one, which looks like more work rather than less risk.
- Reasoning about every intermediate state is genuinely hard, and getting it wrong causes an outage rather than a bug.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: split a long-running migration into a backwards-compatible online sequence. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means each step deploys alone, old and new code both pass against it, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops for the plan, and the review bar is raised afterwards so that smaller suggestions block the merge too, not only serious findings.