You have to be able to leave.

The renewal contract lies open at Section 14.3. The clause is a single paragraph: either party may end the agreement on ninety days' written notice, and the provider will make the customer's data available for export, in a commonly used machine-readable format, for thirty days afterward. Beside the contract sits a printed export manifest, a list of files with their row counts and sizes, produced in a test run the week before. Both documents are invented for this essay. Together they look like an exit. The clause grants the right to leave, and the manifest shows the data can come out. What neither shows is how the service those files came from would be rebuilt somewhere else, by whom, and in how long.

The clause is a real protection, and negotiating it well matters. But consider what it leaves out. It says nothing about the structure of the data: which fields mean what, how records relate to one another, which values are codes whose meaning lives in the provider's configuration. It says nothing about the workflow rules, the approval routes, the integrations with other systems or the reports people rely on every Monday. It says nothing about whether anyone on staff knows how to run the destination, or whether there is a destination at all. An organization with the right to leave and none of these things is in the position of someone who has every right to drive to another city and no car.

My argument is that leaders should judge a critical supplier relationship partly by whether the organization could carry out a workable exit. The contractual right to leave is necessary, and cheap to write down. The practical ability to leave is what turns that right into a choice, and it depends on usable data, compatible processes, skills, time and somewhere to go. This is not an argument for running every service on two platforms, or for treating every switching cost as a trap. Specialized services can be worth what it costs to leave them. The obligation is narrower: for the dependencies that matter, know what an exit would take, put a price on it, and keep a proportionate alternative alive. Sometimes the result of that work will be a well-founded decision to stay. This is the lifecycle view of the first essay in this series, Technology is not a toaster, applied to one recurring moment: the renewal.

What the evidence says about leaving

The difficulty is not hypothetical. On July 31, 2025, the UK Competition and Markets Authority published the final decision of its market investigation into cloud services, the rented computing on which much of modern software runs. It found that very few customers switch: fewer than 1 percent of cloud customers change provider each year. Customers face both commercial and technical barriers to switching or to using several providers, and many, the authority reported, currently think the costs outweigh the benefits.¹

The barriers it described are instructive because they come in two kinds. The commercial one is money: egress fees, the charges for moving data out of one provider to another, which the authority found weigh most on smaller customers and on those storing large amounts of data. The technical ones are differences in features and interfaces that make services hard to compare, substitute or combine, along with latency between clouds, a lack of transferable skills among customers' staff, and too little transparency from providers about how to overcome these obstacles. The authority concluded that such barriers lock customers into their initial choice of provider.¹

Those findings concern one market in one country, and any particular customer's situation may be easier or harder. But the categories travel well. A contract can cap or waive a fee. It cannot make two systems' features line up, teach a team a new platform, or shorten the distance between a set of files and a working service.

Follow one workload out

Take one representative workload, say the system that handles customer service cases, and follow it out of the door, step by step.

Notice. Ninety days begin. From now on the clock runs against every task that follows, including the ones that cannot start until others finish. Export. The data arrives as files. The first useful check is not whether the files exist but whether they reconcile: whether the counts of cases, customers and attachments in the export match the live system, and whether the relationships among them survived the trip. An export that cannot be reconciled is a liability rather than an asset. Interpretation. Someone has to learn what the data means. Status codes, custom fields, records deleted but retained, timestamps in an unexplained time zone: all of them carry meaning that lived in the old system's configuration and in its users' habits. This is slow work, and it is where people who know the old system become indispensable.

Migration. The data is loaded into the destination, and the parts of the service that were never data are rebuilt: workflow rules, routing, notifications, the integrations with billing and the phone system, the reports. In many services this is most of the work. Verification. Before anyone relies on the new system, a representative workflow runs end to end: a case is opened, routed, escalated, resolved and reported, and the results are checked against what the old system would have produced. Cutover. Users move, integrations switch, and the old service is retired. Possession of the bytes covers the second of these six steps. Operational continuity requires all of them.

