Changing AI providers: What your export needs to include

“You can export your data at any time.” That sounds reassuring. It does not establish that you can change AI providers. A contact CSV is not an operational phone assistant, and a search-index backup does not replace the original documents. Once an AI service matters to daily work, check which parts another provider can actually rebuild.

Do that before dependency becomes urgent. You do not need to be planning a constant switch. You need enough documentation to retain practical options. Ask for a specific handover package and test it against a limited workflow. A successful reconstruction outside the original environment tells you more than a broad statement about ownership.

List the parts that support your operation

Start with source documents, structured customer records, conversation rules, tool interfaces, approval boundaries, test cases and unfinished tasks. A phone assistant also needs call routes, ownership of numbers and staff-transfer destinations. A knowledge chatbot needs document versions and access permissions. A single export rarely covers every part.

Distinguish your material from purchased services and provider-specific technology. You might own the FAQs and test cases without holding rights to the underlying model. Address those questions explicitly in the agreement. The existence of an export button does not create a universal right to model weights, internal tools or the supplier’s complete infrastructure.

A handover package you can use

Part	What is included	How to check it
Sources	Original files, versions and stable identifiers.	Trace an answer to its current source.
Operating rules	Owners, boundaries and exceptions.	Run an exception in the new setup.
Interfaces	Field meanings, endpoints and permissions.	Write a test task and read its status.
Unfinished cases	State, owner and next action.	Continue an existing case correctly.

Include a readable inventory explaining each file, required fields and the meaning of states such as open or approved. A date without a timezone can distort an appointment. An unexplained customer identifier can create duplicates on import. These details are easy to overlook but determine whether the receiving team can use the export.

Test backup and portability separately

A backup may work well for restoration within the same product while being unsuitable for migration. The Qdrant snapshot documentation describes product-specific restoration. That does not mean an unrelated search system can directly import the same snapshot.

The Azure guide to moving regions also covers recreating indexes and related components. Changing systems often requires original documents, their metadata and a reproducible indexing procedure. Exported vectors may also depend on the previous embedding model. A different model may produce different representations. What matters is whether the necessary answers and permissions can be rebuilt from the preserved sources and checked again.

Make the rules readable

An exported prompt helps, but it is not the entire operating logic. Some rules live in configuration screens, others in webhooks, tables or code. Describe their business meaning separately: which details are required before booking, when the assistant asks a question and who decides an exception.

Do not blindly copy every previous setting into a new product. A provider-specific tool operation may behave differently there. The replacement must make the same business decision, rather than reproduce the same character sequence. Keep anonymised tests and expected results. A case with a missing customer number can reveal more than ten ordinary greetings.

Try a genuine reconstruction

Choose a limited function, such as collecting a service request without confirming an appointment. In a separate test environment, supply the sources, rules and a simulated interface. Do not grant production write access. Test the ordinary case, missing information, a prohibited action and an unavailable destination.

Evaluate more than tone. Is the customer identifier assigned correctly? Does an unconfirmed appointment remain unconfirmed? Can an unfinished task continue under its previous identifier? Can a reviewer understand why a decision was made? These questions establish whether the package supports operations or merely contains files.

Record missing components and the work required. If an allocation only succeeds because the previous administrator remembers an undocumented rule, put that information into the package. The exercise is not a competition demonstration. Its purpose is to expose gaps while you can still close them without an urgent service interruption.

Agree a cutover point

Decide when the old system may last write and when the new one takes over. Monday’s export does not automatically contain Tuesday’s complaints. Reconcile new and changed records during the transition. Two assistants writing at once can generate duplicate tasks even when each works correctly in isolation.

Assign an owner for telephone numbers, domains, accounts and API access. Credentials need controlled transfer or replacement followed by verification. A secret should not sit inside a broadly shared export archive. Agree how residual data at the former provider will be handled and how those steps will be documented.

Keep a rollback path for the limited transition period. It should explain which system is authoritative and how records created after the switch are recovered if you return to the previous service. Reverting traffic alone does not reconcile those records. Test this with sample tasks before customer requests are involved.

Questions to ask before signing

Ask about formats, export frequency, handover scope and charges. Who performs the export, how are open cases explained and which components cannot be transferred? Request a sample package. An explicit limitation is more useful than a universal “Everything is possible.” Put the agreed deliverables and responsibilities into writing.

Review the handover after a substantial workflow change. A new calendar or document source can create another dependency that the original package never described. The company’s operating owner should know where the current package lives and when it was last tested. Export access that only one former employee understands is not a reliable exit arrangement.

Check the export is complete

Before import, compare the package with the existing operation. Do the identifiers and count of unfinished cases agree? Are attachments accessible? Can the recipient interpret empty fields and unusual characters? One tidy sample does not establish that the whole collection arrived. Agree the completeness checks with the data owner and record the export time and format version. Use fictional or appropriately anonymised material for early reconstruction tests; do not distribute complete customer conversations to every prospective supplier.

General AI supplier due diligence remains useful. The reconstruction exercise answers the narrower question of changing providers. In AI consulting, bring an existing workflow, sample export and unfinished cases. We can establish which handover you actually need, with a concrete package and visible gaps to resolve.