migration
Migration without a cliff
The candidate path earns traffic through shadow evidence, narrow cohorts, and exercised rollback—not a flag-day rewrite.
- Question
- How does the old system remain a safe exit while the new one proves itself?
- Binding decision
- Reads, writes, cache, replay, ownership, and frontend cutover remain independently reversible.
- Owner input
- Production rollout authority, cohort size, rollback window, and deletion date require explicit owner approval.
- 0Freezeobserve
- 1Skeletonbuild + gate
- 2QuestDBbuild + gate
- 3Redisbuild + gate
- 4Backfillbuild + gate
- 5Fanoutbuild + gate
- 6Frontendbuild + gate
- 7Cold tierbuild + gate
- 8Cutoverprove + release
Compare before serving
The candidate first dual-runs canonical Nautilus values without changing client reads, then shadow-writes QuestDB and compares coverage, counts, hashes, and watermarks. Representative history queries are diffed before internal users or symbols enter a canary cohort.
- Generation and resync parity precede frontend cutover.
- Cache, replay, and multi-replica ownership activate independently.
- Expected and 10x profiles gate each expansion.
EvidenceExecPlan Phase 8.
Deletion is a separate decision
Every flag is rolled back in rehearsal before advancing. Old coordination paths, flags, tests, and docs are deleted only after the rollback window and retention, entitlement, security, and data-rights approvals.
- A failed gate stops cohort expansion immediately.
- Shadow data and comparison evidence remain available for diagnosis.
- Deletion never shares a commit with the first production cutover.
EvidenceExecPlan Phase 8 rollback and stop conditions.
mise x -- task migration:rollback-drillAcceptance target: Every feature flag restores the last proven state within accepted RTO/RPO.