The Claim That You Can Always Switch

The sentence appears in almost every conversation about adopting an AI tool, usually as the thing that ends the conversation: it's fine, we can always switch. It is said with relief, and it is said sincerely.

It is also the single most load-bearing assumption in how small companies buy software, and it is mostly wrong. Not wrong because vendors trap you, though some do. Wrong because reversibility is being measured in the one currency that is easy to see, and the thing that actually holds you in place is not denominated in it.

What the claim is really asserting

Unpacked, the claim has three parts. That the data can come out. That the contract can be ended. And that, once both are true, the team can go back to how it worked before or on to something else.

The first two are often genuinely true, and they are the two that get checked. Export exists. The plan is monthly. Somebody confirms both and the decision is declared low-risk.

The third part is never checked, because it is not a property of the software. It is a property of the people, and nobody thinks to audit it before signing up for a trial.

The lock-in is in the habits, and it forms fast

A tool changes what a team considers normal, and it does so in weeks. The change is not dramatic. It is a drift in expectations.

Meetings stop producing written notes because something else produces them. The weekly summary stops being written by the person who understood the week. A draft arrives before anyone has decided what it should argue.

None of that is a complaint about quality. The artefacts may be better. The point is that a capability which used to live in a person now lives in a subscription, and the person has stopped practising.

Switch the tool and the data moves in an afternoon. The practice does not come back in an afternoon. That is the real cost, and it never appears in the comparison because it is not a feature of either product.

Reversible for whom?

The person who says we can always switch is almost always the person who chose the tool, and almost never the person who would do the switching.

This matters because the two have different information. The chooser knows the export exists. The switcher is the one who discovers, months later, what the export leaves behind: the shared conventions, the half-configured automations nobody documented, the link a client has bookmarked, the shortcut three people built their week around.

So the claim is usually made in good faith by somebody who will not pay for it being wrong. That is not dishonesty. It is just a forecast made from the wrong seat.

Why AI tools are worse at this than ordinary software

Ordinary software holds your records. You can enumerate records, export them, and count whether they all arrived. The migration has a finish line and you can tell when you crossed it.

An AI tool holds something harder to inventory: the accumulated sense of how to ask it things. The prompts that work, the formats it reliably produces, the tasks the team has quietly learned to hand it and the ones it has learned to keep. That knowledge is real, valuable and entirely undocumented, and it does not export.

It is also not transferable, because the next tool answers differently. You do not migrate it. You rebuild it, slowly, while the work continues, which is why the second adoption is often harder than the first despite everyone being more experienced.

There is a further asymmetry. A records system behaves the same next month. A model is updated beneath you, without a migration or a decision on your part. So the tool you can supposedly always switch away from is also a tool that can change while you stand still, which means stability is not the alternative to switching. It was never on offer.

The honest version of the claim

There is a true statement near the false one, and it is worth keeping, because the false one is doing useful work in a real conversation: it stops teams agonising over reversible decisions.

The honest version is narrower. You can always stop paying. Whether you can always go back is a separate question, and it depends on what the tool was allowed to replace rather than on what it stored.

Which turns the adoption question into a better one. Not can we leave, but what will have stopped happening by the time we want to.

• What skill stops being practised while this tool is doing it, and who was the person practising it?
• What would we be unable to produce in the week after it disappeared, and is that acceptable for a week?
• Who else has built on it — clients, collaborators, a published link — who would not be consulted about leaving?
• What are we no longer writing down, because the tool appeared to be writing it down for us?
• Is there one task we are deliberately keeping manual, as the thing that keeps the capability alive?

The strongest objection to all this

The best counterargument is that this essay is nostalgic, and it deserves a straight answer.

Nobody mourns the capability to do long division by hand, or to navigate a city from memory. Those were skills, they were genuinely lost, and the loss was worth it. Capability transfer to tools is the ordinary mechanism of every productivity gain in history, and treating it as a hazard is how people end up defending typewriters.

That objection is correct about the general case and silent about the specific one. The arithmetic you handed to a calculator was never going to be needed again, because the calculator is not going to change its mind about multiplication, raise its price, or be withdrawn.

The capability being handed over here is judgement about your own work, to a product that is commercially alive and subject to revision by someone else. That is not the same bargain. It can still be a good one. It simply is not the free one that the calculator analogy implies, and the difference is the whole subject of this essay.

What follows in practice

The useful conclusion is not to adopt more slowly. Slowness has its own costs and small teams rarely have the luxury.

It is to be deliberate about what you let a tool absorb. Adopting something to do work faster is a different decision from adopting something to do work nobody on the team can still do. The first is reversible in the way people mean. The second is a transfer of capability, and it should be made on purpose, out loud, with somebody noticing.

This is the same distinction argued at greater length in the tool is not the workflow: the software is the easy part to change, and the arrangement of work around it is the part that actually persists. A related question, about what the tool retains of what you typed, is taken up in who reads what you type.

Bottom line

We can always switch is true about the contract, roughly true about the data, and false about the team. The exit that gets checked is the one that was never the obstacle.

So keep saying it when the stake really is a subscription and an export. Stop saying it when the thing being handed over is a capability somebody used to have, because that is the case where leaving is not a migration but a relearning, and nobody has scheduled time for that.

The test is not whether you could get your data out tomorrow. It is whether you would still know how to do the work. This essay argues from how small teams are observed to adopt software rather than from any vendor's documentation, and it quotes no figures; our standing rules on sourcing and corrections are on the editorial policy page.