Your vendor will retire the model you built on. A migration playbook for model deprecations

On 15 June, requests to Claude Sonnet 4 and Claude Opus 4 on the Claude API started failing. Anthropic had announced the retirement on 14 April, named the replacements, and given the 60 days its policy promises. On 1 June, Google shut down Gemini 2.0 Flash and Flash-Lite. On 3 June, OpenAI told developers that its Evals platform and Agent Builder will close on 30 November, and on 28 May it said o3 leaves ChatGPT on 26 August and GPT-4.5 on 27 June. Claude Opus 4.1 was given notice on 5 June and goes on 5 August.

None of this is unusual. It is the normal rhythm of the industry now, and the rhythm is fast. A frontier model released today has a working life in your production system of roughly twelve to eighteen months before it is deprecated, and the notice you get is measured in weeks or months, not years. If your AI system was built on the assumption that the model underneath it would stay put, that assumption expires in 2026.

The notice you will actually get

The three main vendors have written policies, and they differ more than people expect.

Anthropic promises at least 60 days between telling customers with active deployments and switching a model off, and marks models Active, Legacy, Deprecated and Retired along the way. Active models carry a "not sooner than" floor rather than a date.

OpenAI promises at least six months for generally available models, three months for specialised variants such as codex or deep-research builds, and warns that preview models may go with as little as two weeks' notice. OpenAI also says safety or compliance concerns can shorten any of those.

Google's Gemini API treats preview models the same way, with a minimum two weeks, and describes its published shutdown dates as the earliest possible date rather than the scheduled one.

And if you consume any of these models through Amazon Bedrock or Google Vertex, those platforms run their own calendars. Claude Sonnet 4 was retired on the Claude API on 15 June and stays available on Bedrock until 14 October. A team running the same model in two places has two migrations.

I would argue the notice period is rarely the constraint. Sixty days is plenty if you have an evaluation set, a staging environment and a rollback plan. It is nothing at all if you have none of those, because the first forty days go on building them.

Why a migration is never a find-and-replace

Teams that have not done one before assume that swapping the model string is the migration. It is the first five minutes of it.

The new model formats differently. It may return markdown where the old one returned plain text, or put the answer at the end where the old one led with it, and your parser downstream will notice before you do.

Refusal boundaries move between generations, too. A prompt that reliably produced a summary of a contract clause may produce a hedge, or the other way round.

Tool use is the third place to look. Agents built on the old model's habits, such as how it sequences calls or how it phrases arguments, can loop or stall on the new one.

Then there is the tokeniser. Anthropic's newer models use an updated tokeniser, and the same input can map to more tokens than before. Your cost per task moves even when the list price does not.

Parameters get retired along with models. Anthropic has deprecated temperature, top_p and top_k on Opus 4.7 and later, returning an error when they are set. Code that worked for two years fails at the first request.

And it is faster or slower, which changes timeouts and, for anything user-facing, the feel of the product.

Every one of these is discoverable in a day with the right test set. Every one of them is a production incident without it.

The playbook

Pin, and inventory. Every production call should reference a dated snapshot ID, never an alias such as claude-opus-4-8 that can silently move. Then keep a list: which workload, which model ID, which platform, who owns it. Anthropic's console can export usage by key and model, which is the fastest way to find out what you are actually running.

Build the golden set before you need it. For each workload, 200 to 500 real inputs with the output you consider correct, and a grader that scores a candidate output against it. Some of the grading is exact match, some is a rubric, some is a second model as judge. This is the same evaluation harness we argue every production system needs on week one, and a deprecation notice is the moment teams regret not having it.

Shadow-run the replacement. Send a week of real traffic to both models, log both outputs, score both against the golden set and diff them. Read the cases where they disagree. That reading is the migration: it tells you which prompts to adjust, which parsers to update and which behaviours changed.

Fix, re-run, repeat. Adjust prompts and code until the new model's score meets or beats the old one on your set, not on the vendor's benchmark. Two or three rounds is typical.

Compare cost and latency on real traffic, using the shadow week's logs, and update the budget. A replacement that scores the same and costs 30 per cent more is still a decision somebody should make on purpose.

Cut over in stages, with a way back. Ten per cent of traffic, then half, then all, with the old model still reachable until its retirement date so you can revert. Keep the shadow logging on for a fortnight after.

Budget for it. One migration per workload per year is the realistic planning number. Put engineering time against it in advance so it does not compete with feature work when the email arrives.

What to ask for as a buyer

Do not run preview models in anything that matters. Two weeks' notice is not a migration window.

Ask vendors, and your own team, which platform each model is consumed through, because the calendar depends on it.

If you are buying an AI product rather than building one, ask the supplier which models it runs on, what its own migration process is, and whether the last one changed the product's behaviour. A vendor who cannot describe their evaluation set will pass every model change straight through to you.

And keep the golden set as an asset in its own right. It is what makes you able to change vendors as well as versions, which is the strongest negotiating position an AI buyer can have.

Frequently asked

How much notice do AI vendors give before retiring a model? Anthropic gives at least 60 days for publicly released models. OpenAI gives at least six months for generally available models, three months for specialised variants and as little as two weeks for preview models. Google's Gemini API gives preview models at least two weeks and publishes earliest-possible shutdown dates for stable ones. Amazon Bedrock and Google Vertex set their own dates for the same models.

What changes when you migrate an LLM application to a new model? Output formatting, refusal boundaries, tool-calling behaviour, token counts and therefore cost, accepted parameters, and latency. Anthropic has removed temperature, top_p and top_k on Opus 4.7 and later, for example. A swap of the model string alone will change outputs in ways a downstream parser or user will notice.

How do you prepare for a model deprecation? Pin every production call to a dated snapshot ID, keep an inventory of workloads by model and platform, and maintain a golden set of 200 to 500 real cases with a grader for each workload. When notice arrives, shadow-run the replacement on real traffic for a week, fix prompts until it matches the old score, compare cost, then cut over in stages with the old model still reachable.

Related reading

• Building evaluation harnesses for production AI systems
• Evaluation is not a phase-two upgrade
• What production AI actually costs

The model is the part of your system you own least. Treat every one as temporary, keep the test set that proves your product still works when it changes, and the next retirement notice becomes a fortnight of planned work rather than a quarter of surprises. That is the discipline our AI products team builds into every system from the first release.