Why Deprecation Notices Deserve a Permanent Slot in Your Routine
Every application that calls a hosted AI model has a hidden dependency: the model version behind the endpoint. Unlike a library you pin in a lockfile, a hosted model can be retired on the provider’s schedule, and the failure mode is abrupt. When Microsoft retires a model in its Foundry catalog, the documentation is unambiguous about what happens next: At 18 months from launch, all inference returns 410 Gone. A request that worked yesterday starts returning an HTTP 410 response, and depending on how your error handling treats that status, the workload may break silently, degrade, or fail loudly in production.
The teams that avoid this outcome treat retirement notices the same way they treat security advisories: as a recurring, scheduled check rather than a one-off panic. That means knowing which lifecycle stage each pinned model version occupies, subscribing to the notification channels the provider actually uses, and validating state programmatically instead of trusting a cached mental model. The broader habit of reading every provider announcement as a dependency change, which we covered in this week-in-review on AI infrastructure changes, applies doubly to retirement schedules, because the consequence of missing one is a hard outage rather than a soft feature gap.
Understand the Lifecycle Stages Before You Interpret Any Date
Microsoft’s Foundry documentation defines five stages for every model in the catalog: Preview, Generally Available, Legacy, Deprecated, and Retired. Each stage carries different deployment rights. Preview models can change weights, runtime, and API schema, and are explicitly not recommended for production workloads. A Deprecated model still serves inference for existing customers, but new customers cannot create deployments, and the definition of an existing customer is subscription-scoped rather than tenant-wide. The Retired stage removes the model from service entirely.
Timeline commitments matter as much as stage names. Under the standard lifecycle, a generally available model’s retirement date is set programmatically at launch to eighteen months out, so there is no separate announcement event to wait for. At twelve months from launch the model enters the Deprecated phase, the replacement becomes available in global standard roughly ninety days before retirement, and provisioned-region availability of the replacement arrives about thirty days before retirement. Some partner models follow a shorter twelve-month lifecycle, so reading the specific schedule for each model family is essential rather than assuming one universal clock.
Notification lead times are contractual enough to plan around. For generally available models, Microsoft states that the retirement notice arrives at least 60 days before retirement, sent to subscription owners with active deployments. For preview models, the notice period is at least thirty days, and preview deployments are either force-upgraded to a replacement or terminated, with no option to remain on a retiring preview version.
Wire Up the Notification Channels That Actually Fire
Passive discovery is the enemy here. If you only learn about a retirement when a colleague forwards an email, your lead time collapses. Microsoft documents two active channels. First, email is sent automatically to subscription owners with active deployments. Second, Azure Service Health publishes advisories for affected subscriptions, and the documentation walks through the exact filter: go to Service Health, then Health advisories, filter by Azure OpenAI Service, and create an alert rule for email, text message, or webhook notifications. Notably, there is no separate Microsoft Foundry service name in Service Health, so the alert must target Azure OpenAI Service specifically.
Two operational details deserve emphasis. Automatic upgrades are managed for Global Standard, Data Zone Standard, and Standard deployment types on a rolling, region-by-region basis, with the schedule published in advance. But provisioned capacity is different: Provisioned deployments are NOT auto-upgraded. Provisioned customers must manually migrate to the replacement model. If your workload runs on provisioned throughput, nobody else will move it for you. You also control upgrade timing on your own deployments through the versionUpgradeOption property, which supports upgrading when a new default version is available, upgrading only at retirement, or never auto-upgrading, in which case the deployment stops working at retirement. And if you were hoping to negotiate, the FAQ is blunt: retirement dates are not extendable, and no exception process exists.
Check State Programmatically and Plan the Migration With Evidence
Documentation pages lag reality, so the durable habit is a scheduled API check. Microsoft exposes lifecycle fields via the Models API at the subscription scope, returning lifecycleStatus, deprecation.inference, deprecation.fineTune, and per-SKU deprecationDate values as ISO dates. The terminology trap is real: a model that the docs list as “Deprecated” (still works, blocked for new customers) appears in the API as lifecycleStatus: “Deprecating”, while the API value “Deprecated” actually means the model is retired and no longer serves inference. To classify a model correctly, check both the status field and the date, treating any inference deprecation date in the past as fully retired regardless of status lag.
Migration planning should not wait for the provider to name an official replacement, which Microsoft selects approximately ninety to one hundred twenty days before retirement. Evaluate candidate models against your own prompts and representative data, comparing quality, latency, and cost together rather than relying on public benchmarks alone. Before switching traffic, confirm API compatibility, feature support, deployment-type and regional availability, capacity, and quota. Fine-tuned models follow a separate two-phase schedule for training and deployment retirement, so any custom checkpoints need their own tracked dates.
Finally, close the loop with evidence, the same discipline we recommend in the small-workload cloud pricing review: save the primary schedule URL, record the currently deployed provider, interface, model ID, and service tier, and keep a rollback route before expanding traffic. Build a simple inventory of every pinned model version, check its lifecycleStatus on a weekly cadence, and alert when a deprecation date falls inside your migration window. Deprecation tracking is not a heroic effort; it is a small, boring, repeated check that keeps your workload from meeting the 410 response it never asked for.