Migrations & Rollouts
Staff-level AI migration playbooks: provider swaps, monolith-to-agentic decomposition, model-version upgrades, and zero-downtime component swaps under one safe shadow → canary → ramp → rollback pattern.
Last updated
After this section you can
- Apply the universal AI-migration pattern (shadow to canary to ramp to rollback-ready) as phase gates, and explain why probabilistic outputs make equivalence an eval-scoring question rather than a byte diff
- Run a provider migration end to end: abstract providers behind one interface, handle prompt-portability and output-schema drift, gate the cutover on a shadow dual-run eval, ramp by percentage, and roll back with a flag flip
- Decompose a mega-prompt into a planned agent using the strangler-fig approach, keep the monolith as a per-intent fallback, and gate on task-success and cost-per-resolved-task instead of latency
- Ship a model-version upgrade and a zero-downtime component swap safely, including the golden-set eval gate and the embedding-reindex trap
Migrations & Rollouts at Staff Scope
The four migrations that actually scare a production AI team — swapping providers, decomposing a monolith into an agent, upgrading a model version, and hot-swapping a component — each run under one safe pattern: shadow, canary, ramp, rollback-ready.
Classic migrations have a comforting property: you can diff the old and new outputs byte-for-byte and prove they match. AI migrations don’t. Swap Sonnet 4.5 for Sonnet 5 and the same prompt returns a different string that may be just as correct, subtly worse, or confidently wrong — and the API returns 200 either way. So “is the migration safe?” is never a byte-equality question; it’s an eval-scoring question. This section is four playbooks for the migrations you will actually be asked to run, each with the trigger, the risk, a step-by-step rollout, how you verify safety, and the rollback plan.