A cancellation clause can make a software contract look reassuringly flexible. It says when payment can stop. It says much less about how the business will continue working afterwards.
By the time a tool becomes useful, it may hold records, approval rules, integrations and knowledge about how work gets done. Those dependencies can outlast the subscription. The practical exit question is whether the organisation can recover enough of them to operate somewhere else.
That question belongs in the buying process. Once a service is essential, discovering that its exports omit attachments or that no one understands the integration becomes a much more awkward negotiation.
Understand the dependence you are accepting
UK government guidance on technical lock-in makes an important distinction between contractual restrictions and technical dependence. It also recognises that accepting some dependence can deliver benefits, including simpler services and less operational work. Avoiding every proprietary feature can impose costs of its own.
That is a better basis for discussion than insisting that all lock-in is bad. A managed service may be valuable precisely because the supplier takes on difficult work. Rebuilding those capabilities internally simply to preserve an abstract ability to leave could consume resources the business needs elsewhere.
The judgment is whether the benefit justifies the likely cost of changing direction. A commodity tool and a service central to fulfilling customer commitments may deserve different exit arrangements. Criticality, available alternatives and the organisation's capacity to manage a move should shape the decision.
For software buyers outside government, this is a commercial application of the guidance, not a claim that its public-sector rules apply to every purchase.
Ask for a rehearsal, not a promise
A small exit test can reveal the difference between exportable data and usable work. Create a permitted sample containing the kinds of records the business expects to retain: a completed request, an attachment, a comment, a status change and a relationship between records. Export it through the route the supplier offers.
Then inspect the result away from the original interface. Can another person identify each record, read the attachment and understand which items belong together? Are timestamps and status meanings clear? If the export contains codes, is the information needed to interpret them available?
This does not require a complete migration during procurement. It requires enough evidence to understand the boundary. A supplier may export the records while leaving workflow configuration or integration behaviour behind. That may be acceptable, but the buyer should know what would need to be rebuilt.
The test should include the receiving side. A file that opens successfully is not proof that the next system can import it or preserve its meaning. For important services, identify a credible destination or a temporary operating method and establish which transformations would be required.
Budget for the people and the transition
The cost of leaving includes more than downloading files. Staff may need to reconcile old and new records, learn a changed process and answer customer questions during the transition. Integrations must point to the right destination. Access and retention decisions need to be handled deliberately.
Procurement should establish who can perform the export, how long access remains available and what assistance is included. Charges, notice periods and deletion arrangements should be checked against the actual contract. A demonstration account cannot establish the rights attached to a later commercial agreement.
The organisation also needs its own record of how the service is used. If the only person who understands a critical integration leaves, supplier flexibility will not solve the knowledge gap. Keeping configuration notes and naming an internal owner are modest steps compared with rebuilding an undocumented process under pressure.
There is a limit to rehearsal. A small dataset will not establish the duration or reliability of moving the full production workload. The larger and more consequential the service becomes, the stronger the evidence required. Repeat the review when usage or dependencies change materially.
Buy the benefit with the dependency visible
A useful purchasing decision might deliberately accept a difficult exit because the service offers substantial value and the alternatives are worse. Another might choose a simpler tool because the organisation cannot support the dependency. Both can be reasonable.
What weakens the decision is treating the ability to cancel payment as proof of operational freedom. Before signing, ask for a small, interpretable export and an honest account of what it leaves behind. The answer will improve the purchase even if the business never leaves.
