Why deprecation tracking is an operational task, not a one-off
Every AI-backed workload depends on a model identifier that a provider will eventually retire. If you track AI model deprecations only when something fails, you are reacting to an outage rather than managing a dependency. Microsoft describes this plainly in its Foundry lifecycle documentation: “Microsoft Foundry Models move through a predictable lifecycle—from release to eventual retirement—giving you time to evaluate replacements and migrate workloads.” The same page explains that the catalog is continuously refreshed and that when a model is superseded, it moves through stages that give customers time to migrate. That means the notices exist before the break; the engineering obligation is to read them on a schedule. A model version that quietly slips from Generally Available into Legacy or Deprecated is still a change to a production dependency, even though inference continues to work, and the safest habit is to review the published schedule at the same cadence you review operating-system patch notices.
Understand the lifecycle stages and what actually stops working
Deprecation is not the same as retirement. In Microsoft’s model, a Deprecated model still serves existing customers while new customers are blocked, but a Retired model is removed from service entirely: “Removed from service. All inference requests return 410 Gone .” Knowing which stage your deployed model occupies tells you how much time you have and who is affected. For standard generally available models, the documentation states that the “Retirement date (18 months out) is set programmatically and available via the Models API”. Note also that some partner models run on shorter clocks: “Generally available models from Anthropic, DeepSeek, Fireworks, and Mistral AI follow a 12-month lifecycle instead of the standard 18-month lifecycle.” Preview models are different again and are force-upgraded or terminated rather than left in place, so teams running preview deployments should treat deprecation checks as routine hygiene, not an annual audit. Access to a deprecated model is also scoped carefully: the documentation explains that existing-customer status is determined at the subscription level, and a new subscription under the same tenant does not inherit access, which matters when a new project spins up on a fresh subscription and expects to deploy an older model ID.
Set up the notification channels before you need them
Providers publish retirement notices through several channels, and an effective tracking routine combines them. For Azure Foundry models, the documentation states that a GA “model retirement notice” is sent “At least 60 days before retirement” and that “Email” is “Sent automatically to subscription owners with active deployments.” It also directs customers to Azure Service Health: “Go to Service Health > Health advisories , filter by Azure OpenAI Service , and create an alert rule for email, text messages, or webhook notifications.” Email to subscription owners only works if someone is actually reading that mailbox, so assign ownership. For deeper guidance on connecting a vendor notice to an asset you actually own, our worksheet on reading security advisories and affected versions applies the same discipline: record the source, match it to deployed versions, and verify the remedy. A weekly review habit, like the one described in our AI infrastructure change review, keeps dated announcements from piling up unnoticed. When a changelog entry names a model ID or an alias change, record which exact identifier your application requests, because a direct API and a partner cloud service can expose different identifiers and deployment options for what sounds like the same model.
Automate the check and plan the migration window
Manual reading is not enough at scale. Microsoft exposes a programmatic path: “Use the Models API to programmatically check lifecycleStatus , deprecation , and per-SKU deprecationDate for any model at any time.” The documentation also warns that the API uses different terminology from the portal, so a model the docs call Deprecated appears as lifecycleStatus “Deprecating”, while the API value “Deprecated” means the model is already retired. Build a scheduled job that lists your deployed model IDs, queries those fields, and files a ticket when a deprecation date falls inside your migration lead time. Plan around the overlap windows: customers can “use and test the replacement model in global standard approximately 90 days before retirement”, and the replacement is named “approximately 90–120 days before” retirement. Provisioned deployments need special attention because, as the documentation warns, “Provisioned deployments are NOT auto-upgraded.” Finally, keep a rollback route and record evidence for each migration: confirm API compatibility, evaluate candidate models against your own prompts and representative data, and retain the current implementation until the replacement has passed those checks, so an end-of-life event becomes a planned change instead of a 410 Gone error in production.