How to Migrate AI Agents to a New Provider, Step by Step

To migrate AI agents to a new provider without interrupting daily work, inventory everything the agent depends on, export what your company owns, run the old and new setups side by side on real tasks, and cut over only when checks agreed in advance pass. Keep the old setup available for rollback until the new one has handled a normal business cycle. Treat the switch as an operations project with a technical part, not the other way around.

Key takeaways

• An agent is more than a model. Identity, instructions, memory, tools, permissions and channels all have to move, and each moves differently.
• Inventory first. Most migration surprises come from dependencies nobody wrote down, such as a hosted memory feature or a scheduled task.
• Test the new setup on a set of your own real tasks, with pass criteria agreed before anyone sees the results.
• During the parallel run, only one agent may write to any system at a time. Otherwise customers and colleagues get duplicates.
• Cut over with a named rollback path, and revoke old credentials only after the new setup has proven itself.

What actually moves when you change AI provider?

The word provider covers several different changes, and the work depends on which one you are making. You might be changing the language model behind the agent, the platform that hosts and orchestrates it, the integration vendor that connects it to your tools, or all three together. A model change leaves your channels and permissions mostly intact but alters how the agent behaves, even with identical instructions. A platform change leaves the model's behavior closer to familiar but can break memory, scheduling and every connection around it.

Before planning anything, write one sentence that states what is changing and why. For example: we are moving the agent from one hosted platform to another and keeping the same model family. That sentence sets the scope of testing and tells you which parts of the agent you can expect to behave the same.

It also helps to separate what your company owns from what the provider owns. Instructions you wrote, documents you supplied and accounts opened in your company's name should be yours to take. Proprietary memory formats, platform-specific workflow definitions and tuning done inside the provider are often not. The article on what to keep, export and document when leaving a provider covers that division in more depth, and it is worth reading before you give notice to anyone.

Step one: inventory the agent as a role, not a prompt

A prompt is only one file in a larger arrangement. Inventory the agent the way you would document a colleague's job before they change teams. Walk through each of these and write down the current state:

• Role definition: what the agent is responsible for, what it must never do, and who it reports to.
• Instructions: system prompts, tone guides, escalation rules and examples, with a note on which ones were tuned around quirks of the current model.
• Memory and knowledge: documents, notes, conversation history and retrieval indexes, and where each one is actually stored.
• Tools and integrations: every system the agent reads or writes, the scope of access, which credential it uses and who owns that credential.
• Channels: email addresses, chat workspaces, shared inboxes and any other place people reach the agent.
• Permissions and approvals: which actions run on their own, which wait for a human, and who approves.
• Logs and evaluations: existing test cases, past incidents, review notes and anything that records what good looks like.
• Provider-only features: built-in schedulers, hosted memory, proprietary tool formats, anything that will not exist elsewhere.
• People: who uses the agent daily, who owns it, and who will notice first if it misbehaves.

Then mark every line with one of three labels: portable (moves as is), convertible (moves after reformatting or rewriting), or provider-specific (must be rebuilt). The provider-specific list is your real migration risk. It is usually shorter than people fear, but it is almost never empty.

Step two: export what your company owns

Start exports early, because some providers take time to fulfil them and some formats need cleaning before they are useful. Ask for exports in readable, documented formats, and confirm that you can actually open and use them. An export that nobody has tried to restore is a hope, not a backup.

Several kinds of material need different handling:

• Instructions and role documents: store them in your own repository or document system, with version history, rather than only inside the provider's console.
• Knowledge sources: keep the original documents as the source of truth. Retrieval indexes are usually rebuilt on the new side, not copied.
• Memory: decide what deserves to be carried over. Curate it. Stale facts, outdated preferences and sensitive details that no longer serve a purpose are better left behind.
• Conversation history: carry over what supports ongoing work, such as open cases, and archive the rest under your retention rules.
• Credentials: do not reuse keys that belong to the old provider's accounts. Create new ones in company-owned accounts and treat the move as a chance to tighten scope.

Ownership is where migrations stall, so check it now rather than during the cutover. If you are unsure which of these your contract lets you take, the guide on who owns your AI prompts, memory and data lays out the questions to ask.

One structural note on tools: standards such as the [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro) exist to describe how an agent connects to external systems in a consistent way. Where your tools already follow a shared interface, reconnecting them to a new platform is much less work than rewriting each integration.

Step three: rebuild and test against real work

Expect to adjust instructions. A prompt tuned over months to one model's habits will not transfer perfectly, because models differ in how literally they follow rules, how much detail they volunteer and how they handle ambiguity. Start from your role definition rather than copying old prompts word for word, then reintroduce the specific rules that earned their place.

Re-check tools and permissions at the same time:

