Direct answer: A model retirement is not just a model-ID change. It can break prompts, tool calls, fine-tunes, evaluations and contracts. In 2026, treat it as a supply-chain event: pin versions, monitor lifecycle notices, run your golden set, and write migration and exit terms before you need them.
This guide is for AI owners, product/engineering, SRE, procurement, legal and vendor management at companies that already run—or are about to run—LLM applications. It covers how to detect a retirement, assess impact, migrate and contract for it. Information is current to 30 October 2026. It is public vendor documentation and project method, not certification or a promise about any model, vendor, price or compliance; notice periods, shutdown dates, SLAs and liability are governed by the vendor documentation, contract and deployment.
Do not bet stability on "latest"; pin model IDs, API versions, prompt/tool schemas and evaluation sets; before retirement, inventory dependencies, run the golden set, canary and roll back; write notice, migration support, price protection and exit into the contract.
Why is model retirement a procurement issue in 2026?
A model retirement is not just a model-ID change. It affects prompts, tool calls, fine-tunes, evaluations and contracts. In 2026, manage it as a supply-chain event, not a bug to fix after errors appear.
LLM API lifecycles are usually controlled by the vendor: release, GA, deprecation, shutdown. Enterprise applications, however, often hard-code model names into code, prompts, evaluation sets, contracts and budgets. When a model is retired, the problem is not only "switch models"; output format, tool calls, citations, latency, cost, safety filters and human takeover can all change. If procurement treats model availability as a default assumption, the migration cost lands on the business team.
| Risk | What happens at retirement | Who is affected | Do first |
|---|---|---|---|
| Model ID disappears | Requests fail; old logs cannot reproduce the behaviour | Product/engineering/SRE | Inventory every model ID and alias |
| Behaviour changes | Format, tool calls, citations, refusals and latency change | Business/QA/support | Run the golden set |
| Fine-tune/embedding breaks | Retrain, rebuild the index or change dimensions | ML/data/ops | Confirm dependencies and rebuild cost |
| Contract has no notice/migration | Short window; migration cost borne by the buyer | Procurement/legal/finance | Add notice, migration and exit terms |
The risk table is editorial; the actual impact depends on application architecture, model dependencies, data region and contract.
How different are the four providers' notice windows?
They differ: OpenAI GA at least 6 months, Anthropic at least 60 days, Google 12 months or 45 days, Azure GA standard 18 months. Preview and security exceptions can be shorter; check GA, preview and exceptions before planning the migration.
Public documentation does not give one universal number, and the difference between GA, public, preview, specialized variants and security exceptions is large. The table below only summarises the general commitments on each vendor's current public page; individual models still need their own retirement schedule, and vendors reserve the right to shorten notice for safety/compliance reasons.
| Vendor | Public notice window | Shorter/exception | Signal to monitor | Acceptance implication |
|---|---|---|---|---|
| OpenAI | GA models at least 6 months; specialized variants at least 3 months | Preview may be as short as about 2 weeks; safety/compliance can be faster | shutdown_date, Deprecations page, email | Do not run critical production on preview; read the shutdown date in code |
| Anthropic | Publicly released models at least 60 days | Check the specific model page/email | Model deprecations page, email, usage export | 60 days is enough only for small migrations; critical systems need earlier work |
| Google Cloud | Some models at least 12 months after release; shorter-term models at least 45 days to migrate | Check the model-version table | Model versions page, version tables | Pin model ID/version; do not rely on "auto-latest" |
| Azure/Foundry | GA models follow a standard 18-month lifecycle | Safety/compliance can trigger emergency retirement; replacement about 90/30 days ahead | Model retirement schedule, lifecycle page | Expiry may return 410; prepare replacement/rollback early |
Windows are summarised from vendor pages accessed on 2026-10-30: OpenAI Deprecations, Anthropic Model deprecations, Google model versions, Azure lifecycle. Policies change; the vendor page and specific model table govern. This table is not a legal commitment.
The table is easy to misread as "six months is enough". Real migration is not just an API call: if the application depends on tool calls, JSON schema, citation format, fine-tuned weights or embedding dimensions, two weeks is enough for a demo, not for regression, canary, support training and contract changes. Preview models are especially unsuitable for critical production because their notice can be as short as two weeks.
Which dependency layers can a retirement break?
A retirement can break seven layers: model ID, API/SDK, prompt/tool schema, fine-tune/embedding, safety filters, data region and billing. Map the dependencies before discussing migration; an uninventoried layer will cause rework.
Many teams think "switch model" means changing one string. In practice, at least seven layers matter: model ID/alias, API version and SDK, prompts and tool schema, fine-tune/embedding, safety/content filters, data region/retention and billing/quota. Each fails differently and needs different acceptance evidence.
| Layer | How it can break | How to detect | How to reduce risk |
|---|---|---|---|
| Model ID/alias | Hard-coded ID disappears; latest drifts | Code/config scan, request logs | Pin versions; aliases only for non-critical use |
| API/SDK | Parameters, error codes, streaming format change | Contract tests, SDK version table | Lock the SDK; isolate behind an adapter |
| Prompt/tool schema | JSON format, function calls, refusals change | Golden set, schema validation | Version prompts; strict parsing |
| Fine-tune/embedding | Weights unavailable; vector dimensions/semantics change | Model card, index version, retrieval tests | Keep training data; rebuildable index |
| Safety/content filter | Refusal rate, false positives, compliance boundary change | Safety samples, red team, human review | Independent safety layer; configurable policy |
| Data region/retention | Residency, logging/training use change | DPA, region config, audit | Contract region/retention/deletion |
| Billing/quota | Price, cache, rate limits, plan change | Bill, usage, load test | Budget alerts; multi-vendor comparison |
The dependency layers are editorial; specific failure modes and evidence depend on the application, model/vendor and contract.
How should a 90-day regression migration run?
Inventory models and owners, then run the golden set, shadow traffic, canary, rollback and contract checks. A one-off demo of the new model is not a migration; keep a rollback window before the final cutover.
The goal is not "the new model can answer one prompt"; it is "critical tasks stay within acceptable metrics and failure can be rolled back". A 90-day plan can be split into inventory, golden set, shadow, canary, contract/operations and final cutover. Each phase needs an owner, evidence and stop condition; if a hard gate fails, extend under the contract or narrow scope—do not cut over a broken workflow.
| Phase | Actions | Outputs | Stop/rollback |
|---|---|---|---|
| Weeks 0–2 | Inventory model IDs, aliases, SDK, prompts, tools, fine-tunes, embeddings, regions and owners | Dependency map, shutdown-date table | Critical system without owner: stop migration |
| Weeks 3–4 | Freeze golden/safety samples; define task success, format, citations, latency, cost and takeover gates | Evaluation set, gate table | No baseline: do not enter shadow |
| Weeks 5–6 | Shadow traffic to the new model; compare output, tool calls, refusals, latency and cost | Difference report, failed samples | Hard gate fails: no canary |
| Weeks 7–8 | Small canary; human review; prepare rollback switch and dual-run budget | Canary log, rollback drill | Rollback fails: do not expand |
| Weeks 9–10 | Confirm contract/notice/price/deletion; update prompts, SDK, monitoring and runbook | Contract change, ops docs | Contract not confirmed: no final cutover |
| Weeks 11–12 | Final cutover, review, close the old model; keep a rollback window and evidence | Cutover record, review | Anomaly: roll back by threshold |
The 90-day plan is an editorial suggestion; actual duration depends on system complexity, evaluation set, vendor window and contract. It is not a project schedule.
Do not budget only the new model's unit price. Include engineering days, evaluation/labelling, dual-run tokens/cloud resources, support/human takeover, contract/legal and opportunity cost. A simple framing is "migration budget = engineering + evaluation + dual-run + takeover + contract", amortised over 3–6 months; the actual amount depends on the project. This article gives no price commitment.
Which regression metrics matter?
At minimum: task success, format/tool calls, citations/grounding, latency, cost per task, human takeover, safety and data boundaries. "Sounds more human" is not enough.
Use the same golden set as business acceptance, not a few cherry-picked examples from the vendor. Split metrics into hard gates and soft indicators: format/tool calls, safety/privilege and data leakage are hard gates; latency, cost, tone and length can be soft. Each metric needs sample size, definition, failure handling and retest evidence.
| Metric | Why it matters | Pass standard | Evidence |
|---|---|---|---|
| Task success | Does the new model complete the same business task? | Scenario gate; critical tasks do not degrade | Per-item golden-set results |
| Format/tool calls | Can JSON, functions and workflows be parsed? | Format-error rate below gate; tool parameters correct | Schema validation, logs |
| Citations/grounding | Is the answer sourced or fabricated? | Citations verifiable; unsourced conclusions flagged | Citation samples, human review |
| Latency | Does it affect support or production cadence? | P95 within business tolerance | Load test/monitoring |
| Cost per task | Does unit economics worsen after migration? | Within budget/margin gate | Bill, tokens/task |
| Human takeover | Is there a fallback when it fails? | Takeover rate/handling time controlled | Tickets, duty log |
| Safety/data | Privilege, injection, leakage, region/retention | Hard gate; failure means rollback | Security test, DPA |
Metrics and gates are editorial; sample size, definitions and pass standards depend on business risk, evaluation set and contract.
What contract clauses should cover retirement/migration?
Write notice, migration support, version/SLA, price protection, data deletion and exit. "Vendor may upgrade at any time" leaves the retirement risk with the buyer.
The vendor controls the lifecycle, but the contract can define notice, support, price, data and exit. Do not accept a generic SaaS clause that only says "available"; if the application depends on a specific model/version, put it in the service description, SLA and change process. The following is an editorial suggestion, not a substitute for legal review.
| Clause | What to write | Evidence | Red flag |
|---|---|---|---|
| Notice | Days of notice before retirement/deprecation; channel; emergency safety exception | Notice record, lifecycle page | Blog/email only, no contractual duty |
| Migration support | Replacement model, migration docs, evaluation support, dual-run period | Migration plan, support tickets | "Migrate on your own" with no support |
| Version/SLA | Fixed-version availability, error rate/latency, degradation/rate limits | SLA, status page | "Best effort" only |
| Price protection | Pricing during retirement/migration; cache/batch; quota | Quote, bill | Large increase after migration |
| Data | Training use, region, retention, deletion, export | DPA, audit | Delete data/no export at shutdown |
| Exit | Weights/prompts/logs/evaluation sets/vector export; transition period | Exit checklist, deletion proof | PDF reports only |
Contract clauses are editorial suggestions, not a substitute for legal review; notice, SLA, data and liability depend on the vendor, deployment and contract.
Pre-launch/pre-retirement acceptance checklist
Accept eight items: inventory, owner, monitoring, golden set, regression, canary, rollback and contract. If any is missing, retirement becomes emergency firefighting; the checklist must name people and dates.
The checklist can be shared by AI product, engineering, SRE, procurement, legal and vendor management. The pass standard is not "the new model runs"; it is "we can detect retirement, assess impact, roll back and migrate under the contract".
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Model inventory | All model IDs/aliases, versions, owners and uses are discoverable | Dependency map, config | Add inventory/retire unknown models |
| Lifecycle monitoring | Deprecation page/email/shutdown_date/status page is watched | Monitoring config, duty roster | Assign owner/alert |
| Golden set | Critical tasks, format, safety and citation samples are complete | Evaluation set, labels | Add samples/do not migrate |
| Regression | Old and new models compared on the same set; hard gates block cutover | Difference report | Rerun/narrow scope |
| Canary/rollback | Small traffic, rollback switch, dual-run budget | Canary log, drill | Do not expand on rollback failure |
| Contract | Notice, migration, SLA, price, data and exit are written | Contract/DPA | Add clauses/change vendor |
| Runbook | Runbook, contacts, degradation/stop steps updated | Docs, drill | Add docs/training |
The checklist is an editorial suggestion; retirement/migration/SLA/data requirements depend on vendor documentation, contract and business risk.
Who should read this, who should not, and what decision does it support?
It fits teams already in production or using multiple model vendors; it does not fit pre-launch teams, teams without an evaluation set, or one-off demos. Check for production dependency and a golden set first.
Who should read: AI owners, product/engineering, SRE, procurement, legal and vendor management at companies running LLM applications in support, knowledge bases, agents or inspection; teams selecting a vendor, preparing for multi-vendor, receiving a retirement notice or setting an annual budget. Who should not: pre-launch teams without real tasks or an evaluation set; one-off demos with no production dependency; projects expecting a checklist to replace legal or contract advice. Decisions supported: model pinning/version policy, retirement monitoring, dependency inventory, 90-day migration, regression gates, contract clauses and pre-launch/pre-retirement acceptance.
Lingyi Information is a website and enterprise AI project services company, not a model vendor or law firm. This article does not replace a vendor contract, legal advice or a security assessment. Scope is confirmed case by case; Lingyi does not promise model availability, migration time, cost or outcomes.
FAQ
How much notice do model retirements usually give?
There is no universal answer. Public pages show OpenAI GA at least 6 months, Anthropic public models at least 60 days, Google some models 12 months or shorter-term 45 days, and Azure GA a standard 18-month lifecycle; preview, specialized variants and safety/compliance exceptions can be shorter. The specific model page and contract govern.
Does a "latest" alias upgrade automatically?
It may, and that is the risk. Aliases drift; behaviour, price and format can change. Pin a version for critical production and use aliases only for non-critical or quickly reversible cases. Upgrade through the golden set and a canary, not "auto-latest".
Is switching models just a model-ID change?
No. Check API/SDK, prompts, tool schema, fine-tune/embedding, safety filters, data region, billing and monitoring. Many failures are not "the model cannot answer" but JSON parsing, function parameters, citation format or refusal policy changing.
If a vendor says it is OpenAI-compatible, do we skip migration?
Compatibility usually covers the interface shape, not behaviour, tool calls, citations, refusals, latency, price or data terms. Still run your own golden set and check SLA, data region and exit terms.
Does self-hosting/open source avoid retirement?
Not entirely. Weights may stop being updated, frameworks/dependencies expire, and GPU/driver/security patches need maintenance; control moves from the API vendor to you. Still pin versions, keep data, run regression and plan an exit.
How should the contract cover retirement/migration?
At minimum: notice period/channel, migration support, version/SLA, price protection, data retention/deletion/export, exit and transition. Put the "available model/version" into the service description; confirm the actual clauses with the vendor, deployment and legal counsel.
Bottom line
An LLM API retirement is a supply-chain event: pin model versions, monitor lifecycle, run the golden set, canary and roll back, and write notice/migration/price/data/exit into the contract. Do not bet stability on "latest", and do not leave migration until the first error.
Method and limits
This article is public vendor documentation, lifecycle pages and editorial method, not certification or a promise about any model, vendor, price, SLA or compliance, and not legal advice. It uses no unpublished client systems, contracts or retirement cases. Notice windows, migration duration, metrics and contract clauses are editorial suggestions; the vendor documentation, contract, actual deployment and legal counsel govern.
Sources
Information is current to 30 October 2026; each vendor page and specific model schedule governs.
- OpenAI, Deprecations: platform.openai.com. GA at least 6 months, specialized variants at least 3 months, preview may be about 2 weeks;
shutdown_datefield. - Anthropic, Model deprecations: docs.anthropic.com. At least 60 days' notice for publicly released models; retirement/replacement tables.
- Google Cloud, Model versions and lifecycle: cloud.google.com. Some models at least 12 months after release; shorter-term models at least 45 days to migrate.
- Microsoft Foundry, Models lifecycle and support policy: learn.microsoft.com. Standard 18-month GA lifecycle; replacement about 90/30 days ahead; expiry may return 410 Gone.