Your Model Provider Just Announced a Deprecation Date. Now What?

Quick answer

A forced model deprecation is a countdown, not a project you get to schedule on your own terms, so the playbook starts with triage, not evaluation. Within the first week: confirm the exact cutoff date, inventory every place the deprecated model version is called directly or indirectly, and run your existing eval suite against the two or three most likely replacement versions to get an early accuracy and behavior delta before committing to one. The goal for week one is not picking the final replacement, it is knowing how much runway you actually have and whether the safe default (the provider's suggested successor version) is good enough to buy time for a more deliberate choice later.

A deprecation deadline changes the shape of the decision, not just the timeline

When a company voluntarily switches LLM providers, the process, covered in migrating an AI agent between LLM providers, can be sequenced carefully: build the eval harness first, test the new provider in shadow mode, cut over gradually, keep the old provider as a fallback the whole time. A forced deprecation removes the most important lever in that process, which is time. You do not get to decide when the migration starts or, past a certain point, whether it happens at all.

That constraint changes what "good enough" means. A voluntary migration can wait for a replacement model that matches or beats the current one on every eval dimension. A forced migration often has to accept a replacement that is good enough on the dimensions that matter most, with a plan to keep improving it after the deadline rather than before.

Build the response plan in three phases

Phase one: confirm scope, not just the headline date. Deprecation announcements often apply to a specific model version, not the whole model family, and providers frequently offer a "recommended successor" that is meant to be closer to a drop-in replacement than a full-family jump. Confirm exactly which version is being retired, what the suggested successor is, and whether the deprecation is a hard cutoff (the old version stops responding entirely) or a soft one (rate limits and cost increases before an eventual hard stop).

Phase two: run your golden eval set against the successor immediately, even before you have decided on a final target. This is the single highest leverage thing to do early, because it tells you whether the provider's suggested successor is close enough to buy time. The methodology here is the same one described in building a golden evaluation dataset for your AI agent: a fixed set of representative real conversations with known-good outputs, scored consistently across model versions. If your eval set does not exist yet, building even a minimal version of it in week one is worth more than any other single action, because everything downstream depends on being able to measure the delta rather than guess at it.

Phase three: stage the cutover with a fallback window, not a single flip. Even under deadline pressure, avoid a hard cutover on the deprecation date itself. Route a small percentage of traffic to the new model version as early as the eval results allow, watch production behavior (not just eval scores) for at least a few days, and only ramp to full traffic once you have real usage data, not just offline eval data, backing the decision.

Update everything that assumes the old model's specific behavior

Model version changes are not just an API endpoint swap. Prompts tuned against the quirks of a specific model version, especially instruction-following style and formatting habits, often need adjustment after a version change. Track every prompt change made in response to the deprecation as its own version, using the discipline covered in versioning and rolling back AI agent prompts, so that if the new model version introduces a regression, you can isolate whether it came from the model change itself or from a prompt adjustment made alongside it. Conflating the two makes post-migration debugging much harder than it needs to be.

Treat the deadline as a forcing function to fix eval debt, not just a fire drill

Teams that already have a solid eval harness and clean prompt versioning treat a forced deprecation as a routine, if compressed, migration. Teams without either scramble to build both under deadline pressure while also trying to pick a replacement model, which is a worse position to be making an important decision from. If this is your first forced deprecation, the highest value long term outcome is not just surviving this one, it is having a real eval suite and versioning discipline in place before the next provider announcement arrives, because there will be a next one.

FAQ

How much notice do providers typically give before a hard model deprecation? It varies widely, from several months to, in some cases, a matter of weeks for smaller or preview model versions. Treat any deprecation notice as the actual deadline, not a soft suggestion, since providers do enforce hard cutoffs.

Is the provider's "recommended successor" always the right replacement? Not always, but it is almost always the right starting point for eval testing, since it is typically the closest match in capability and API shape. Use your own eval results to confirm or override that recommendation rather than assuming it automatically.

Should we build in a fallback to a second provider because of this? That is a reasonable long term response to a forced deprecation, but do not try to build multi-provider failover under the same deadline pressure as the migration itself. Handle the immediate deadline first, then treat provider redundancy as a separate, deliberately scoped project.

What if none of the successor models pass our eval bar? Escalate to the provider directly, since deprecation deadlines sometimes have quiet extension paths for enterprise accounts with a documented migration blocker. In parallel, start evaluating a different provider as a genuine contingency, not just the recommended successor.