Why model deprecations deserve a standing process
Every team that builds on hosted AI models is renting a dependency that will eventually be switched off. Providers refresh their catalogs continuously, and each refresh pushes older model versions along a pipeline that ends in removal from service. When that removal happens, requests do not return degraded answers; they fail outright. Microsoft’s Foundry documentation describes the terminal state plainly: once a version reaches the end of its timeline, At 18 months from launch, all inference returns 410 Gone. That single sentence is the reason deprecation tracking should be an engineering routine rather than a fire drill. A workload that worked on Friday can start returning client errors on the retirement date if nobody migrated it.
The wider context reinforces the urgency. The European Commission’s AI Act framework, which entered into force in 2024 and phased in obligations through 2025 and 2026, places transparency and documentation duties on providers and deployers of general-purpose AI models. The Commission states that The AI Act (Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence) is the first comprehensive legal framework of its kind worldwide. For engineering teams, regulatory documentation and dependency hygiene go hand in hand: knowing which model version answered which request is useful both for compliance traceability and for planning migrations before a version disappears.
Where providers actually publish end-of-life notices
The first habit to build is knowing each provider’s official channel, because retirement notices are not always marketing announcements. Microsoft’s Foundry lifecycle documentation explains that generally available models have their retirement date set programmatically at launch, meaning there is no separate launch-day announcement to wait for. Instead, dates live in a published retirement schedule and surface through tooling. The documentation states that customers can use programmatic checks: Use the Models API to programmatically check lifecycleStatus , deprecation , and per-SKU deprecationDate for any model at any time. That is a strong pattern to copy across vendors: find the machine-readable lifecycle endpoint, not just the blog.
Active notifications also exist, but they arrive on specific timelines and only to specific recipients. Microsoft documents a notification window for generally available models of At least 60 days before retirement All GA models, sent to subscription owners with active deployments, and mirrored in Azure Service Health advisories that can trigger email, SMS, or webhook alerts. Preview models operate on a shorter fuse: when a retirement decision forces an upgrade to a newer preview version, Customers get at least 30 days notice. If your alerts route only to an inbox nobody watches, the notice period is wasted; wire Service Health or the vendor equivalent into your on-call tooling.
Building a practical tracking routine
Turn passive awareness into a checklist. First, inventory every model identifier your services call, including versioned snapshot IDs, fine-tuned checkpoints, and mutable aliases. Aliases deserve special care because a vendor can move an alias to a new snapshot without any change in your configuration; the same principle applies when reading any provider changelog, as our piece on reading releases as dependency changes explains. Second, for each entry record the provider, deployment type, region, and the official retirement date from the vendor schedule. Third, poll the lifecycle API on a recurring job and store the results, so you can diff stage changes week over week. A model that moves from generally available to deprecated status in the API response is your cue to start migration work, not to bookmark it for later.
Watch for terminology gaps between documentation and APIs. Microsoft’s docs warn that a model the portal labels deprecated appears in the API with a different status value, and that a past inference deprecation date means retired regardless of any lag in the status field. Reading the two fields together prevents false confidence. Fine-tuned models add another wrinkle: training and deployment can retire on separate dates, so a fine-tuning pipeline can break before inference does. Provisioned capacity may not auto-upgrade at all, leaving manual migration as the only path. If you also maintain non-AI dependencies, the same verification discipline in our guide to reading affected-version advisories applies directly.
Planning the migration before the deadline
Good tracking buys time; migration planning uses it. Vendors typically open evaluation windows ahead of retirement, with replacement models becoming available in standard deployment tiers months before the old version stops answering. Use that window to run your own evaluation set through candidate models, comparing quality, latency, and cost on your representative data rather than public benchmarks alone. Confirm API compatibility, feature support, regional availability, and quota before cutover. Keep the previous configuration deployed and reversible until the new path has handled real traffic, and record which model version answered each request so that any post-migration regression can be diagnosed against a known baseline.
Finally, treat deprecation tracking as a recurring calendar item, not a one-time project. Model catalogs turn over quickly, provider notification windows are finite, and regulators increasingly expect deployers to document which systems did what and when. A small standing routine, inventory plus API polling plus alert routing plus a tested rollback, converts a hard outage date into a scheduled, evidence-backed migration.
Sources
- Microsoft Foundry Models lifecycle and support policy (learn.microsoft.com)
- AI Act — Shaping Europe’s digital future (ec.europa.eu)
- Eurostat: The use of artificial intelligence technologies in the EU — 2026 edition (ec.europa.eu)
- This week in AI infrastructure: changes engineers should verify (dailytrendsignal.com)