---
title: "The exit clause is the most important part of a support contract"
url: "https://kybertis.com/blog/the-exit-clause-matters-most"
description: "Nobody negotiates the exit while signing, which is exactly why it should be negotiated then. It is the only clause you have leverage over."
---

# The exit clause is the most important part of a support contract

August 6, 2026·2 min read·Editorial team

A heavy quick-release connector pulled apart into two halves lying a few centimetres apart

The exit clause is written when both sides are optimistic and read when at least one of them is not. It is also the only part of the contract you have real leverage over, because the moment you actually want to leave, your leverage is precisely zero. Everything else — price, scope, response times — can be renegotiated later. The exit cannot.

## What it has to contain

**What is handed over.** Configuration, infrastructure definitions, custom code, runbooks, credentials, data and its schema, and any documentation produced during the engagement. Listed specifically. “All relevant materials” means whatever the supplier decides is relevant on their worst day.

**In what format.** Configuration in version control rather than in a management console. Documentation as files rather than as pages in the supplier’s wiki. Data in a documented, open format. Formats are where good intentions quietly fail.

**Within how long.** A defined window from notice, with the handover itself scoped so it does not become a project nobody has budget for.

**At what cost.** Ideally zero, realistically a defined transition rate agreed in advance. What matters is that it is a number now, not a negotiation when you have already announced you are leaving.

**With what support during transition.** A defined period where the outgoing supplier still answers questions, because the gap between handover and competence is where outages live.

## The tell

Ask a prospective supplier to write the exit into the contract and watch what happens.

Reasonable answers: yes, and here is our standard clause. Yes, with a transition rate. Yes, but we need to define the boundary of custom work.

Unreasonable answers: that never happens with our customers. It is covered by the general terms. Let us deal with that if it comes up. We do not have a template for that.

The last set is not an administrative gap. It is a business model that depends on you not having the option, and you are learning about it at the only moment when learning about it is still useful.

## Why we write it in

Partly because it is right, and partly because of what it does to us.

A supplier that can be left has to keep earning the next month. There is no accumulated switching cost to coast on, no configuration nobody else can read, no undocumented decision that makes the relationship sticky by accident. The only retention mechanism available is doing the work well.

That is a healthier position for both sides. It removes the temptation to make ourselves necessary, which is a temptation every services company faces and most eventually give in to without ever deciding to.

## The version that applies to open source

On open-source software the exit is technically always available: the code is public, you can run it yourself. That is the argument, and on its own it is not enough.

Practically, leaving requires the configuration, the operational knowledge and the changes made along the way. If those live only in the supplier’s systems and heads, the open licence is theoretical. The exit clause is what turns it into something you could actually exercise on a Tuesday.

Which is why, on an open stack, the exit clause is not a defensive detail. It is the thing that makes the openness real.

-   exit
-   procurement
-   lock-in
-   negotiation

## Keep reading

-   [Hardening is a service, not a checkbox](https://kybertis.com/blog/hardening-is-a-service)
-   [Rolling out KyberDeck to a team: devices, identities, spares](https://kybertis.com/blog/rolling-out-kyberdeck-to-a-team)