On 5 August 2026, Claude Opus 4.1 retires. On 23 October, roughly ten OpenAI models go with it. Somewhere in your organisation, a workflow that a department head signed off eight months ago is calling one of them, and nobody has written down which one.
That is the whole problem in three sentences. The technology works, the vendors have published their dates, and the gap is entirely organisational.
This article sets out what model deprecation is, which dates matter in 2026, what a forced migration actually costs, and the one-page register that turns a retirement notice into a calendar item rather than an incident.
What is AI model deprecation?
AI model deprecation is the scheduled retirement of a model version by its provider. After the retirement date, API calls to that version fail or are silently redirected to a successor. The model your production system was built, tested and approved on stops existing, on the vendor's timetable rather than yours.
Most enterprises treat the underlying model as infrastructure, like a database engine that will still be there in five years.
It is not infrastructure. It is a supplier contract with an expiry date, and the expiry dates in 2026 are arriving faster than procurement cycles can absorb them.
Two categories of retirement matter differently. A hard retirement returns an error, which is disruptive but visible. A silent upgrade routes your traffic to a newer version that behaves differently, which is far more dangerous because nothing breaks loudly.
Why are model retirement cycles getting shorter?
Retirement windows have compressed because frontier labs now ship successor models every few months and cannot economically serve every prior generation. Industry reporting through 2025 and 2026 puts the typical useful life of a given model version at roughly six months, down from about twelve. Faster iteration on the vendor side becomes faster forced migration on yours.
The commercial logic is straightforward. Serving an older model means holding inference capacity for a shrinking user base while the same silicon could run a cheaper, better successor.
The notice periods reflect that pressure. According to OpenAI's published deprecations policy, generally available models receive at least six months' notice, specialised variants around three months, and preview models roughly two weeks. Anthropic publicly commits to a minimum of 60 days' notice for public models.
Sixty days is shorter than the change-approval cycle at most Hong Kong financial institutions.
That is the real problem. The vendor is behaving reasonably and transparently. The mismatch is between a 60-day notice window and an enterprise governance process that takes a quarter to approve a production change.
Which AI models retire in 2026, and when?
Several major retirements land inside the 2026 financial year, and the near-term dates are already public. Any organisation running these versions in production has a fixed deadline, not a planning assumption. The list below reflects provider announcements and deprecation trackers published in the first half of 2026.
--- 13 February 2026: GPT-4.1, GPT-4.1 mini, GPT-4o and o4-mini were removed from ChatGPT.
--- 9 to 31 March 2026: Standard Azure OpenAI deployments began automatically upgrading older models, reaching end-of-life at month end. This was a silent upgrade, not an error.
--- 23 July 2026: Codex and deep-research model variants retired.
--- 5 August 2026: Claude Opus 4.1 retires.
--- 23 October 2026: Approximately ten OpenAI models, spanning the GPT-4 era and the o-series, retire together.
The October date deserves attention because it is a cluster, not a single sunset. An enterprise with four AI workflows built at different times may find three of them depending on models that all expire in the same week.
Cluster retirements are what turn a manageable migration into a change-freeze conflict with year-end close.
What does a forced model migration actually cost?
The direct licence cost of migration is usually zero, and successor models are often cheaper per token. The real cost is regression risk: every prompt, every retrieval pipeline and every downstream automation validated against the old model must be re-validated. That work is engineering time, testing time and compliance sign-off, not vendor spend.
Migration cost breaks into four line items that finance teams consistently underestimate.
--- Prompt re-tuning. Instructions optimised for one model's behaviour frequently underperform on its successor, especially where output format is strict.
--- Evaluation rebuild. If accuracy was measured informally, there is no baseline to compare the new model against, so the team is guessing.
--- Regulatory re-approval. In regulated sectors, a material change to a model used in a customer-facing decision can trigger fresh internal validation.
--- Output drift remediation. A successor model may produce longer, differently structured or differently hedged answers that break the system consuming them.
There is a genuine upside worth putting in the same business case. Successor models are frequently cheaper for equivalent work, and migrating between Claude Opus generations has been reported to cut per-token billing materially. A migration forced on you can still end up reducing run-rate cost, which is the argument that makes the budget request survivable.
Measuring that trade-off requires a working evaluation baseline. If your organisation has not established one, start with what an AI eval is and how enterprises measure whether AI actually works, then attach the cost side using an AI FinOps framework for controlling enterprise AI spend.
How do you build a model lifecycle register?
A model lifecycle register is a single maintained list of every model version your organisation calls in production, who owns it, what it does, and when it expires. It is the minimum viable control. Without it, no one can answer the board question "what breaks on 23 October" in under a week.
Five columns make the register useful rather than decorative.
--- Call site. The specific application, workflow or agent making the request, not the department.
--- Pinned version string. The exact model identifier, including the date suffix where the provider supplies one.
--- Named business owner. One person accountable for the migration decision, not a committee.
--- Announced retirement date. Taken from the provider's own deprecation page, refreshed monthly.
--- Evaluation status. Whether a scored test set exists that can be run against a candidate replacement today.
The fifth column is the one that separates organisations that migrate in a fortnight from those that spend a quarter arguing. A team with a scored test set runs the successor model, compares results, and produces evidence. A team without one runs on opinion.
The register also answers the concentration question. Multi-model operation is now standard practice: AvePoint's 2026 analysis of enterprise AI strategy reports that 81% of CIOs run three or more model families in testing or production, up from 68% a year earlier, and that 37% now run five or more in production. Two thirds of organisations describe themselves as actively working to avoid single-provider dependency.
Running several models is not automatically resilience. Running several models with no register means several expiry dates you cannot see.
What contract terms protect you from deprecation?
Four clauses convert deprecation from an operational emergency into a managed vendor event: version pinning rights, a defined minimum notice period, a migration support commitment, and an output-equivalence remedy. Procurement teams that negotiate AI contracts on price per token alone leave all four on the table.
Ask for each one explicitly at renewal.
--- Version pinning. The right to remain on a named version for a defined term, so a mid-cycle capability change cannot arrive unannounced.
--- Notice floor. A contractual minimum notice that exceeds the vendor's public default, sized to your own change-approval cycle.
--- Migration support. Named technical assistance and a parallel-running window where both versions are callable.
--- Materiality remedy. A defined path if the successor version produces materially different output on your validated test set.
Version pinning carries a trade-off worth stating plainly. Pinning protects you from surprise changes, and it also guarantees that you will eventually be sitting on a version scheduled for retirement. Pinning buys predictability, not permanence.
The architectural counterpart is an abstraction layer between application code and the model API, so that swapping providers is a routing configuration change rather than a rebuild. This is the same integration discipline that makes MCP a strategic enterprise integration decision rather than a developer convenience.
How does model deprecation affect Hong Kong sectors differently?
Exposure depends on how tightly the model output is bound to a regulated or contractual obligation. A marketing team can absorb output drift in an afternoon. A licensed institution cannot, because the model sits inside a documented control that an examiner may ask about.
Three Hong Kong scenarios show the range.
--- Financial services. A licensed corporation uses a model to summarise client suitability notes before an adviser signs off. The model version is named in the internal control documentation. A silent upgrade changes summary length and hedging language, and the control description no longer matches reality. The remediation is a document review, not a code change.
--- Logistics. A freight forwarder extracts fields from customs paperwork across three languages. A successor model handles Traditional Chinese abbreviations differently, so extraction accuracy drops on a subset of documents that nobody sampled during testing. The error surfaces as downstream declaration corrections weeks later.
--- Professional services. An accounting firm runs first-pass document review on a pinned model version. The retirement date falls three weeks before the busiest filing period. The migration is technically simple and operationally impossible, because there is no capacity to re-validate during peak.
The pattern across all three is timing rather than technology. Each organisation could have migrated comfortably with ninety days of visibility and could not migrate safely with fourteen.
Personal data adds a second layer for Hong Kong operators, because a change in the model processing personal data may need to be reflected in internal records. The practical baseline is set out in what the 2026 PDPO compliance checks mean for Hong Kong enterprises.
What goes wrong when enterprises ignore deprecation?
Five failure patterns recur, and each one is visible in advance. They share a root cause: the model was treated as a permanent technical fact rather than a dated supplier commitment with a named owner and a review date.
--- The unpinned default. The team never specified a version, so the provider's silent upgrade changed behaviour and no one connected the incident to a model change for weeks.
--- The orphaned pilot. A successful proof of concept was handed to operations without documentation of which model it used. The retirement email arrived and nobody could say what it affected.
--- The compliance freeze collision. The retirement date fell inside a year-end change freeze, forcing either an emergency exception or an outage.
--- The vanished baseline. Accuracy was demonstrated in a workshop, never encoded as a test set, so the migration could not be proven safe to the risk committee.
--- The single-vendor cliff. Every AI workflow used one provider, so one deprecation cycle hit every workflow simultaneously.
A logistics operator running invoice extraction, customer email triage and shipment-exception summarisation on the same provider does not have three AI projects. It has one concentrated dependency wearing three hats.
What should you do in the next 30 days?
Discovery first, contracts second, architecture third. Most organisations do not need a new platform to manage deprecation risk. They need to know what they are running, who owns it, and when it expires, which is a four-week exercise rather than a capital project.
--- Week 1. Inventory every production AI call site and record the exact model version string for each.
--- Week 2. Check each version against the provider's official deprecation page and flag anything expiring within 180 days.
--- Week 3. Assign one named business owner per call site and confirm whether a scored evaluation set exists.
--- Week 4. Add the four contract clauses to your next AI vendor renewal, and brief the risk committee with dates rather than adjectives.
The output of the month is one page: call sites, owners, expiry dates, evaluation status. That page is what makes the next retirement notice a calendar item instead of an incident.
The strategic takeaway
Model deprecation is not an AI problem. It is ordinary supplier lifecycle management applied to a supplier your organisation has not yet classified as one.
The enterprises that will handle the 23 October cluster calmly are not the ones with the largest AI budgets. They are the ones that can produce a one-page register on request, name an owner for each call site, and run a scored test against a replacement model the same afternoon.
Vendor dates are fixed. Your readiness is the only variable you control, and it is built before the notice email arrives, not after.
We understand AI. We understand you. With UD by your side, AI never feels cold. Twenty-eight years of serving Hong Kong enterprises has taught us that the technology decision is rarely the hard part. The hard part is the operating discipline around it.
Reviewed by the UD enterprise AI team.
Know What You Are Running Before the Next Retirement Date
A model lifecycle register only works if it reflects how your organisation actually uses AI today. UD's AI Ready Check maps your current AI footprint, dependencies and readiness gaps, and we'll walk you through every step, from discovery and vendor review to evaluation baselines and migration planning. Twenty-eight years of Hong Kong enterprise experience, alongside you the whole way.
