Why Deprecation Notices Arrive Quietly
AI model deprecations rarely arrive as a loud, single announcement. On Microsoft’s Foundry platform, for example, retirement dates are set mechanically rather than published as news. The documentation states plainly: “GA models that follow the standard lifecycle have their retirement date set programmatically at launch to 18 months out—there’s no separate \”announcement.\”” That means a team waiting for a vendor blog post or a conference keynote can simply miss the signal. The date exists from day one, embedded in platform metadata, and the burden of discovering it falls on the workload owner rather than the provider.
This quiet pattern is exactly why tracking must be systematic rather than reactive. A model that is fully retired stops serving traffic with a hard error, and the consequence is immediate: your application’s inference calls begin to fail in production. Building a habit of checking lifecycle status before failures occur is far cheaper than debugging them after an outage, because it turns an unpredictable break risk into a scheduled maintenance task with a named owner, a verified replacement target and a firm deadline.
Check the Programmatic Channels First
The most reliable deprecation signals are not newsletters or social posts; they are the provider’s own programmatic interfaces. Azure exposes lifecycle data through a documented endpoint, and the guidance is direct: “Use the Models API to programmatically check lifecycleStatus , deprecation , and per-SKU deprecationDate for any model at any time.” Querying these fields regularly turns retirement tracking into a routine monitoring task instead of a scramble. If a scheduled job records the current lifecycle status of every model your workloads depend on, you see the shift from generally available to deprecating the moment it happens, weeks or months before traffic is affected.
Be aware that documentation wording and API wording can diverge in confusing ways. The same documentation explains that a model listed in the portal as “Deprecated” appears in the API as Deprecating, while the API value “Deprecated” actually means the model is retired and inference returns an error. Reading both the status field and the date field together avoids a costly misreading, because a past inference deprecation date means the model is gone regardless of any lagging status value. This kind of terminology mismatch is a common trap when teams build their first deprecation dashboard, and a short mapping table in your runbook prevents it.
Know the Minimum Notice Periods
Providers commit to notice windows, and knowing them tells you how late you can safely leave a migration. For Azure Foundry, the active-notification table specifies “At least 60 days before retirement All GA models”, with the notice sent to subscription owners with active deployments, while preview models carry a shorter “at least 30 days notice” commitment before force-upgrades or termination. Health advisories in Azure Service Health mirror the same information for affected subscriptions, so configuring an alert rule for email, text or webhook notifications there adds a passive safety net on top of active polling of the API.
Two structural facts deserve special attention in any plan. First, not every deployment type is rescued automatically at retirement. The documentation warns in bold that “Provisioned deployments are NOT auto-upgraded.” Provisioned capacity therefore requires a deliberate, manual migration before the retirement date, including confirming that quota is available for the target model in advance. Second, deadlines do not bend. When the documentation’s FAQ is asked whether a retirement date can be extended, the answer is simply that “Retirement dates aren’t extendable.” Any migration plan that assumes an eleventh-hour exception is built on hope rather than published policy, and the official replacement model is only declared roughly 90 to 120 days before retirement, so early independent evaluation pays off.
Build a Migration Trigger Into Your Records
Tracking notices only pays off if each signal triggers an owned action. A practical record for every AI dependency should capture the exact model identifier rather than a moving alias, the deployment type, the current lifecycle status from the provider’s API, the retirement date, and the named owner of the migration. When the polled status changes or the date crosses an agreed threshold, the record converts directly into a ticket. Treating a model announcement the way you would treat a dependency version change, as described in our weekly infrastructure review practice, keeps the evaluation honest: confirm account-level availability, interface fit and cost before moving any traffic.
Closing the loop also means verifying the migration itself, not just scheduling it. Following the evidence-first discipline we outline for matching notices to deployed assets, record the version that actually served each request after cutover and keep a rollback route until the replacement is proven on your own data. Retirement schedules change as providers publish updates, so re-check the official schedule and the Models API rather than relying on a saved copy. With polling, alert rules and an owned migration record in place, model deprecations become scheduled maintenance instead of an outage.