Your AI Model Has an Expiry Date: Build the Migration Lane Early

Illustrated infographic summarizing: Your AI model has an expiry date: build the migration lane now

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
A five-gate migration lane keeps the deadline from becoming the project plan.

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

Need help with this kind of work?

Plan a safer AI model migration Get in touch with Greg.

Sources

Latest articles

An AI assistant can answer questions and guide customers to a booking. Here are practical boundaries for prices, delivery times, personal data, and contact with a staff member.

Google and Bing now offer first-party AI search visibility reports. Here’s how to build a useful baseline without inventing a misleading GEO score.

AI crawlers can copy a familiar name. Here’s how to verify signed agents at the edge while keeping legitimate automated traffic moving.

A critical Webform release is a reminder to audit every Drupal codebase, configuration and deployment—not just the main production website.

A secure AI workflow can turn Meet and Teams transcripts into approved decisions and tasks in Jira or Asana—without giving up control.

NGINX 1.31.5 can route on JSON body values. Here’s how to weigh the performance, security, and operational trade-offs before using it.

OpenAI can keep agent sessions running, but reliable workflows still depend on clear failure states, safe retries, validation, limits and human fallback.

AI can identify termination deadlines and price adjustments in supplier contracts, route uncertain findings for approval and create the right reminders.

Why a DNS record can exist in a dashboard yet fail publicly—and how to trace zone cuts, verify glue, and fix the right side of a live delegation.

An Apache version below 2.4.68 may still be patched. Package provenance, vendor advisories, module checks and runtime evidence reveal the real position.