Include a standard reversibility clause in all client contracts, with documented open formats, tested export scripts, and contractually guaranteed export deadlines#

What this is, concretely#

This commitment addresses one of the most poorly handled points in SaaS contracts: exit. Most contracts settle for a vague mention (“client data belongs to the client and may be exported on request”) without specifying format, scope, deadlines, or any associated cost. From the client’s standpoint, a clause without operational content guarantees nothing: at the moment of exit, the proprietary format, the loss of the relational model, the absence of scripts, or the unclear deadlines turn an exportability right into a captivity in fact.

The commitment consists of including in all client contracts a standard reversibility clause structured around three elements: (a) the explicit list of open formats in which data and flows will be exported (CSV or JSON for business data, ODF or OOXML for office documents, standard SQL dump for relational databases, schema manifest for non-trivial models); (b) the provision of export scripts tested under real conditions, ideally published in the product’s public documentation, with a sample archive; (c) a capped contractual export deadline, typically between 30 and 90 days depending on volume, with a commitment to deliver the artefact free of charge (or at a documented and capped cost). This commitment directly informs domain 5 of the Sovereignty Profile (continuity) and domain 6 (contractual relationship).

Why this commitment matters#

Thesis 13 of the manifesto grounds this commitment: “Technological sovereignty is not an end in itself. It is the condition under which an organisation — a business, an administration, an individual — can continue to operate its data and conduct its operations, whatever happens: provider failure, geopolitical conflict, sanctions, hostile takeover, unilateral flip by a publisher. It is a right, not a comfort.” The standard reversibility clause is, on the contractual side, the concrete instrument by which this right becomes enforceable: the client no longer depends on the publisher’s goodwill on the day they decide to leave.

This commitment forms part of the new section “Conditions of equivalence for the proprietary publisher” of the About page, which sets out the seven mechanisms by which a proprietary publisher can offer a guarantee of sovereignty equivalent to that of an open source publisher. The “standard reversibility” condition is the third of these. It directly complements pub-005-establish-software-escrow: escrow guarantees the continuity of the software; the reversibility clause guarantees the portability of the data and flows that live within it. Without both, the structural gap between an open source publisher and a proprietary publisher remains intact, because it is painless as long as nothing goes wrong, and unacceptable the moment something breaks.

This sheet treats reversibility from a SaaS angle — the publisher operates the service, the client entrusts their data, the issue is exporting that data into open formats. For PaaS providers — where the client has deployed code and configuration onto the provider’s platform — reversibility takes a complementary form centred on application workload portability (OCI packaging, deployment manifests portable to diverse targets including light self-hosted via Compose as a priority, detachable managed services, tested relocation contract). That declension is handled by pub-014-paas-application-portability. The two sheets are not exclusive: a provider that operates both SaaS and PaaS would do well to take both commitments.

A concrete example#

A French SaaS publisher of document management for the legal departments of mid-sized companies (ETIs), about 60 employees, takes this commitment in May 2026 with a 12-month horizon. The standard contract is updated in a new version in the third quarter of 2026. The clause specifies: export on request within a maximum of 60 days; scope covering all documents (original formats plus PDF/A version for archival), metadata in JSON conforming to a published versioned schema, audit log in CSV; a Python export script, published on the internal forge and accessible to clients under non-disclosure agreement, is tested each quarter on a representative dataset and its execution time is documented.

By the 12-month horizon, the clause appears in 100% of new contracts and in roughly 70% of renewed contracts. Two clients actually trigger the planned export (one to migrate to a competitor, the other to bring the service in-house); both operations proceed within the announced deadline and format, which is documented publicly as anonymised feedback. The sales team observes that mention of this detailed clause is now explicitly a positive in tender defences against competitors offering vaguer reversibility language.

Anti-pattern to avoid#

A reversibility clause reduced to “the client may request export of their data at any time” without specified format, without numerical deadline, without script, and without no-cost guarantee, gives no real assurance. A proprietary format alone (an export in a binary that only the publisher can read back) empties the clause of all force. An uncapped deadline lets the publisher decide unilaterally. A script never tested at real volumes becomes inoperable on the day it actually serves. Finally, charging for export as an ad hoc service (at an uncapped rate) creates a disguised exit barrier and contradicts the very spirit of the commitment.

Success indicators#

By the 12-month horizon, you can reasonably consider this commitment fulfilled if the clause appears in 100% of your new contracts and has been submitted for signature on renewals; if export formats are publicly documented; if at least one full export test has been conducted on a representative dataset and its deliverable made public in anonymised form; if the contractual deadline is met when actual export requests come in.

JSON schema category: publication. Default horizon: 12 months. Applicable to: businesses.