Guide

Switching AI solutions without losing everything

What you recover, what is really lost, the clauses to demand from the next vendor, and the architecture that makes the next change painless.

Published July 20, 2026

The decision to change AI tools often comes long after the failure is obvious, held back by one fear: losing everything and starting over. The reality of a migration is more favourable: the essential is recovered, what is lost matters less than expected, and the real stake lies elsewhere: not reproducing with the next vendor the dependence that is costing you today.

What you recover

Your documents, first: they never belonged to the tool. The document system, the case files, the letter templates remain yours, and the sorting done for the first project - which documents matter, which are current - remains acquired.

The knowledge of your use cases, next. The first tool revealed where AI helps and where it fails, which questions keep coming back, which processes are worth the investment. That lived requirements list is worth more than any scoping workshop.

The teams, finally. They learned to phrase requests, to distrust answers without sources, to spot what works. The disappointment trained their standards: that is an asset, not a scar.

What is lost, and why it is acceptable

The index of your documents is lost, and rebuilt: it is a by-product of your files, not capital. The conversation history is usually lost too; its real value is low, because the useful answers have already been used where they served. The proprietary configuration does not transfer, and that is precisely the sign it should never have locked in your processes.

One exception deserves care: if teams have built habits on the tool, the migration is planned with them, process by process, with no hard cutover.

The clauses to demand before signing again

Dependence is not fought at the moment of leaving; it is refused at the moment of signing. Before any new commitment, demand in writing:

  • export of your data in standard formats, with a delay and assistance;
  • the location of processing and the operator's jurisdiction, in black and white;
  • a consultable audit log, which remains accessible at the end of the contract;
  • the identity of the system's operator and their service commitments;
  • a full reversibility clause: what is handed back to you, in which format, within what time.

A vendor who negotiates these clauses badly is informing you usefully, before it is too late. This grid matches the seven questions of an audit: what an auditor will demand tomorrow, demand it in the contract today.

The architecture that makes the next change painless

The durable lesson goes beyond choosing a vendor. A sound architecture separates three things: your data, the tool that exploits it, and the model that reasons. When these three layers are distinct, replacing the model becomes a revisable technical decision - the model landscape shifts every six months - without touching the data or redoing the processes.

That is the principle of the Workspace: your instance, your data in France, models replaceable by design, chosen per task rather than imposed by the vendor. Leaving the first tool is the occasion to put that separation in place once and for all.

Frequently asked questions

Will the migration interrupt the teams?

No, if it is carried out process by process: the old tool remains available for consultation while the first process switches over, and each team changes when its flow is ready. A hard cutover is a choice, never a fatality.

Our provider refuses to hand over an export. What can we do?

For personal data, the GDPR gives you an enforceable right; a formal notice is usually enough. For the rest, it depends on the signed contract, and that is the lesson to remember: your source documents, which you hold anyway, allow the essential to be rebuilt even without the vendor's cooperation.

How do we avoid reliving the same disappointment?

By reversing the order of the questions: architecture first (citations, the right model per task, connection to the real tools, an accountable operator - the five causes of the first failure, taken in reverse), the demo second, on your real documents. If you are preparing that second decision, let's talk.