Two different things can happen
A provider can take your model away in two ways, and the two call for completely different preparation.
One is retirement: from a given date the model cannot be called and the request comes back as an error. That is unpleasant but honest — you know about it immediately. The other is the quiet swap: the model's name stays, but an updated version runs behind it, and the output shifts imperceptibly. That is the one that goes unnoticed for months.
The loud case: retirement
The large providers run a lifecycle for models: active → legacy → deprecated → retired. A deprecated model still works, but it already has a date.
Common practice is at least 60 days' notice for publicly released models, by email and in the documentation. One large provider withdrew several models this way during 2026, each with a named successor. And for active models a "not sooner than" date is published in advance — so you can check how long what you are using is safe for.
Two tasks follow from that, and both take five minutes: subscribe to the notifications, and check the deprecations page every quarter. That is enough to keep the 60 days from turning into three.
The quiet case, which is more dangerous
If your code uses a "latest"-style model name with no version, the provider can update underneath you at any time. Nothing errors. The call completes, the answer arrives, the system is green.
Only the output has changed. Longer. Formatted differently. One field missing. More cautious on a borderline question. If you process answers in an automated flow, this goes unnoticed for days or weeks, because everyone assumes that one case was just odd.
The defence is simple: pin the exact version in production, not the floating name. A floating name is convenient during development; in production it is a risk.
Six preparations you can make now
None of them is much work, and all six pay off when trouble comes:
- A pinned version in production. The model name should carry an exact version.
- The model name in one place. A configuration value, not scattered across twenty places in the code. Switching is then one line.
- A twenty-task test set, with written good answers. This is the same set you use for choosing a model.
- Saved sample outputs. The good answer as it was then, saved — that is what you will compare against. A prompt library entry has a field for exactly this.
- A second provider within reach. You do not have to use it; it is enough that the call format and the access exist. That is what a model router is for.
- An owner and a date. Someone the deprecation email reaches, who looks at it once a quarter.
What typically breaks
On a model change it is not "intelligence" that changes but five very prosaic things:
- The shape of the output. The same request produces a differently structured answer — different headings, different list, different order.
- The length. The new model is more or less verbose, and if you built on a character limit, that slips.
- The tone. It becomes more formal or more casual, and no longer fits your template text.
- The refusal boundary. What used to go through becomes questionable, or the other way round.
- The reasoning default. If the new model thinks more by default, both the response time and the bill grow without you having changed anything.
The migration recipe
Once the notice arrives, four steps, and it need not take more than half a day:
- Run the twenty tasks on the old and the new model, with the same prompt.
- Compare against the saved outputs, not against your memory. Write the differences down.
- Fix the prompt, do not go hunting for another model. Most differences come down to the format and length request, which one sentence can restore.
- Run both in parallel for a few days before going live, if you can. Comparing the two outputs is the only real test.
If the new model gets as many or more of the twenty right, you are done. If it gets fewer, then the problem is not the model but a prompt that was tuned to the old one — and that is fixable.
When it must not change at all
There are places where change itself is the problem: an audited process, a long-term contractual commitment, research where reproducibility is a requirement.
There a closed model is structurally the wrong choice, because retirement is not your decision. Open-weight models give a real advantage here: what you downloaded will run exactly the same way in five years. In exchange the operations are yours — but the question here is not price, it is whether the thing is possible at all.
What to take away
Retirement is loud and manageable; the quiet update is the real risk. The defence in production is a pinned version, a twenty-task test set and saved sample outputs — with those, migration is half a day. Where change is not permitted at all, a downloaded open-weight model is the only structurally correct answer.