Anthropic retires the Claude Opus snapshot your service pins — how do you run the migration?

## What retirement actually means A dated Opus snapshot is immutable but not eternal. Anthropic publishes deprecation notices with a retirement date, and after that date a request naming the retired model does not quietly get served by something newer — it fails. That is the correct design, because a silent substitution would swap the weights under a production workload without anyone noticing, but it means the deadline is real and a missed migration is an outage, not a degradation. The first instinct of many teams — switch to a floating alias so this can never happen again — trades a scheduled, testable migration for an unscheduled, untested one. It converts a date you control into a surprise you do not. ## Step one: inventory Model identifiers sprawl. Beyond the obvious service config there are usually batch and offline jobs, evaluation harnesses, notebooks that became load-bearing, infrastructure-as-code defaults, per-tenant overrides, feature-flag payloads, and documentation and runbooks that will send someone down the wrong path later. Grep the organisation, not the repository. The output of this step is a list with an owner per entry, because the migration's real cost is coordination, not code. This is also the moment to notice how many distinct pins you carry. A fleet with one logical name resolving to one ID migrates in an afternoon; a fleet where twelve teams each chose their own is where the schedule goes. ## Step two: measure before you change anything Run the successor snapshot against a golden set that reflects your traffic — real prompts, real documents, real tool schemas — and diff against the incumbent. Aggregate quality scores are the least informative signal here. Watch instead for: - **Format drift.** Added preambles, changed heading or list style, fenced output where bare JSON was expected. Anything downstream that parses text is where breakage concentrates. - **Tool-call behaviour.** Different eagerness to call, different handling of optional arguments, different batching per turn. In an agent loop this changes the number of round trips and therefore latency and cost, even when each call is individually valid. - **Refusal boundaries.** Prompts near the line can flip, creating a whole class of empty or hedged responses in one workflow while everything else looks healthy. - **Length and latency distribution.** Longer average responses move p95 and can trip timeouts that were comfortable before. Record these as an artefact. The same harness is what you will run for the next migration, so the investment compounds. ## Step three: fix in the right layer Regressions belong in prompts, output schemas and parsers — the layers you own — not in more elaborate pinning. If a downstream parser only worked because a particular build never emitted a preamble, the parser was always fragile and the migration merely revealed it. Prefer structural fixes: explicit output contracts, tolerant parsing, tool schemas that make the required arguments unambiguous. ## Step four: roll out like a dependency upgrade Flag or percentage canary, old pin still reachable, rollback as a config revert rather than a redeploy. Watch business-level metrics — task success, human-escalation rate, downstream error rate — because model regressions rarely show up as HTTP errors. Ramp over days, not minutes, and keep the ability to hold at a partial split. Budget the calendar backwards from the retirement date with real slack. Aim to be fully migrated well before it, so that discovering a regression late leaves room to fix rather than forcing a bad choice at the wall. ## Step five: fix the governance, not just this migration The organisational answer is a single source of truth: a logical model name owned by one team, mapped to a concrete pinned ID, consumed by everyone else. Then a retirement is one mapping change plus one eval run, and the inventory step disappears. Pair it with a policy on who may change a pin and what evidence gates the change, and subscribe someone to the deprecation announcements so the notice reaches a human with authority rather than a shared mailbox. ## What good judgment looks like here The defensible position is not "always pin" or "always float" but "pin, with an owned, rehearsed upgrade path". Pinning without a migration muscle is how teams end up doing an emergency swap the week of the deadline with no evals at all — the worst of both strategies. Rehearse by moving a low-stakes workload to each new snapshot early: it keeps the harness honest and surfaces format drift long before the clock matters.