How Azure Retires AI Models

Part of a series on running AI workflows across model providers — this one is about ongoing model retirement, not a one-time API sunset.

The previous article covered a one-time API retirement. This one covers something different and, in a way, more important to understand if you're running anything in production on Azure AI: models themselves go through a structured, ongoing retirement lifecycle, on a documented schedule, whether or not any single dramatic announcement is happening.

The five lifecycle stages

Every model available through Azure AI moves through a defined sequence:

1. Preview — experimental, may change or be removed without the longer notice periods GA models get.

2. Generally Available (GA) — production-ready, with fixed weights and a stable API.

3. Legacy — a newer model exists; migration is recommended but the model still works for new and existing deployments.

4. Deprecated — existing deployments keep working; new customers can no longer deploy it.

5. Retired — fully removed; every request against it returns a 410 Gone error.

A model doesn't disappear suddenly — it moves through a defined sequence with real notice at each stage.

The notice periods, concretely

For GA models, Microsoft commits to an 18-month lifecycle from launch to retirement, with a minimum 60-day notice before the actual retirement date, delivered via email to subscription owners and through Azure Service Health advisories. At the 12-month mark, a model typically moves into "Deprecated" status. In the run-up to retirement, a replacement model is generally declared and made available roughly 90 days ahead in Global Standard deployments, and roughly 30 days ahead in provisioned regions.

Preview models get a shorter runway — at least 30 days' notice — and there's no option to simply stay on a retiring preview model. It either gets force-upgraded to a newer version or retired outright with no replacement offered.

Third-party models available through Azure (Anthropic, DeepSeek, Mistral, and others) follow a 12-month lifecycle rather than the 18-month schedule GA Azure OpenAI models get — a meaningful difference if you're planning around one of those specifically.

What actually happens at the retirement date depends on your deployment type

This is the detail that catches teams off guard: Standard, Global Standard, and Data Zone Standard deployments are automatically upgraded to the replacement model on a rolling basis as the retirement date approaches. You can control this behavior through a versionUpgradeOption setting — upgrade as soon as a replacement is available, upgrade only once the current version actually expires, or disable auto-upgrade entirely (in which case the deployment simply stops working at retirement, with no automatic fallback).

Provisioned deployments work differently and don't get this safety net. They are not automatically upgraded. Migrating a provisioned deployment requires manual action — either an in-place migration, where Azure handles traffic migration over a 20–30 minute window with no downtime, or a side-by-side migration, where you stand up a new deployment, validate it, cut traffic over, and remove the old one yourself.

The same retirement date means two very different amounts of required action, depending on which deployment type you chose.

Where to actually check this instead of guessing

Azure exposes deployment lifecycle status through its management API — querying a resource's models endpoint returns lifecycleStatus, a deprecation.inference field, and per-SKU deprecationDate values you can check directly, rather than relying on remembering an email that arrived months earlier. Azure Service Health advisories are the other reliable channel — worth setting up an alert specifically for this rather than checking manually.

A use case that shows why checking proactively matters

A team running a provisioned deployment for a latency-sensitive production feature assumed, reasonably given how other cloud services often behave, that Azure would handle their model's eventual retirement automatically the way it does for standard deployments. It didn't — provisioned deployments require manual migration, and the team only discovered this when a Service Health advisory arrived with a concrete date attached. Because they caught the advisory with enough lead time, they had room to run an in-place migration calmly rather than scrambling after the fact. The lesson wasn't that Azure failed to warn them — the notice periods are real and were followed — it was that assuming their deployment type behaved like the more common standard tier turned out to be the wrong assumption.

What this means for a DNotifier-based Azure integration

None of this lifecycle management is something DNotifier automates away — a deployment retiring on Azure's schedule still needs the same attention whether you're calling it directly or through sendAI() with provider: "azure_ai". What DNotifier does simplify is the blast radius: if a deployment name changes or a model gets replaced, updating the provider configuration in one place propagates to every workflow that calls it, rather than requiring you to hunt down every direct call in your codebase.

Frequently asked questions

Do I need to do anything if I'm only using Standard or Global Standard deployments?

Less than with provisioned deployments, since auto-upgrade can handle the transition — but it's still worth reviewing your versionUpgradeOption setting rather than assuming the default behavior matches what you want.

How far in advance will I actually know a model I depend on is retiring?

At minimum 60 days for GA models, often longer given the 12-month "Deprecated" stage that precedes it — set up a Service Health advisory alert rather than relying on catching an email.

Does this lifecycle apply to models from providers other than OpenAI, inside Azure?

Yes, with a shorter 12-month lifecycle for third-party models (Anthropic, Mistral, DeepSeek, and others) compared to the 18-month schedule for Azure OpenAI's own GA models.

Is a "Deprecated" model still safe to use in production?

It continues working for existing deployments, but new deployments are blocked and retirement is coming — treat "Deprecated" as the point to actively plan migration, not a status to ignore until "Retired" actually arrives.

The Bottom Line

Next in this series: a practical framework for choosing which Azure deployment actually fits a given task, rather than defaulting to whichever one was set up first.

Read part five: Choosing a Deployment on Azure AI. Explore dnotifier.com.