Your LLM Model Is Being Retired: The Migration Playbook (2026)
When your LLM model is being retired, the playbook is short: find every place the old model name appears, pick a replacement, re-test on it because a different model gives different outputs, and update before the hard date, after which calls fail. Notice windows can be as short as about 60 days, so treat a retirement date as a real deadline.
Most of what you will find when you search this problem is written for developers: changelog entries, API migration guides, and version tables. If you run a business that uses an AI feature but you did not build it yourself, none of that tells you what to actually do. This is the plain-language version. It works whether you touch the code or you are handing the job to whoever does.
We keep our own deprecation calendar - more than 70 retirement dates across the major providers, on four per-provider pages - and the pattern is consistent. A retirement is announced, a hard date is set, and on that date the old model stops answering. The four steps below are the whole job. Do them in order and finish before the date.
Find every place the old model name appears. The model name is a short string of text, and it hides in more places than you expect: application code, configuration files, environment variables, and saved prompt templates all reference it by name. Search your whole setup for the exact model id and write down every hit. If another team or a contractor built the feature, ask them for the same list. The one reference you miss is the one that breaks on the hard date, so this step is worth doing thoroughly rather than from memory.
Choose a replacement model. Providers retire an old model because a newer one exists, and usually there is a direct successor in the same tier - a comparable size and price point. Pick that, or a comparable model from another provider if you are switching vendors anyway. The goal is to match the capability level you actually use: do not jump to the most powerful model out of caution and quietly triple your bill, and do not drop to a cheaper tier that cannot do the job. If the provider names a recommended migration target, that is your default choice.
Re-test on the new model. This is the step people skip, and it is the one that bites. A different model gives different outputs, so changing one line in your config is not enough to call the job done. Re-run your real cases on the replacement - the actual prompts and inputs your business depends on, including the awkward edge cases - and compare the results against what the old model produced. Wording changes, formatting shifts, and a prompt that was tuned for one model can behave differently on another. Better to find that on your test cases than in front of a customer.
Update before the hard date. Once you have a replacement you trust, ship the change and confirm it is live in production. Do this with time to spare, not on the deadline. After the hard retirement date, calls to the old model fail outright, so a swap you meant to do "next week" becomes an outage if the date arrives first. Put the date on a calendar, work back from it, and treat it like any other hard deadline your business cannot miss.
That is the entire migration. It is not complicated, but it is time-boxed, and the box can be smaller than you think. To see how the dates line up across providers, our deprecation calendar lists every announced retirement in one place.
How much warning do you actually get?
It varies by provider, and you should not assume generous notice. Some providers give many months between an announcement and the hard date; others give as little as about 60 days. There is no industry-wide standard, so a policy that worked with one vendor tells you nothing about the next. The safe assumption is the short end: plan as if you have roughly two months, and treat anything more as a bonus rather than the norm.
The practical consequence is that you cannot wait to be told twice. A single announcement, buried in a changelog or a dashboard banner, may be all the warning there is. If your business relies on a model, the retirement date needs to reach you the day it is announced, not the week the model goes dark. That is exactly the gap a maintained deprecation calendar closes - it turns a scattered set of provider notices into one list of dates you can plan around.
What breaks if you ignore a retirement date?
On the hard date, API calls to the retired model start failing. The request goes out, the provider no longer serves that model, and an error comes back instead of an answer. Whatever feature depended on it stops working at that moment. This tends to break loudly rather than silently: the app throws errors, a page shows a failure, or a workflow halts, so you notice quickly. That is better than the alternative of wrong answers you do not catch.
The exception is if you built a fallback. Some setups automatically route to a default model when the primary one fails, which keeps the app running but quietly changes which model is answering - and, as step three explains, a different model gives different outputs. So the failure mode is usually a loud outage, occasionally a silent quality shift, and rarely nothing at all. Either way the fix is the same migration above, done before the date instead of after. If you also keep hitting walls before the retirement even arrives, see why an AI agent hits usage limits.
FAQ
Will my app break silently or loudly?
Loudly, usually. Once the model is retired, calls to it return errors rather than wrong answers, so you notice fast - the feature fails visibly instead of quietly misbehaving. The one exception is a silent fallback to a default model, which keeps the app running but swaps in a different model behind the scenes and can mask the problem until someone spots the changed output.
Can I stay on the old model?
Sometimes, by request for extended access, some providers will keep a retiring model available to you for a while. But that is a deferral, not a fix. The model is still going away; you have only bought time. Use the extra weeks to run the migration steps and move off cleanly, not to put off the work until the extension itself expires and you are back at the same deadline.
How do I hear about retirements early?
Track a maintained deprecation calendar rather than watching every provider changelog yourself. Retirement dates are announced in scattered places - dashboards, docs, emails - and it is easy to miss one. A single source that collects the dates across providers gives you the lead time to migrate calmly, on your schedule, instead of discovering a hard date the week your feature stops working.