A provider switch depends on the surrounding workflow as much as the model. Agree export, responsibility and acceptance before the move becomes urgent.
What you'll learn
- Check which connections and stored information can carry over.
- Work from the actual model and hosting service’s retirement notice.
- Test the replacement and agree a fallback before moving live work.
Changing the AI behind your agent can affect instructions, tool connections, saved information and testing. Some parts may carry over; others need adaptation. Before relying on the option to switch, agree who owns the work, how your data leaves and how the replacement proves it can handle the same tasks. Model retirement policies provide planning time, but their exceptions and model-specific dates matter.
Changing the AI behind your agent can affect instructions, tool connections, saved information and testing. Some parts may carry over; others need adaptation. Before relying on the option to switch, agree who owns the work, how your data leaves and how the replacement proves it can handle the same tasks. Model retirement policies provide planning time, but their exceptions and model-specific dates matter.
This page covers the work and the responsibilities in a planned move. Keep an emergency fallback separate from the longer job of qualifying a permanent replacement.
What actually changes when you switch AI providers?
Review the instructions, tool compatibility, credentials, stored information, tests and changeover. These are work areas to inspect, not a promise that every part must be rebuilt. Provider adapters can reuse some connections while leaving feature differences to resolve.[3]
- The instructions. Run the existing instructions against representative tasks before rewriting them. Look for changed tone, missed conditions, incorrect tool choices or a failure to ask for approval. Preserve what still works; adjust the parts that no longer produce acceptable behaviour. Keep the old and new versions so the operator knows what changed.
- The tool connections. Check what the replacement supports: attached files, structured records, searches and actions may travel differently. An adapter can translate some requests. A provider-specific hosted search or conversation feature can require a different implementation. Test a normal action, a refused action and a failed connection, rather than assuming the same interface means identical behaviour.[3]
- The credentials and service settings. Arrange the new account, permissions, spending controls and operating limits. Keep the provider choice in a documented place. Confirm who can revoke the old credential after the changeover and how the team recognises a request still being sent to the old service.
- The saved history and document index. Inventory where each is stored and whether it can be exported. The model that answers questions and the model that prepares documents for search need not be the same. If the search model stays unchanged, changing the answering model does not by itself require rebuilding that index. If the search model changes, rebuild compatible document and query representations together.[4]
- The testing. Keep the same business test cases and acceptance criteria so the comparison remains useful. Re-run them on the replacement, including permissions and failure handling. OpenAI’s evaluation guidance recommends running evaluations on changes; an earlier pass belongs to the earlier setup.[7]
- The changeover. Choose a controlled trial and a return route. Compare the new model on copies of work or in a read-only trial before giving it live authority. Running both versions must not mean both send the same message or update the same record. Name the person who can approve the move or stop it.
A model setting can be a small change while the operating decision remains substantial. Ask which connections carry over, which need work and what tests will show that the replacement is ready.
How much warning do you get if your model is retired?
In October 2026, OpenAI publishes minimum notice periods of six months for generally available models and three months for specialised variants, unless safety or compliance concerns require a faster timeline. Preview models may receive much shorter notice, such as two weeks.[1]
Anthropic’s published policy provides at least 60 days for publicly released models and notifies customers with active deployments. Its records show Claude Opus 3 retired on January 5, 2026. Its separate preservation commitment keeps model weights for at least the company’s lifetime; that is not a promise to keep your old model publicly available.[2][6]
Use the actual notice for the exact model and hosting service. Partner-operated platforms can set different schedules. Microsoft Foundry’s published active notifications specify at least 60 days for generally available models and 30 days for preview models. Do not assume a direct provider’s window transfers unchanged to a hosted deployment.[2][5]
Assign an owner for retirement notices and ensure the email reaches someone who can act. Keep the replacement task on the operating calendar, including testing and sign-off. A general policy is useful for planning, but the model-specific date and your agreement are what the team must work from.
Why can't you just point it at a new model?
The replacement may handle the same instructions, files and tool requests differently. OpenAI’s provider documentation specifically warns about feature differences, including unsupported tools and structured output. A shared connection format does not make every feature portable.[3]
Say your current agent drafts an order confirmation and extracts the delivery date into your order system. The replacement needs to handle both the wording and the exact date field. A reply that looks fluent can still put the wrong value in the record. Test the whole task, including the case where the date is missing and the agent should ask.
That does not mean rewriting everything. Start with the existing instructions and the same test cases. Change the parts that fail, inspect what the change affects elsewhere and record the final behaviour. The useful question is what must change for your workflow to pass its acceptance checks.
How long does a provider switch take?
Get an estimate against your actual connections, stored information and acceptance tests. A useful plan names the work, its dependencies and the person responsible for each decision, rather than giving a universal migration duration.
Tool compatibility. List what can be reused and what depends on a provider-specific feature. Ask the implementer to demonstrate a representative connection before treating the rest as routine. Separate adapting a connection from testing the business action it carries.
Stored information. Confirm whether you are moving conversation history, documents, a search index or all of them. An index rebuild belongs in the plan when the search representation changes, not automatically whenever the answering model changes.[4]
Documented behaviour. Give the new operator the instructions, approved examples, failure cases and expected limits. If those records are missing, allow for reconstructing the workflow before estimating the change. Agree who reviews ambiguous cases and who can accept the final result.
For example, a drafting-only assistant with locally held documents has a different change plan from an agent that updates orders and relies on the old provider’s hosted search. The latter plan must include the replacement search service, its permissions and the order-action tests. Ask for a trial on that real dependency before agreeing a deadline.
Keep contingency separate from the planned work. If the old service stops before the replacement passes, identify which tasks return to people and which can safely pause. A migration date is useful only with an operating plan for the work that cannot move yet.
Whose job is the switch, yours or your provider's?
Agree the responsibilities in the support contract. The setup partner can handle technical changes, while your team owns the business decision and acceptance.
Ask whether model migration is included, what triggers extra work and who owns the export. A managed service label alone does not settle the scope. Keep these responsibilities explicit:
- The decision. Whether to switch, and when.
- Access to your data. Providing the history and documents that need rebuilding.
- The contract terms that let your data leave in a usable form.
- The downtime call. Accepting the changeover window.
| Part of the switch | Suggested responsibility to agree |
|---|---|
| Re-tune the instructions | Setup partner |
| Adapt if needed and re-test tool connections | Setup partner |
| Swap keys and endpoints | Setup partner |
| Rebuild the search index if needed | Shared. You give access, they run it |
| Re-run the tests, fix what regressed | Setup partner |
| Decide to switch, accept the changeover | You |
From your side, a well-run switch is quiet. The partner flags the retirement or the reason for the move, re-tunes the instructions and rebuilds the connections behind the scenes, and runs the new model alongside the old one for an agreed trial. You get a short report showing the tests pass, you sign off, and real work moves across. The visible part is a review and a sign-off, not a rebuild you have to manage.
This is why lock-in is not really about the model. You are not tied to a model. You are tied to the setup around it, and how portable that setup is depends on whether it was built to be handed over. Yardwork stays involved after launch, so a provider switch is work we handle, not a job that lands back on you.
What forces a switch?
Plan for these possible triggers. Each has its own contractual and operational timetable.
- A retirement. The provider ends the model. Work from the model-specific notice and test the replacement. This is the one case you can plan for calmly if the setup is portable.
- A price rise. The provider raises the price the setup's running cost was built on. Check the price-change notice in your agreement and how long your budget can absorb the new rate.
- A terms change. The provider changes its data-handling terms or where it processes data, the kind of change covered in AI data residency. If the new terms do not work for your obligations, the timeline is set by when the change takes effect, not by you.
- An outage. Sustained downtime or a drop in answer quality forces a move on the shortest timeline of all, because it is already costing you every day it continues.
- The provider shuts down or is acquired. A smaller provider folding into a larger one can bring a new price, new terms, and a migration deadline at once. Check the agreement, announced changes and available exit route.
Do not apply a model-retirement policy to every trigger. Record who monitors availability, cost and contractual changes, and who can activate the fallback.
What should you ask before you commit to a provider?
Three questions, before you sign, not after. They decide whether a future switch is a task list or a rebuild. The rest of the evaluation, covered in how to choose an AI implementation partner, matters too, but these three are specific to lock-in.
- Can my data be exported in a usable form? The conversation history and the documents the agent works from should be able to leave in a standard format. Get that in writing.
- Who handles a model switch, and is it included? A partner who has done one has a concrete answer: the instruction pass, the tool re-tests, the changeover window. Ask for the inclusion and any exclusions in writing rather than inferring them from the sales discussion.
- Is the setup written down? The instructions, the tool connections, and the tests should exist in a form another team could pick up. If they only live in one person's head, that is the lock-in.
None of this removes the work a switch takes. It turns it into a scoped job with a known shape instead of a surprise rebuild.
What this page does not cover
Provider migration planning needs the actual workflow and agreement, rather than a model ranking or a general contract promise. Match the replacement to your actual tasks, data obligations and operating limits.
Keep planned change and emergency response separate. If the replacement has not passed, return affected tasks to the agreed fallback. Do not give it live authority merely because the old model’s deadline has arrived.
Provider policies and model-specific dates can change. Keep a named owner for the retirement record, and confirm which service your application actually uses before acting on a notice.
Frequently asked questions
What happens when you switch AI model providers? Review instructions, tool compatibility, credentials, stored information, tests and changeover. Reuse parts that still work. Rebuild a document index when its search model or storage arrangement requires it, not automatically whenever the answering model changes.[3][4]
How much notice do you get before an AI model is retired? OpenAI publishes six-month GA and three-month specialised notice periods with safety/compliance exceptions; preview notice can be as short as two weeks. Anthropic publishes at least 60 days for publicly released models. Check the exact model and hosting platform’s notice rather than treating these as an unconditional guarantee.[1][2]
Does an abstraction layer remove AI provider lock-in? It can reduce connection work, but it does not make unsupported features compatible or prove the replacement behaves correctly. Check each dependency and repeat the business acceptance tests.[3][7]
How do you avoid being locked into one AI provider? Keep instructions, connection details and test cases portable. Agree data export, migration responsibility, included work and a fallback in writing. Demonstrate the export and a representative replacement workflow before depending on the option to leave.
Notes
- Deprecations. Living policy; October 2026 Accessed October 15, 2026.
- Model deprecations. Living policy; October 2026 Accessed October 15, 2026.
- Models — OpenAI Agents SDK. Living documentation; October 2026 Accessed October 15, 2026.
- Vector embeddings. Living documentation; October 2026 Accessed October 15, 2026.
- Foundry Models lifecycle and support policy. Living documentation; October 2026 Accessed October 15, 2026.
- Commitments on model deprecation and preservation. November 4, 2025 Accessed October 15, 2026.
- Evaluation best practices. Living documentation; October 2026 Accessed October 15, 2026.
- When the Model Retires: An Empirical Study of LLM Migration in Open-Source Applications. September 25, 2026 Accessed October 15, 2026.