Figure 2 lays those steps out as a schedule. Its durations are invented, but its shape is common. The tasks depend on one another, several cannot start until the data has been understood, and together they take longer than the notice period. In the example, the contract ends at about week thirteen and the new service is verified at week sixteen, leaving weeks in which the organization has neither. That is not a reason to give up on leaving. It is a reason to do part of the work before notice is ever given, and to know in advance roughly how long the rest would take.

Price the dependency

None of this makes switching costs bad in themselves. A specialized service is often valuable precisely because it does things a generic alternative does not, and the features that make it hard to leave are frequently the features it was bought for. The same investigation recorded that customers say cloud providers offer them quality and innovation.¹ Accepting some dependence in exchange for that can be a sound decision.

What turns dependence into a problem is not knowing its size. At a renewal, the supplier usually has a fair idea of how hard it would be for the customer to leave; the customer often does not. That asymmetry shows up in the negotiation. A customer that can say, credibly, what an exit would cost and how long it would take is negotiating with an alternative in hand, even if it never intends to use it. One that cannot is negotiating with a clause.

The obligation for leaders has three parts. Know which dependencies are critical, in the sense that the business could not operate for long without them. Price each one: the estimated cost and duration of a transition, and the capabilities that would be given up. And preserve a proportionate alternative: not a second running copy of everything, but enough preparation that the estimate rests on evidence rather than hope.

Rehearse, then decide

The cheapest evidence is a rehearsal. Take the representative workload, request a full export and reconcile it against the live system. Load a slice of it into a plausible destination and make one real workflow run from start to finish. Record how long each step took, what was missing and who had to be involved. A rehearsal like this is not a migration. It is a measurement, and its result is an input to the renewal decision.

Often the measurement will support staying. A team that finds an exit would take most of a year and cost capabilities it values may decide, sensibly, that the current supplier is the right one. It can then negotiate from knowledge rather than fear: on price, on export formats and documentation, on a longer export window, on help with a transition should one ever be needed. The rehearsal has done its job. A decision to stay that has been tested is a different thing from a decision to stay that was never questioned.

Objections, considered

Portability work consumes resources. It does, and there is no point pretending otherwise. Every hour spent rehearsing an exit is an hour not spent improving the service. The answer is to be selective: prepare exits only for critical dependencies, give the work an explicit budget, and size it to the stakes. A rehearsal for the system that runs customer service may well be worth it; one for a minor departmental tool almost certainly is not.

Running two platforms creates complexity. It can, and running every service on two platforms is often a poor trade: twice the operating knowledge, twice the security surface, and a design reduced to what both platforms share. That is not what this essay recommends. A reconciled export, a documented mapping of the data and a workflow that has run once in a destination are not dual operation. They are evidence that an alternative could be built if it were needed.

Generic interfaces sacrifice useful capabilities. True. Restricting a service to the features every competitor offers can throw away the reasons for choosing it. Portability should be weighed against capability case by case, and sometimes capability should win. The point is to make that trade knowingly, with a price attached, rather than to discover its terms at the next renewal.

The right to leave is written in a clause; the ability to leave is built, and it has to be tested.

Before the next significant renewal

• Name the destination. Where the service would go, even if no one intends to move it.
• Name the owner. The person responsible for knowing what an exit would take, and for keeping that knowledge current.
• Estimate the cost and the duration. Of a transition, including the work that is not data: workflows, integrations, training and verification.
• Date the last test. When a representative export was last reconciled, or a representative workflow last ran in the destination, and what it found.

Back to Section 14.3 and the manifest beside it. Keep both. The clause is a right worth having, and the manifest shows that the data can leave. What belongs on the table next to them is a third sheet: a schedule with its dependencies and durations, an acceptance test, and the date on which someone last made a representative workflow run on the other side. With that sheet, the renewal is a choice. Without it, the clause is the only thing on the table that says the organization can leave, and a clause cannot run a service.