Model deprecation windows are the notice periods a provider gives you before a model stops answering API requests, and they are the difference between a planned migration and a production outage. OpenAI commits to at least 6 months of notice for generally available models and as little as 2 weeks for preview models, Microsoft Foundry runs an 18-month lifecycle for most generally available models, and Anthropic guarantees at least 60 days of notice before retiring publicly released models. The engineering work is deciding which of your workloads can live inside the shortest applicable window, and which must be pinned, tested, and cut over deliberately.
Because vendors set these windows unilaterally and can shorten them for safety or compliance reasons, treat the published minimum as the only number you can plan against. Anything longer than the minimum is luck, not architecture. This guide compares the three binding commitments, then turns them into a runbook and a decision table you can apply to your own deployments this week.
What Providers Actually Commit
The three vendors most teams depend on publish explicit, and different, commitments. OpenAI’s deprecation policy sets a floor of at least 6 months for generally available models, 3 months for specialized variants such as chat, Codex, or deep research builds, and warns that preview models may be retired with roughly 2 weeks of notice. Microsoft Foundry runs generally available models on an 18-month lifecycle where deployments become deprecated at 12 months and inference eventually returns 410 Gone, with the declared replacement available in global standard roughly 90 days before the retirement date. Anthropic’s published policy promises at least 60 days of notice for publicly released models and lets you export a per-key, per-model usage CSV from the console so you can find exactly what is still running on deprecated versions.
| Provider | Minimum notice (GA) | Preview behavior | End state |
|---|---|---|---|
| OpenAI | 6 months (3 for specialized variants) | Retired with roughly 2 weeks of notice | Model stops serving on shutdown date |
| Microsoft Foundry | 18-month lifecycle, deprecated at 12 months | Force-upgraded or retired, no opt-out | All inference returns 410 Gone |
| Anthropic | At least 60 days for public models | Deprecated before retirement | Requests to retired models fail |
Read the table as worst-case budgeting input, not as a schedule you can rely on. The numbers are floors that the providers can undercut when a model has compliance or security problems, and fine-tuned checkpoints follow separate, shorter timelines on some platforms.
Reading the Notice Periods
Notice periods are minima, not promises of stability. OpenAI states explicitly that safety or compliance concerns can force a faster timeline than the published floor, and Microsoft reserves the right to invoke an emergency retirement with shortened notice for models with compliance or security issues. Provisioned deployments are not auto-upgraded, and retirement dates are not extendable, so a missed window has no negotiation path; customers on provisioned capacity must migrate by hand, while Standard deployments roll to the replacement region by region on a published schedule. In practice, the effective migration deadline for anything on provisioned capacity is the auto-upgrade schedule of the platform, not the retirement date itself.
The second trap is the distinction between deprecated and legacy. Both OpenAI and Anthropic use a legacy label for endpoints that still work but no longer receive updates, and a deprecation label that attaches a date. Legacy models are pre-deprecation candidates: they still answer requests today, but treating them as stable infrastructure is how teams end up doing an emergency rewrite. Watch aliases too, because a floating alias such as a latest pointer can change behavior underneath you with no deprecation notice at all.
Build a Deprecation Runbook
- Inventory every model reference. Grep application configs, infrastructure code, environment variables, database rows, and notebook schedules for model names and dated snapshots. Pinned snapshots and floating aliases age differently, and you need both lists.
- Query lifecycle data programmatically. The Azure Models API exposes lifecycleStatus and per-SKU deprecationDate fields you can poll on a timer; OpenAI and Anthropic publish deprecation tables that are small enough to diff weekly in CI.
- Alert on the failure mode, not the announcement. A synthetic call that fails on 410 Gone in staging, plus production logging of model-not-found errors, catches quiet drift that vendor email notices miss.
- Gate the replacement behind regression checks. Re-run your golden prompt sets and your structured outputs regression suite against the replacement model before any traffic shifts, so a schema break surfaces in testing rather than in a customer payload.
- Shadow, then cut over. Mirror a slice of production traffic to the replacement, compare outputs, latency, and cost per request, and only then move the default reference.
- Retire the old reference. Delete the deprecated model name from code and configuration so a rollback cannot silently reintroduce a model that is weeks from disappearing.
The whole runbook assumes you can answer one question on demand: which workloads, in which environments, call which model versions today. If that inventory takes longer than an afternoon to produce, that is the first thing to fix, before any vendor forces the issue.
The Migration Decision Table
Use a decision table with explicit assumptions so the migration call is auditable later. The defaults below assume moderate traffic, a working evaluation suite, and no contractual capacity commitment; adjust the deadlines if any of those assumptions fail. When the replacement model lands in a new region or SKU, also confirm it is reachable through your existing private VPC endpoint setup before committing to a cutover date.
- Pinned snapshot in production: migrate on the vendor schedule. You hold the full notice window and a hard stop, so the risk is calendar discipline, not surprise.
- Floating alias in production: pin it now, then migrate deliberately. An alias can swap the underlying model without any notice, which is worse than a dated retirement.
- Fine-tuned or provisioned deployment: start earliest. Manual migration, quota checks, retraining lead times, and re-approval of the deployment consume most of the window before testing even begins.
- Preview model anywhere near production: treat roughly 2 weeks as the real budget and keep a tested fallback model behind a feature flag.
Deprecation windows are one of the few parts of the model landscape that are written down and enforceable. Teams that read the commitments literally, inventory their references, and gate migrations behind regression checks turn retirements into routine maintenance instead of incident response.
Sources
- OpenAI — Deprecations (consulted 2026-10-27)
- Microsoft — Foundry Models lifecycle and support policy (consulted 2026-10-27)
- Anthropic — Model deprecations (consulted 2026-10-27)