• Rewrite tool descriptions if the new platform reads them differently, and test that the agent picks the right tool for the right job.
• Give the agent its own identity on every connected system, with the narrowest access that lets it do the work. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is a sound reference for least privilege.
• Confirm that approval steps still fire. An action that required a human yesterday must not run unattended today because a setting did not carry over.

Then build a test set from your own work. Pull a representative sample of past tasks, including the ordinary ones, the awkward edge cases, the requests the agent should decline and the ones it should escalate. For each, write down what an acceptable result looks like in terms of the work, not the wording. Anthropic's piece on [evaluating AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) is a useful guide to structuring this. Agree the pass criteria before running anything, so nobody adjusts the bar after seeing the results.

How should a parallel run work?

A parallel run means the old and new agents handle the same real inputs for a period, while people compare the results. Do it in stages, and widen only when the previous stage is clean:

• Shadow stage: the new agent receives copies of real requests and produces outputs, but nothing leaves the building. Reviewers compare its work to the old agent's.
• Supervised stage: the new agent drafts and a person approves every outward action. The old agent remains the one actually acting.
• Limited live stage: the new agent acts on a small, low-risk slice of work, with the old agent still available for the rest.

One rule matters more than any other: at any moment, only one agent should hold write access to a given system or channel. If both can send email or update records, you will get duplicate messages and conflicting changes, and cleaning that up is slower than the migration itself.

Log both agents with the same fields so comparison is easy: the input, the tools called, the output, the time taken and whether a human changed anything. The [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) explains how traces and logs fit together if you want a shared vocabulary for this.

Here is an illustrative scenario. An operations team has an agent that triages supplier emails, drafts replies and updates a shared tracker. During the shadow stage, the new agent matches the old one on routine order questions but handles requests for late-delivery credits too eagerly, offering resolutions it should escalate. The team adds an explicit escalation rule, reruns the credit-related cases from the test set, and only then moves to the supervised stage. Nothing reached a supplier while the problem was being found.

Sort the differences you find into three groups: regressions that block cutover, differences that are acceptable or even better, and gaps that can be fixed after cutover. Writing the groups down keeps the cutover decision about evidence rather than mood.

Step five: cut over with a rollback path

Cutover is the moment write access and channels shift to the new setup. Done well, it is dull. A plan that works for most teams:

• Step one: pick a quiet window and tell the people who use the agent what will change, what will not, and whom to contact. Guidance on bringing a team along with an AI agent applies here as much as at launch.
• Step two: freeze changes to instructions and tools on both sides until cutover is complete.
• Step three: confirm the pass criteria from the test set and the last parallel stage are met, and record who signed off.
• Step four: move write access and channel routing to the new agent, and remove them from the old one in the same sitting.
• Step five: watch the first days closely, with a named person reviewing outputs and a simple way for colleagues to flag problems.
• Step six: keep the old setup intact but inactive, with a written trigger for rolling back, until the new one has handled a normal cycle of work, including the busy and awkward moments.

Only after that should you decommission. Revoke the old credentials, delete or archive exported data according to your retention rules, ask the old provider to confirm deletion in writing, and close the accounts. Then update your inventory so it describes the new reality. The principles in updating a live AI agent without breaking it cover the same discipline of staged change and rollback, which a provider switch simply applies at larger scale.

How Be Human handles provider migrations

Be Human operates agents on infrastructure where identity, memory, channels, tools and permissions are documented and kept under the company's control, so a provider change starts from an existing inventory rather than a blank page. For a migration, we map each component as portable, convertible or provider-specific, rebuild the role on the new side, test it against a set of the company's own tasks, and run old and new in parallel with only one holding write access. Cutover happens with an agreed rollback trigger and approval boundaries unchanged, and the old credentials are retired afterward as part of managed operations.

Frequently asked questions

How long does a provider migration take? It depends on how many tools the agent uses, how much of its memory is portable and how long your parallel run needs to cover a normal cycle of work. A narrow agent with few integrations can move quickly, while one with many connected systems needs more testing. Plan around the evidence in the parallel run, not a fixed date.

Will the agent behave exactly the same after the move? Not necessarily, especially if the underlying model changes. Models interpret instructions differently, so expect to tune wording, escalation rules and tool descriptions. That is why a test set built from your real tasks matters more than any claim of equivalence.

Should we migrate everything at once or one agent at a time? One agent or one role at a time is usually safer. The first migration teaches you which parts of your inventory were incomplete, and that learning makes each later move cheaper. Start with a role where mistakes are easy to catch and reverse.

What if the old provider will not release our data? Check your contract and the ownership terms before you start, since this is far easier to address early. Keep the original documents and instructions in your own systems so that the most important material never depends on an export. If something is truly locked in, treat it as provider-specific and plan to rebuild it, and let the lesson shape your next provider's terms.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.