Your LLM model is being deprecated: the migration plan

Every quarter, at least one model your product depends on enters a retirement window. On June 11, 2026, OpenAI notified developers that older GPT-5 and o3 snapshots would be removed from the API on December 11, 2026. Anthropic retired Claude Sonnet 4 on its own API on June 15, 2026, while Amazon Bedrock set a different end-of-life for the same model. If your AI feature pins a single model string and you find out through a sunset email, you are already behind.

This is the migration playbook we run for SaaS teams so a deprecation notice becomes a scheduled chore, not a production incident.

Why a model sunset breaks features that "just worked"

A deprecated model does not degrade gracefully. On the retirement date the endpoint starts returning errors for that model string, and any request still pinned to it fails. Teams get caught because the model id is usually hardcoded in three or four places: the main generation call, a cheaper summarization call, an eval script, and a fallback path nobody has read in months.

The notice periods vary more than people expect. Anthropic commits to a minimum of 60 days on publicly released models. OpenAI ranges from about three months for specialized snapshots to as long as 18 months for foundational models, but a recent batch of retirements landed with as little as two weeks of usable warning for some teams. Partner platforms make it worse: Anthropic's dates apply to its own API, while Bedrock and Google Cloud publish their own schedules, so the same model can have two different death dates depending on where you call it.

The second failure mode is quieter. You swap the model id, the endpoint works, and your outputs shift. A new model version re-tokenizes, re-weights, and changes formatting habits, so a prompt tuned for the old model can start returning slightly different JSON, longer answers, or a different refusal rate. Nothing throws an error. The feature just gets worse, and you find out from support tickets.

The migration plan we actually run

1. Build a model inventory before you need one

You cannot migrate what you cannot find. Grep the codebase for every model string and route them all through one place, a single config value or a thin gateway, so the next swap is one line instead of a scavenger hunt. Record where each model is used, what it costs, and how latency-sensitive that call is. This inventory is the difference between a 30-minute change and a two-day one.

2. Subscribe to the deprecation feeds and put dates on a calendar

Both major vendors publish a deprecations page. Read it monthly, not when the email arrives. Put every retirement date your inventory touches on a shared calendar with a four-week lead reminder. If you run on Bedrock or Vertex, track those schedules separately, because they are not the same as the vendor's own dates.

3. Keep a frozen eval set so you can compare candidates

You need a way to answer "is the new model as good as the old one" with data, not vibes. A small frozen set of real inputs with known-good outputs lets you run the candidate model and diff the results. This is the same asset that protects you from silent regressions on any model update, which is why we treat an eval suite that runs in CI on model updates as table stakes for any production feature.

4. Migrate in shadow, not in prod

Run the candidate model alongside the current one on live traffic without showing users the new output. Log both, compare cost, latency, and eval scores, and only cut over when the new model wins or ties. This is the same discipline behind a staged rollout with a kill switch: you want the ability to fall back instantly if the new model misbehaves in ways your eval set missed.

5. Re-tune the prompt for the new model, do not assume it transfers

Prompts are model-specific. Budget time to adjust formatting instructions, few-shot examples, and temperature for the new model, and re-run your eval set after each change. Version the prompt alongside the model id so you can tie an output-quality change to the exact prompt and model that produced it. If you are not already doing prompt versioning in production, a migration is the moment it starts paying for itself.

Reduce how often this hurts

The teams that barely feel deprecations share two habits. They route every model call through one abstraction so switching providers or versions is a config change, and they keep at least one tested fallback model wired in. When you already have model routing in place for cost reasons, deprecation resilience comes almost for free, because the plumbing to send a request to a different model already exists. Pair that with a documented fallback for when a model fails and a sunset date becomes a routing-table edit.

None of this requires a rewrite. It requires an inventory, a calendar, a frozen eval set, and one abstraction layer. Set those up once and every future deprecation is a planned afternoon instead of a fire.

Frequently asked questions

How much notice do OpenAI and Anthropic give before removing a model?

Anthropic commits to a minimum of 60 days for publicly released models. OpenAI's windows range from about three months for narrow snapshots to 18 months for foundational models, though some 2026 retirements gave teams closer to two weeks of practical warning. Amazon Bedrock and Google Cloud set their own end-of-life dates that can differ from the vendor's.

Can I just swap the model id and move on?

Sometimes, but not safely without checking. A new model re-tokenizes and changes output habits, so a prompt tuned for the old one can return different JSON or longer answers with no error raised. Run the new model against a frozen eval set and compare before you cut over.

What is the single highest-impact thing to do first?

Route every model call through one config value or gateway. Once the model id lives in one place, every future migration is a one-line change instead of a hunt through the codebase, and you can add a fallback model without touching feature code.

Boundev ships and maintains production AI features for US SaaS teams, including the migration work when a vendor retires the model underneath you. If a deprecation notice is sitting in your inbox, that is the kind of task we turn around in days.