Switching AI Providers: What Your Business Needs to Take With It

Could your assistant leave without taking your enquiry process with it?

Before changing an AI supplier, ask for a small migration rehearsal: take an approved set of business information and sample questions into a separate test environment, then check whether the replacement can support the same customer task. That provides more useful evidence than an export file sitting in a folder.

For a UK small business, the risk is often practical. Your assistant might know which enquiries to pass to sales, which details to collect and when to stop answering. If that knowledge exists only inside one supplier's account, moving can mean rediscovering decisions you already paid to make. The aim is to retain those decisions and a working contact route, while accepting that some components may need rebuilding.

Start this conversation while the current service still works. You do not have to run two suppliers permanently or abandon useful platform features. You need to know what depends on the supplier, who controls it and what a change would involve.

A model change and a supplier change are different projects

A model is the component that produces an answer. Your service may also contain document search, a conversation interface, rules, account permissions and connections to other systems. Changing a model can leave much of that surrounding service intact. Changing the platform or delivery supplier can affect all of it. Ask which change the proposal actually covers.

There is a current reason to check the distinction. Anthropic's documentation, checked on 3 November 2026, lists Claude Sonnet 4.5 API retirement for 30 November 2026, following a notification dated 30 September. This is an existing announced deadline, not news announced today. If your service uses that model, ask the developer to confirm the exact model identifier and purchasing platform, then check the applicable migration guidance. Do not assume a similarly named consumer product has the same timetable.

Even when the replacement comes from the same provider, test your own tasks. A familiar chat window does not establish that field extraction, refusal behaviour or escalation still meets your requirements.

Anthropic: model lifecycle and the announced Sonnet 4.5 retirement

Inventory the business assets before discussing an export

Make a short register of the things needed to reproduce the service. Include approved source documents, instructions, routing rules, enquiry fields, integration mappings and the examples used to decide whether an answer is acceptable. Name an owner and location for each item. A list of software subscriptions is not enough.

Separate original knowledge from the supplier's processed copy. Keep the maintained product information, policies and contact rules in a location your business controls. If a search index needs rebuilding elsewhere, the original material and its access rules should still be understandable. Record which sources are current and who may approve changes.

Do not turn this inventory into an unrestricted collection of customer conversations. Keep only records you are entitled to retain and use, under your existing access and retention arrangements. For a rehearsal, deliberately written fictional examples can test the workflow without copying private enquiries into another service. Credentials should stay in the appropriate secure configuration, with access recreated through an authorised process.

Ask what the export leaves behind

Microsoft's Copilot Studio guidance describes moving agents between environments using solutions. It also lists exclusions and dependencies: not every component or property is included, and custom connectors need the appropriate import order. This demonstrates why a supported export still needs checking. Moving within that platform is not evidence that the package will run on a different vendor's platform.

Ask the supplier to show the contents and identify the missing pieces. Can someone read the instructions? Where are the source documents? Which connections must be recreated? What happens to channel settings, permissions and records of unfinished work? Ask for answers specific to the product and version you use rather than a broad claim that the service is portable.

A missing item is not automatically a reason to reject a platform. It is a cost or dependency to understand. A convenient managed feature may still be the right choice if its benefit is clear and the rebuilding effort is acceptable.

Microsoft: export and import agents using solutions, including exclusions

Run a rehearsal around one real business task

Consider an illustrative engineering business whose website assistant helps visitors prepare a quotation enquiry. The test task is simple: collect a description, material, quantity and requested date, then hand the request to the ordinary enquiry process. The assistant must not promise a price, delivery slot or acceptance of a confidential drawing. This is a fictional planning example.

Create a small set of fictional questions covering a normal enquiry, missing details, an unsupported service and a request for a commitment the assistant cannot make. Agree the expected next action for each. Repeat those cases in the proposed replacement, using the same approved source information. Judge the outcome and handover, not whether the wording is identical.

Check the integration separately. Does a test enquiry arrive once, in the intended test queue, with the required fields and an owner? If the AI component is unavailable, can a visitor still use the normal form? Keep these checks away from live customers until the responsible team approves the release. Do not infer readiness from a polished demonstration alone.

Choose the amount of independence that is worth paying for

The UK government's cloud lock-in guidance balances portability against the value of integrated services. It recognises that accepting some dependency can be reasonable. That is public-sector guidance, not a rule imposed on your private business, but the trade-off is useful when assessing an AI proposal.

For a small assistant with a dependable manual fallback, a documented rebuild route may be enough. A workflow that customer operations depend on may justify a more complete migration rehearsal, clearer separation between components and a recovery plan. Requiring every feature to work on every provider can add engineering and support work without solving your actual risk.

Ask for two estimates: the effort to change the model within the current service, and the effort to move the wider workflow. Include document preparation, integration changes, testing, staff handover and any period of overlapping service. No general price is reliable without that scope. The useful buying decision is whether the current benefit justifies the dependency you are accepting.

UK Government: balancing cloud portability and provider value

Write down the changeover and the way back

Before a move, agree who authorises it, which checks must pass and how new enquiries will be handled during the transition. Identify unfinished work that needs reconciling so the old and new services do not both act on the same request. Keep customer communication accurate: a saved chat message is not necessarily a delivered enquiry.

Define a rollback condition in plain language. For example, if the replacement fails the agreed enquiry-delivery checks, the team restores the previous route where it remains available, or uses the normal contact form while investigating. A rollback plan cannot depend on a model that has already retired. Prepare and test the fallback before the deadline.

After a successful change, review actual enquiries and errors with the responsible team. Retire old access and copies according to the agreed process once they are no longer needed. Keep a brief record of what moved, what was recreated and what the rehearsal did not establish. That record makes the next change less dependent on someone's memory.

The five questions to put in your next supplier meeting

Ask who controls the business knowledge, which parts can be exported, which parts must be rebuilt, how the replacement will be tested and what customers can do if it fails. Request a named owner and a concrete piece of evidence for each answer. You are buying the ability to keep a business process working, not just a different answer generator.

A useful first engagement can be small: inventory one assistant, choose a representative enquiry task and rehearse it away from production. The result might support staying with the existing provider. It might reveal a modest change that makes future migration easier. Either outcome is more useful than assuming a download button has settled the question.