Exit Plan

An exit plan is a documented description of how an organisation would stop using a supplier: what data comes back, in what format, over what period, who does the work, what replaces the service, and what it would cost. It is written not because departure is expected but because the ability to leave is what keeps a commercial relationship honest, and that ability decays quietly if nobody ever checks it. The right moment to write it is before signing, when the vendor is still competing for the business. Export formats, transition assistance, data retention after termination, and the right to terminate for convenience are all negotiable at that point and rarely negotiable later. A supplier who will not discuss the exit before the contract starts is providing useful information about what the exit will be like. A serviceable plan covers four things. What is yours — records, documents, configurations, evaluation sets, prompt libraries, models trained on your data — and whether the contract says so plainly. How you get it — a documented export, an API, a one-off extract, and crucially in a structure that can be loaded somewhere else rather than a proprietary archive or a stack of report files. How long you have after termination before it is deleted. And what work sits on your side: integrations to rebuild, workflows to re-implement, users to retrain. The costs are usually underestimated because the licence fee is the visible part. The real weight is the engineering time to rewire integrations, the parallel running period when both systems are paid for, the retraining, and the historical data that either migrates or becomes an archive nobody can query. Estimating these once, roughly, is enough to make the trade-off real — and often enough to change what you negotiate at renewal. For AI systems there are components that generic exit plans miss. Fine-tuned models and their weights, if the contract permits their extraction at all. The evaluation set and its labels, which represent months of accumulated judgement about what good output looks like. Prompt and configuration history. Embeddings, which usually have to be regenerated rather than moved because they are tied to a model. And any data the vendor derived from yours, which is often governed by a different clause than the data you supplied. Finally, a plan nobody has tested is a belief. The cheap version of testing it is to perform the export annually, load the result somewhere neutral and confirm it is complete and usable. That single habit finds broken exports, missing fields and undocumented limits at a moment when they are an inconvenience rather than an emergency.