Your AI Model Has an Expiry Date: Build the Migration Lane Early
By Greg Nowak. Updated 30 August 2026.
An AI integration can appear healthy until the provider retires the model or API behind it. Then a support assistant, document workflow or internal automation can fail even though your own application has not changed.
This is already routine operational work. Anthropic retired Claude Opus 4.1 on 5 August. Google shut down several embedding and image models during August, while its current schedule includes further retirements in September and October. OpenAI retired the Assistants API on 26 August and lists additional model and API shutdowns for the coming months.
The answer is not to treat every notice as an emergency. It is to maintain a migration lane: a repeatable route from dependency discovery to testing, controlled release and rollback.
A recommended replacement is not a completed migration
Changing a model identifier may take minutes. Proving that the replacement still performs the business task can take much longer.
A new model may handle prompts, tools, structured output, images or long context differently. Its supported parameters can also change. Anthropic, for example, documents that non-default temperature, top_p and top_k values produce an HTTP 400 error on some newer Claude models. A migration must therefore test two separate questions: does the API call still work, and does the resulting workflow still do useful work?
That distinction matters to a business owner. A successful HTTP response is not evidence that an order was classified correctly, a quotation contains the required fields or a customer received an appropriate answer.
Inventory the real dependency, not just the model family
Start with the exact production identifier and trace every place it is selected. Look in application code, environment variables, cloud deployment names, automation platforms, scheduled jobs, evaluation scripts and fallback configurations. Rarely used jobs are particularly easy to miss.
For each dependency, record:
- provider, hosting platform, endpoint and exact model or deployment version;
- configuration location, technical owner and business owner;
- workflow, criticality, expected volume and data sensitivity;
- lifecycle status, announced retirement date and candidate replacement;
- request parameters, tools, output schema, timeouts and retry behaviour;
- current quality, latency, token use and cost baseline;
- the setting used to switch models and the last date rollback remains possible.
The hosting platform deserves its own field. Anthropic explicitly says partner-operated platforms can follow different schedules. Microsoft Foundry also publishes retirement dates by hosted model and version. “We use Claude” or “we use GPT” is therefore not precise enough for an operational register.
| Migration gate | Evidence to prepare | Ready when |
|---|---|---|
| Discover | Exact IDs, hosts, locations and owners | Every production reference is accounted for |
| Validate contract | Endpoints, parameters, tools and schemas | Requests succeed without accidental compatibility |
| Replay work | Representative inputs and acceptance thresholds | Business and safety outcomes remain acceptable |
| Release | Canary traffic, telemetry and alert limits | No material operational regression appears |
| Prove rollback | Documented switch, owner and valid fallback | Recovery has been rehearsed before retirement |
Test the workflow your organisation actually runs
Public benchmarks cannot tell you whether your invoice extractor still returns valid JSON or whether a service assistant now escalates ordinary requests. Build a small, versioned replay set from the real workflow.
Include common inputs, high-value edge cases, malformed or unusually long material, tool calls, structured-output examples and cases that should be refused or handed to a person. Remove or replace personal and confidential data where necessary.
Automate objective checks: schema validity, required fields, valid tool arguments and expected routing. Add human review for correctness, usefulness, tone and safe escalation. Then compare error rate, latency, input and output tokens, and estimated cost under the same workload.
Agree thresholds before examining attractive examples. A replacement should not pass because five answers look impressive while a low-frequency but valuable path has stopped working.
Put model selection behind a controlled boundary
Scattered model calls turn every retirement into detective work. Centralise model selection, supported parameters, timeouts, retries, logging and response normalisation where the architecture allows it. Keep the active and canary choices in inspectable configuration, such as AI_MODEL_PRIMARY and AI_MODEL_CANARY, rather than burying them in releases.
This wrapper should not pretend that providers are interchangeable. Tool semantics and model-specific capabilities still need explicit handling. Its purpose is control: reject unsupported settings early, expose one governed switching point and attach consistent telemetry to each call.
Automation tools and cloud-side deployments may sit outside that wrapper. Keep them in the same dependency register so they do not disappear from the migration plan.
Release while rollback is still real
Move a controlled share of suitable traffic to the replacement before the deadline. Compare provider errors, schema failures, latency, token consumption, cost indicators and business outcomes with the established route. Increase traffic only after the agreed gates pass.
The rollback note should name the exact setting to change, the person authorised to change it, the signals that trigger a reversal and the check that confirms recovery. Rehearse it. After the previous model retires, switching back is no longer a rollback strategy.
Make lifecycle review an operating habit
Assign someone to review provider notices and the dependency register on a recurring schedule. Preview models deserve shorter review intervals because their availability can change faster. Treat endpoints, fine-tuned base models, embeddings, image models and realtime services as lifecycle dependencies too—not only chat models.
Begin with systems nearest a published deadline, then rank the rest by business impact and migration uncertainty. Greg can help trace the dependencies, prepare representative evaluations, introduce controlled model configuration and manage the canary and rollback plan. The immediate result is a safer migration; the lasting value is being ready before the next notice arrives.
Related on GrN.dk
- Model Retirements Are Quietly Breaking AI Integrations
- OpenAI Is Retiring Agent Builder: Save the Workflow, Not Just Prompts
- Not Every AI Job Needs an Instant Answer: Batch the Backlog
Need help with this kind of work?
Plan a safer AI model migration Get in touch with Greg.