migration-plan

Plan the route from current to target in phases that each leave the system working. Read ./CONTEXT.md first; describe both states in the project's own domain language.

1. Pin down both ends. Current state (what actually runs, including the ugly parts) and target state. If the target itself is undecided, stop — route to design-doc or grilling first; a migration plan toward a vague target is fiction.
2. Bias to incremental. Default to strangler-fig-style coexistence: new and old running side by side, traffic/data moving over in slices. A big-bang cutover needs explicit justification (and a rehearsal plan).
3. Phase the work. For each numbered phase:
   • Scope — the slice that moves, and what explicitly stays on the old path.
   • Coexistence mechanism — routing, facade, dual-write/backfill, feature flag; name it.
   • Exit criteria — the measurable condition that ends the phase (a verify: step, not a date).
   • Rollback — the concrete way back if the phase fails, and what it costs.
4. Name the classic risks where they apply: data migration and backfill integrity, dual-write drift, contract/consumer breakage, freeze windows, the long tail of stragglers on the old path, and the danger of the coexistence layer becoming permanent — give each phase an owner condition for removing scaffolding.
5. Route onward. Capture the chosen strategy as an ADR (domain-modeling skill), break phases into tracker issues (to-tickets), and size them with the estimate skill if asked.

Prefer the smallest first phase that proves the mechanism end-to-end over a "foundations" phase that delivers nothing observable.