Data ownership and exit clauses in SaaS contracts.

A founder showed us his SaaS contract the week before signing. The product was good. The pricing was fair. The clause that did not exist in the contract was the one that mattered most. Three years from signing, when the firm had outgrown the product or simply wanted to move, the contract said nothing about what the firm would get out and in what form. The vendor's standard practice was a CSV export. The vendor's premium practice, on request, was an extended CSV export. There was no mention of the database, the schema, or transition assistance. The founder signed anyway.

Most SaaS contracts assume the relationship is forever. The assumption is convenient for the vendor and dangerous for the firm. The interesting fact about exit clauses is that they cost the vendor almost nothing to add at signing, and save the firm lakhs of rupees and months of attention at exit. The conversation that founders almost never have is the one to have.

The asymmetry of the standard SaaS contract

A standard SaaS contract is a one-way ratchet. The firm commits revenue. The vendor commits service availability. The firm's data moves into the vendor's infrastructure progressively, often silently, over years. The vendor's obligation to return that data, in any specific form, is usually unspecified beyond a generic line about data export availability.

This is not malicious. It is the default contract shape because nobody asks for anything different at signing. The vendor's sales team is incentivised to close the deal. The vendor's legal team drafts the standard agreement. The founder reviews the pricing and the SLA. The exit terms sit in the boilerplate and get signed off as acceptable.

Three years later, when the firm has decided to move, the boilerplate is what the firm has to work with. The boilerplate rarely contains what the firm needs.

Clause one: data export format specified in writing

The first clause to negotiate is the specific format of data export on exit. Not "data export will be made available". Not "customer will receive a copy of customer data". Specifically: a SQL dump of the database, with the schema documented, delivered in a named file format, within a named number of days of the request.

The reason this matters is that a CSV export and a SQL dump are operationally different artifacts. A CSV flattens the relational structure. The firm receives many spreadsheets that look like the data, but the relationships between them have to be reconstructed by hand. A SQL dump preserves the structure. The firm receives the data in a form a new system can ingest cleanly.

The cost to the vendor of providing a SQL dump is small. The vendor already runs the database. Extracting the dump is a routine operation. The vendor's resistance, when it appears, is rarely about cost. It is about preserving the friction that makes the firm stay. Naming the format in the contract removes the friction.

For Lucky Traders, the customer portal we built sits next to the firm's other operational data, all of which lives in the firm's own database. When the question of exit ever arises, the firm holds the data already. The question is structural rather than contractual, which is the position to be in.

Clause two: schema documentation as a deliverable

The second clause is a quieter one and is the one founders most often miss. A SQL dump without schema documentation is data without context. The new system's engineers have to reverse-engineer what each table represents, which fields are foreign keys, what the status codes mean, which fields are deprecated, which were renamed mid-product-cycle.

The schema documentation should be a contractual deliverable. A document that lists every table, every field, every relationship, every enumerated value. The vendor maintains this document internally already, because the vendor's engineers need it. Sharing it with the firm at exit costs the vendor nothing, and saves the new implementation team weeks of guesswork.

The pattern we saw at ES Haji before the custom industrial ERP was built, when the firm was running on mixed tools, was exactly this. Data existed across three vendors. None of the three had documented schemas. Migrating off any one of them would have required forensic work on the data shape before any new system could be loaded.

Clause three: transition assistance with a named duration and named price

The third clause is transition assistance. When the firm leaves the vendor's platform, what specifically does the vendor agree to provide. Help with the data export. Answers to the new system's implementation team's questions. A defined number of hours of engineer time at a defined hourly rate. A named duration of post-termination support.

The default contract assumes the relationship ends on the termination date. The reality is that the relationship has a tail. The new system's team will have questions for thirty to ninety days. The vendor's willingness to answer those questions, in a defined form, at a defined cost, determines whether the migration takes three months or eight.

A reasonable transition assistance clause specifies twenty to forty hours of engineer support over a sixty-day window, at the vendor's professional services rate, with a guaranteed response time. The clause costs the vendor nothing if the firm never invokes it, and costs the firm a known number if invoked. Compared to the alternative of unbounded migration uncertainty, the clause is cheap insurance.

Why these clauses are uncontroversial at signing and impossible later

At signing, the vendor's sales motion is to close. The vendor is willing to negotiate. The exit clauses do not affect the vendor's revenue today. The marginal effort to add them is low. Most vendors, when asked, will accept all three with minor wording changes.

At exit, the vendor's incentive is exactly the opposite. The firm has decided to leave. The vendor's commercial interest is to make leaving slow enough that the firm reconsiders, or expensive enough that the move is delayed. The clauses that were free to add at signing become impossible to add at exit, because the leverage has inverted.

This is why the founder's negotiation moment is one-shot. The day of signing is the only day on which all three clauses can be added at zero cost. Every subsequent day, the cost rises.

The deeper architectural answer

The contractual clauses above are useful. They are not, however, a substitute for the structural answer, which is to own the data substrate in the first place.

Decision infrastructure built inside the firm's own infrastructure has no exit clause because there is no exit. The codebase, the database, the deployment, the schema, the documentation, all live with the firm. The vendor relationship is a partnership, not a custody arrangement.

The longer treatment of when the build path becomes the better path is in our essay on the build-versus-buy math. For firms that have decided the SaaS path is still right for the current stage, the three clauses above are the protection that costs nothing to demand and saves a great deal to have.

The work we do under the enterprise practice is structured for firms past the point where the SaaS path serves. For firms not yet at that point, the right move is to sign the SaaS contract with the three clauses written in. The vendor will agree. The firm's future self will be grateful.

If you are within thirty days of signing a SaaS contract and want a second pair of eyes on the exit terms before you commit, the conversation is short and useful. Start a Conversation.