Articles · Handover

2026-10-16 11 min EN / FR

The exit plan every client should require from a tech provider

Contracts describe what a provider will deliver. They rarely describe what happens when the relationship ends. That is when you need the details most.

An exit plan is a short document, written at the start of a project and updated along the way, that answers one question: if we part ways, how do I keep running?

It is not a sign of distrust. Good providers like it, because it protects them too. It makes the relationship easier to end on good terms, which makes it easier to keep.

Why it matters

Without an exit plan, these situations are common:

  • A developer becomes unavailable, and nobody else knows how the system is deployed
  • An agency closes, and the code, licenses and hosting are under its name
  • A dispute starts, and access is used as leverage
  • A new provider needs weeks just to understand what exists

An exit plan turns these into a manageable handover instead of a crisis.

What it contains

1. System inventory

A simple list of everything that makes up the solution:

  • Applications and their purpose
  • Servers, hosting and cloud resources
  • Domains and DNS
  • Databases
  • Third-party services and APIs
  • Scheduled jobs and automations

2. Ownership table

For each item: owner, billing party, admin accounts, recovery contacts. The same four columns as in the 30-minute account audit.

3. Access and secrets

  • Where credentials are stored (your password manager or vault)
  • Which accounts the provider uses, with what role
  • How to revoke provider access, and in how much time
  • Confirmation that the provider holds no secrets you cannot rotate

4. Source code and build

  • Location of the repositories (under your organization)
  • How to build and deploy from scratch
  • Environment variables and configuration, documented
  • Licensing of any third-party or provider-owned components

5. Data and backups

  • What is backed up, how often, and where
  • Who can restore, and how (with a tested procedure). See backups that actually restore
  • How to export your data in a usable format
  • Retention rules, including legal ones

6. Operations

  • Monitoring and alert contacts
  • Routine maintenance tasks (updates, certificate renewals, backup checks)
  • Known weak points and open issues

7. Handover procedure

  • Notice period and what the provider does during it
  • Hours of support for knowledge transfer
  • How and when access is removed
  • Who validates that the handover is complete

8. Costs and responsibilities

  • What the handover costs (included, or at a stated rate)
  • Which third-party contracts transfer and which end

A simple template

You can copy this structure into any document:

EXIT PLAN: [Project name]
Version / date:
Client contact:
Provider contact:

  1. Inventory (system, purpose, location)
  2. Ownership (account, owner, payer, admin, recovery)
  3. Access (who has what, how to revoke)
  4. Code and deployment (repos, build steps, config)
  5. Data and backups (what, where, frequency, last restore test)
  6. Operations (monitoring, recurring tasks)
  7. Handover (notice, support hours, access removal, validation)
  8. Costs

Last reviewed:

Clauses worth putting in the contract

You should have a lawyer review the wording, but these are the ideas to ask for:

  • Accounts in the client's name from the start
  • Client ownership of code, data and documentation upon payment (or as agreed)
  • Delivery of source code and deployment documentation, not only the running system
  • A defined handover period with a stated number of support hours
  • No withholding of access during a disagreement over invoices (the dispute goes through the normal channels)
  • Transfer of third-party licences where permitted, or a clear list of those that cannot be transferred

Test it, do not just write it

An exit plan that has never been tested is a hope. Once a year:

  • Ask someone not involved in the project (an internal employee or an outside technician) to read it.
  • Have them try to restore from a backup in a test environment.
  • Check that the access list still matches reality.
  • Update the document and note the date.

It is an hour or two of work, and the first time you do it you will almost always find a gap.

Starting a new project?

We can help you draft an exit plan alongside delivery, or review one a provider gave you before you sign.

Ask us Custom solutions

When to ask for one

  • Before signing a new project: add it to the deliverables.
  • At a milestone of an existing project: ask for a first version.
  • When something changes: new provider, new hosting, a key person leaving.

A provider who refuses to discuss it entirely is giving you useful information.

Related

From template to a signed deliverable

If you want a second look before the next contract, write us. We answer on substance.

Start a conversation All articles