Analysis

The exit clause you will wish you had written

An outsourcing contract is judged at the moment you want out of it. Rarely before.

A developer works at three screens showing code and an admin console
Getting your data back assumes you planned for it

You choose an outsourcing contract on price and scope. You judge it, three or five years later, on one criterion: how hard it is to leave.

By then the relationship has usually soured, and you negotiate from weakness — the supplier holds the credentials, the knowledge of the system, and sometimes the code.

What an exit clause covers

  • the timescale for handover, from the date of request
  • the format of returned data, usable without the supplier’s own tools
  • the operating documentation, kept current
  • the support given to the incoming supplier, expressed in days
  • the cost, fixed at signature and not on departure
  • ownership of any bespoke development

What usually blocks matters is not ill will: it is the absence of an agreed price. Handover work with no figure attached will be billed at whatever rate the supplier decides on the day you leave.

What is not written down will not be handed back. Or it will, at the price set on the day you no longer have a choice.

Service levels do not measure what you think

Availability stated at 99.5% allows around three and a half hours of downtime a month. At 99.9% that falls to forty minutes. The gap between the two figures looks slight; in practice it separates an inconvenience from a stoppage.

More to the point, availability says nothing about the rest. Three distinct commitments need setting out separately:

  • the response time — how long before someone picks it up
  • the resolution time — how long before it works again
  • the penalties, and their cap, which shows how serious the commitment is

The decision framework is set in calm weather

In an incident, the question that paralyses is almost never technical. It is: who decides. Assigning roles in advance — who does the work, who is accountable, who is consulted, who is informed — avoids the half-day lost hunting for someone while the system is down.

Renegotiate rather than terminate

Reversibility is never read on its own: it is negotiated with the rest of the contract, and in particular with what you believe you signed on maintenance.

A one-sided contract does not necessarily need terminating, which is expensive and loses the history. A variation lets you put back what is missing — exit terms, quantified commitments, a decision framework — without calling the relationship into question. It is often the quickest route, provided you know exactly what you are asking for.

Common questions

What is reversibility in a managed-services contract?

It is the set of conditions that let you take your system back at the end of the contract: handover timescale, format of returned data, up-to-date documentation, support for the incoming provider, ownership of custom developments, and cost. It is negotiated at signature, not on departure.

How do you terminate a managed-services contract without losing control of your system?

By having written the exit before you need it. Without a priced reversibility clause, the provider holds the access, the knowledge of the system and sets the price of the handover. If the contract lacks one, an amendment can often reintroduce it without ending the relationship.

What should you check in a managed-services contract’s service commitments?

Three separate commitments: response time, restoration time, and penalties with their cap. An availability rate alone is not enough: a response time does not guarantee the system works again, and a commitment without a penalty commits nothing.


Next article

IT outsourcing does not transfer responsibility

Read

A transformation to support?