By Greg Nowak. Updated 5 November 2026.
An AI integration can work perfectly today and still have a deadline approaching. When its provider retires a model or changes the API behind it, your support assistant, document processor or internal automation may need attention even though your application has not changed.
For a business owner, the practical question is whether the team can make that change without disrupting customers or creating a backlog. Build a migration lane early: a repeatable process for finding dependencies, testing replacements, releasing safely and recovering when something goes wrong.
A retirement notice can mean more than an outage
The deadlines are concrete. Anthropic currently lists claude-sonnet-4-5-20250929 for retirement on 30 November 2026. Its deprecation guidance also explains that partner-operated platforms can follow different schedules.
Some changes happen while requests continue succeeding. Google says requests to gemini-2.5-pro will automatically route to Gemini 3.8 Flash from 1 December 2026, with the replacement's billing rates. Its deprecation schedule flags breaking API changes to review beforehand. A responding endpoint does not prove that the workflow still behaves as expected.
Find the dependency and the person responsible
Start with one business-critical workflow. Trace the exact model identifier through application code, environment variables, cloud deployments, automation platforms, scheduled jobs and fallback settings. Include monthly jobs: they may escape everyday monitoring.
Keep a shared register containing:
- Dependency: provider, hosting platform, endpoint, exact model version and configuration location.
- Accountability: technical owner, business owner and affected customer or client workflow.
- Deadline: lifecycle status, retirement date, automatic upgrade behaviour and candidate replacement.
- Operating baseline: volume, quality, latency, cost, tools, output schema and data sensitivity.
- Recovery: switching procedure, available fallback and the last date the old model remains usable.
For agencies, record whose account receives provider notices and who funds maintenance. A warning sent to an unused developer inbox is unlikely to become a scheduled piece of work.
| Migration gate | Evidence required | Who confirms it |
|---|---|---|
| Dependency mapped | Production references, hosting details and deadline | Technical owner |
| Compatibility checked | Valid requests, tool arguments and output schemas | Implementation team |
| Business task tested | Representative cases meet agreed acceptance criteria | Workflow owner |
| Release controlled | Limited traffic, monitoring and stop conditions | Release owner |
| Recovery rehearsed | Working switch or documented operational fallback | Operations owner |
Separate API compatibility from business quality
A replacement needs to pass two tests: can the application call it correctly, and does it still perform the job?
Check supported parameters, authentication, context limits, streaming events, tool calls and structured outputs. An API migration can also change how conversation state is managed. OpenAI's deprecation register, for example, records the Assistants API shutdown on 26 August 2026 and identifies Responses and Conversations as replacements. Changing a model identifier alone cannot migrate an endpoint.
Then test business outcomes. Valid JSON can still contain the wrong invoice total. A fluent support answer can still promise something the business cannot deliver. Ask the person responsible for the workflow to define what acceptable means before reviewing the replacement's answers.
Replay real work before sending real traffic
Build a small, versioned test set covering ordinary inputs, valuable edge cases, long or malformed documents, tool calls and requests that should reach a person. Remove or replace confidential and personal information where necessary.
Automate checks for required fields, schema validity, correct routing and valid tool arguments. Use human review for factual accuracy, usefulness and tone. Repeat important cases because model responses can vary.
Compare latency, failures, token consumption and cost per completed task, including retries and manual corrections. Microsoft's model migration guidance likewise treats measurable application behaviour as the basis for a successful move.
When replaying workflows that send emails, update records or place orders, replace those actions with test substitutes. Evaluation should reveal mistakes without carrying them into customer systems.
Create one controlled place to switch models
Centralise model selection and provider-specific settings where practical. Configuration names such as AI_MODEL_PRIMARY and AI_MODEL_CANARY can make the active and trial routes visible; these are application conventions your team must implement.
Keep prompts, schemas and related settings versioned together. A model-only switch may be insufficient if the replacement requires different parameters or instructions. Record the requested model and, where available, the model actually served alongside errors, timing and usage.
The wrapper should expose provider differences explicitly. Automation platforms outside it still belong in the dependency register.
Release while recovery is still possible
Start with internal users or a limited share of suitable traffic. Define stop conditions before increasing exposure: unacceptable routing errors, schema failures, slower responses or rising manual review effort.
A recovery note should identify the configuration to restore, the responsible person and the check that confirms service has recovered. Rehearse the switch while the old model is available. If prompts or schemas changed too, restore a compatible set.
After retirement, the previous model cannot be your fallback. Prepare an alternative such as a tested second model, a manual review queue or temporarily pausing the affected feature.
Make the next migration easier
Review provider notices and the register regularly, with closer attention to preview models and approaching deadlines. After release, check infrequent jobs, remove obsolete references and retain the evaluation set for the next change.
If ownership or scope is unclear, start with one workflow and its nearest deadline. Greg can help map dependencies, agree acceptance criteria and coordinate the technical work and release. Talk to Greg about planning your AI model migration.
Related on GrN.dk
- Your AI workflow has logs. Can they explain one bad decision?
- Model Retirements Are Quietly Breaking AI Integrations
- AI Agents Need a Spending Brake, Not Just a Billing Dashboard
Need help with this kind of work?
Plan your AI model migration with Greg Get in touch with Greg.
