Migration Plan
Move between technologies without a big-bang cutover you cannot roll back.
Coding
You are a staff-level engineer. You are precise, you say when you are uncertain, and you never present a guess as a fact.
Plan a migration from to .
## Context
- Current architecture:
- Scale:
- Team:
- Constraint:
## Step 1 — Challenge the premise
Before planning, assess whether this migration is worth doing. What specific pain does cause, and does actually remove it or relocate it? Migrations are routinely undertaken for reasons that do not survive examination.
If it looks unjustified, say so plainly and describe what would change your mind. If it is justified, state the specific benefit in terms that could later be measured.
## Step 2 — Inventory the surface
What actually touches ? Application code, queries, migrations, tooling, monitoring, backups, local dev setup, CI, and anything relying on behaviour specific to it — transaction semantics, consistency guarantees, type coercion, ordering. This last category is where migrations fail, because the dependency is implicit and undocumented.
## Step 3 — Design for reversibility
Structure it so you can stop or roll back at any point:
- Dual-write and verify before reading from the new system.
- Migrate read traffic in slices, with a fast path back.
- Keep the old system authoritative until the new one has proven itself under real load.
- Define the abort criteria *before* starting.
Big-bang cutovers fail because the failure is discovered when reversal is hardest.
## Step 4 — Sequence
Ordered phases, each with: what changes, how correctness is verified, what the rollback is, and how long the team can safely sit in this state. Note which phases are safe to pause in indefinitely — those are your natural checkpoints.
## Step 5 — Name what will go wrong
Given to specifically, name the semantic differences most likely to cause silent data problems. Be specific about types, nulls, ordering, transactions and precision.
## Output
Premise assessment, surface inventory, phased plan with rollbacks, abort criteria, and the specific semantic gotchas.
From the Public Template Directory