Vendor lock-in in SaaS: reading the exit clause
Before signing up for a product your business will depend on, read how you would leave. The six questions and what acceptable answers look like.
The short answer
Every product your business will depend on should be judged, before signing, on how you would leave it. Not because you plan to, but because prices rise, products are acquired, features are removed and needs change, and the cost of leaving is what decides whether you have a choice when that happens. Six questions cover it: can you export everything, in what format, including attachments, history and configuration, how quickly, at what cost, and what happens to your data after you leave. Lock-in also hides outside the data, in integrations, automations and habits built around the product. Test the export before you depend on the product, and once a year after.
The six questions
| Question | Acceptable answer | Warning sign |
|---|---|---|
| Can we export everything? | All records, fields, relationships, attachments, history, comments, configuration | A spreadsheet of the main table |
| In what format? | Open, documented, structured; attachments in standard formats; a full API | Proprietary format; export only through support |
| How quickly? | Self-service, any time, within hours | On request, weeks, at the vendor’s discretion |
| At what cost? | Free or nominal | An export fee, or exit fees in the contract |
| What happens to our data afterwards? | Retained briefly for recovery, then deleted, in writing | Retained indefinitely; unclear |
| Can we test it now? | Yes, here is a sample export from a trial account | No |
Where lock-in hides beyond the data
- Integrations written against the product’s specific API, woven through your systems. An adapter layer keeps them replaceable.
- Automations built in the product’s own scripting or workflow tools, which do not travel. Prefer portable automation where a choice exists.
- Identity: the product as the login for other tools. Keep identity with a provider you control.
- Habits and training: the way the team works shaped by the product. Document the process, not the clicks.
- Historical reporting: years of data only analysable inside the product. Export regularly to your own storage.
- Contract terms: auto-renewal, long notice, price escalation without caps, exit fees. Read them before the trial ends.
Keeping the option real
Run the export once a year and check it: complete, readable, loadable. Keep a note of the two alternative products and what a switch would involve. Keep integrations behind adapters in your repository. Keep identity and documents with providers you control. And negotiate terms at signing, when you have bargaining power, rather than at renewal, when you do not: notice periods, price caps, export commitments in writing.
What this means for you
Judge every product you will depend on by how you would leave it: the six questions, a tested export, adapters around the integrations, terms negotiated at signing. Repeat the export test yearly. You may never leave, but the vendor who knows you can is the vendor who keeps earning your business rather than assuming it.
Frequently asked questions
The product says data export is available. Is that enough?
Only if the export is complete: every record, every field, attachments, history, comments, configuration, in a documented format you could load elsewhere. Many exports are a spreadsheet of the main table with no relationships, attachments or history. Ask for a sample export before signing, and try it.
What formats are acceptable?
Open, documented ones: structured files with relationships preserved, standard document formats for attachments, and ideally a full API from which everything can be read. A proprietary format that only the vendor can open is not an export; it is a backup you cannot use.
How do we reduce lock-in beyond the data?
Keep integrations in your own code with an adapter layer, so the product is one configuration among others. Avoid building deep automations inside the product's own scripting where a portable alternative exists. Document the processes that depend on it. And keep the option real by testing the export yearly and knowing the alternative products.