Your AI model has an expiry date: build the migration lane now
By Greg Nowak. Last updated 2026-07-30.
An AI integration can run perfectly well in production right up to the day its model endpoint disappears. The surrounding software may be healthy, but once the provider retires that model, the workflow can still stop.
Several deadlines are already close. As of 30 July 2026, Anthropic's retirement schedule lists Claude Opus 4.1 for retirement on 5 August and recommends Claude Opus 4.8 as its replacement. Google's Gemini schedule lists the embedding-2-preview shutdown for 10 August. Gemini 2.5 Flash Image follows on 2 October, with Gemini 2.5 Pro, Flash and Flash-Lite listed for 16 October. Google describes these as the earliest possible shutdown dates and says it will communicate exact timing in advance.
There is no need to treat every deprecation notice as an emergency. There is a need for a repeatable way to handle one before the deadline becomes the project plan.
A replacement model is only the starting point
Changing the model identifier may take a minute. Establishing that the replacement still works for the business process can take considerably longer.
A new model may accept different parameters, validate requests differently or return a changed response structure. Tool behaviour, token use, latency and the tone or reliability of its answers may also shift.
The providers' current guidance gives some concrete examples. Anthropic says that setting temperature, top_p or top_k to non-default values produces a 400 error on Claude 4.7 and later. Google's latest-model migration guidance says newer Gemini releases ignore those sampling parameters and may reject them in future generations. It also says a request ending with a non-empty model-role turn now returns a 400 error.
Those changes affect the API contract. Some requests will fail before the application receives an answer. Others will succeed but produce different schemas, tool choices or task results. A sensible migration checks both: whether the integration still functions and whether the output still does the job.
Find every place the model is configured
Start with the deployed model ID, then follow it through the whole workflow. It may be hard-coded in application code, supplied through an environment variable, selected inside an automation platform, configured in a cloud deployment or buried in a scheduled job that rarely runs.
For each dependency, record the provider, hosting platform, exact model or deployment version, configuration location, business owner, workload, production criticality, known retirement date and recommended replacement. Capture the request parameters, expected response schema, tools, timeout settings and current rollback route as well. That turns a model list into something an operator can actually use during a migration.
The hosting platform needs its own field. Anthropic notes that retirement schedules can differ between Anthropic-operated and partner-operated platforms. Microsoft's Foundry retirement schedule separately tracks Azure OpenAI and partner models. It includes October 2026 retirements for deployments such as GPT-4o version 2024-05-13, GPT-4.1 Nano, several audio models, o3-mini, o4-mini and partner-hosted Claude models. A model family name alone does not tell you the deadline.
| Migration gate | What to prepare | What must be true before moving on |
|---|---|---|
| 1. Dependency inventory | Exact IDs, versions, locations, owners and retirement dates | Every production reference has an accountable owner |
| 2. Contract check | Parameters, endpoints, schemas, tool calls and error handling | Replacement requests work without relying on hidden compatibility assumptions |
| 3. Workflow replay | Normal, difficult and failure-prone inputs from the real process | Quality, safety and operational results meet agreed thresholds |
| 4. Canary release | Limited traffic, comparable telemetry and alert thresholds | No material regression in errors, latency, token use or task outcomes |
| 5. Rollback check | A documented switch, responsible person and valid fallback model | The previous safe configuration can still be restored before retirement |
Test the work your integration really performs
A generic benchmark will not tell you whether an order-processing workflow still returns valid JSON or whether a support assistant has started refusing routine requests. The evaluation set should represent the integration's actual workload.
Include common requests, valuable but difficult cases, malformed and long inputs, tool calls, structured-output examples and cases that should be refused or escalated. Remove sensitive information where necessary. Keep the set versioned so the same material can be replayed when the next model reaches retirement.
Some results can be checked automatically. Does the response validate against the expected schema? Are the required fields present? Can the application use the tool arguments? Other results need judgement: whether the answer completes the business task, follows the right safety boundary and remains useful to the person receiving it.
Operational measures belong in the same comparison. Track failure rate, latency, input and output tokens, and estimated cost under the same workload. Look beyond averages. A small improvement across routine prompts does not make up for broken JSON in an order path or an unexpected refusal in customer support. Agree the acceptance thresholds before reviewing the replacement, so a handful of impressive outputs do not set the release standard.
Give model calls a controlled boundary
When model calls are scattered across a codebase, each retirement becomes a search exercise. A provider wrapper can centralise model selection, supported parameters, timeouts, retries, logging and response normalisation.
That wrapper should not hide genuine provider differences. Provider-specific capabilities still need explicit handling. The useful part is control: unsupported settings can be rejected early, the application can use a stable internal interface where that makes sense, and the active model configuration is easier to inspect.
This structure also improves the dependency register. Most production model selection can pass through one governed point, while automation platforms and cloud-side deployment names remain visible as separate dependencies outside the application.
Release before the fallback disappears
A migration finished on retirement day leaves almost no room to recover. Move earlier and use a canary release. Send a small, controlled share of suitable traffic to the replacement, then compare it with the established route. Watch schema failures, provider errors, latency, token use, cost indicators and the outcomes that matter to the workflow.
The rollback instructions should identify the exact setting to change, who can authorise the switch, how recovery will be verified and how long the fallback will remain available. Once the old model has retired, it is no longer a fallback. The canary and rollback rehearsal therefore need to happen while both routes still work.
OpenAI's official deprecation record makes the case for regular lifecycle checks. It distinguishes legacy models from formally deprecated ones, publishes shutdown dates and recommended replacements, and warns that preview models may receive much shorter notice than generally available models. A multi-provider register should track lifecycle status as well as dates, with someone responsible for reviewing it on a recurring schedule.
What to do next
Begin with integrations closest to a published deadline, then rank the rest by business impact and migration uncertainty. Confirm the exact hosted version and assign an owner. Prepare representative replay inputs, agree the acceptance thresholds and place the replacement behind controlled configuration. The comparison, canary and rollback rehearsal can then happen while there is still time to respond to a problem.
Greg can help trace model IDs across code, environment variables, automation platforms and cloud deployments. He can also introduce a controlled provider wrapper, replay representative inputs against replacement models, compare schemas, quality, latency and cost, and prepare the canary and rollback instructions. The immediate goal is a safe model change. The more valuable outcome is a migration process that is ready for the next expiry date.
Related on GrN.dk
- Background AI Tasks Need Queues, Not Just Longer API Calls
- OpenAI Presence Arrived—But Is Your Workflow Ready for an Agent?
- Search Console Can See Social Posts—Your Reports Need a New Map
Need help with this kind of work?
Plan your model migration Get in touch with Greg.