Exit and Handover Clauses: What to Demand Before You Sign

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A CIO or VP of Technology at a UK enterprise mid-way through an outsourced build who has just been asked by legal what happens if they need to terminate — and realises the contract says almost nothing useful about it

If the contract in front of you treats termination as a payment-settlement question — final invoices, notice periods, maybe a kill fee — it is not protecting you. The real exposure sits in the 30 to 90 days after you give notice, when the vendor still controls every production credential, pipeline secret, cloud account, and undocumented deployment script, and has almost no contractual reason to transfer any of it in a usable state. A good exit and handover clause fixes that imbalance by making the transition-out a defined, paid, acceptance-tested deliverable in its own right — not a goodwill exercise.

This post walks through what to put in the termination and transition-out clause of a UK enterprise development contract, which standard wording quietly fails to protect you, and the questions to put to the vendor before signing. It is written for the person who has to sign it, not the lawyer who has to draft it. None of this is legal advice. Your in-house counsel or external solicitor needs to review the final wording against your specific procurement, your regulator, and your risk appetite.

Why this clause matters more than the SOW

The UK IT outsourcing market was valued at £19.6 billion in 2024 and is projected to reach £41.6 billion by 2033. The failure rate inside that spend is not a rounding error: Gartner data compiled in 2024 puts the share of IT outsourcing engagements that fail within 24 months at 21%, a rate that has held steady for a decade. The same research pins the primary causes on quality (43%) and communication breakdown (31%) — not payment disputes. In other words, you are statistically more likely to need the exit clause than to need the warranty clause, and you are more likely to need it because something went wrong operationally than because of a billing fight.

The scale of getting it wrong is not theoretical either. BSkyB's dispute with EDS (later HP) over a CRM programme ended with a reported £318 million in damages. That is the extreme end, but 24% of IT outsourcing clients report vendor lock-in on proprietary platforms as an experienced challenge, and 21% cite loss of institutional knowledge — both of which sit squarely in the transition-out window.

If you are a UK-regulated firm, this is not optional. The PRA's Supervisory Statement SS2/21 explicitly requires regulated firms to document exit plans for material outsourcing arrangements covering both stressed and non-stressed scenarios, including estimated cost, resourcing, timing, and data recovery priorities. The Critical Third Parties regime (PS16/24, effective 1 January 2025) extends similar expectations beyond just regulated firms' own contracts. Your exit clause is now a regulatory artefact, not just a commercial one.

What the exit and handover clause is actually for

Strip it to first principles. The clause has to answer, in writing and without ambiguity, five questions:

1. What triggers it? Termination for cause, for convenience, insolvency, change of control, repeated SLA breach, or you simply reaching the end of the term.
2. What gets handed over? Not just "the code" — the full operational estate.
3. In what state? Buildable, deployable, documented to a defined standard, with no undisclosed dependencies.
4. Over what period, and who pays? A defined transition-out window with named deliverables and a pre-agreed day rate or fixed fee.
5. How do you prove it is done? Acceptance criteria for the handover itself, with payment held back until they are met.

Most contracts answer question one in detail and the other four in a sentence each. That is where the exposure is.

Trigger events: what to insist on

What the clause is for

To make clear, without needing a court to decide, when you can walk away and on what terms.

Wording that protects the buyer

Termination rights for: (a) material breach not cured within a defined period, typically 30 days; (b) repeated minor breach — a defined number of SLA failures in a rolling window; (c) convenience, with notice (usually 60-90 days) and a transparent compensation formula that covers work-in-progress but not future margin; (d) insolvency or change of control of the vendor; (e) persistent key-personnel turnover beyond a stated threshold.

Crucially: termination for cause should not be conditional on the vendor's agreement that cause exists. The clause should say the exit obligations apply irrespective of the reason for termination or which party terminates. Otherwise a disputed termination becomes a disputed handover, and you sit without your code while the lawyers argue.

Wording that quietly does not

"Either party may terminate for material breach" without defining material breach or a cure period. "Termination for convenience subject to payment of all outstanding fees and reasonable wind-down costs" — "reasonable" is the word that funds the dispute. Any clause that makes handover obligations conditional on payment of disputed invoices. That gives the vendor a lien on your code.

Question to put to the vendor

"If we terminate for cause and you dispute that cause, do your transition-out obligations still kick in on day one of the notice period, or do they wait for the dispute to be resolved?" The honest answer should be: obligations start immediately, dispute runs in parallel.

The handover inventory: what gets transferred

What the clause is for

To define the full operational estate, not just the IP. The gap between "we gave you the source code" and "you can actually run this system" is where 90-day handovers become 9-month rebuilds.

Wording that protects the buyer

Schedule a named handover inventory. Minimum items:

• Source code for every component, including internal libraries, build scripts, infrastructure-as-code, migration scripts, and seed data generators — in a Git repository you own, with full commit history
• Container images and build artefacts with the Dockerfiles, base image references, and build arguments needed to reproduce them
• CI/CD pipeline definitions and the secrets inventory (not the secret values — a list of what secrets exist, where, and what they are for)
• Cloud account ownership — AWS, Azure, GCP accounts, DNS, CDN, monitoring, logging, APM, and any SaaS tool bought on your behalf, transferred to accounts you control or a documented path to doing so
• Credentials and access for every production and non-production environment, third-party API, payment processor, and data store, rotated at handover
• Model weights, training data, prompt templates, fine-tuning datasets, and evaluation harnesses — critical for AI builds and often absent from older contract templates
• Architecture documentation at a defined standard: system context diagram, component diagram, data flow, deployment topology, runbooks for the top-N operational incidents
• Known defects list and technical debt register, dated and current
• Third-party licence register — what OSS is in the stack, what commercial licences the vendor bought in your name, what licences the vendor bought in their name that the system depends on
• Data — a full export of production and non-production data in a defined format, plus confirmation of deletion from vendor systems after handover

Wording that quietly does not

"The Supplier shall deliver all materials reasonably required for the ongoing operation of the Software." That is a dispute waiting to happen. So is any clause that defines the IP assignment but is silent on the operational artefacts around it — you can own the code and still not be able to run it.

Watch especially for proprietary vendor platforms baked into the build. If the vendor's "accelerator framework" or in-house low-code layer is part of the system, your handover needs either a perpetual, transferable licence to that framework or a path to replace it. 24% of outsourcing clients cite lock-in on proprietary platforms as an experienced challenge for a reason.

Question to put to the vendor

"Walk me through what a new engineering team would need, in week one, to deploy a change to production without any of your staff available. What on that list is not in the handover inventory?"

Condition of handover: documented, buildable, deployable

What the clause is for

To stop the vendor from meeting the letter of the handover inventory while delivering something unusable — a repo that won't build, infrastructure code that references secrets nobody has, runbooks that reference a Slack channel that no longer exists.

Wording that protects the buyer

Define acceptance criteria for the handover itself. Something like: on receipt of the handover package, a nominated successor team (yours, or an independent third party) will attempt to (a) build the system from source on clean hardware, (b) deploy it to a new environment using only the supplied scripts and documentation, (c) execute a defined smoke-test suite, (d) resolve a defined test defect end-to-end. The vendor's final retention payment — typically 10-20% of total fees or a dedicated handover fee — is released on sign-off.

Specify documentation to a standard. "To a standard sufficient for a competent engineer unfamiliar with the system to operate and maintain it" is defensible wording. Better still, reference internal templates or a public standard your team uses.

Wording that quietly does not

"The Supplier shall provide reasonable documentation." "Knowledge transfer sessions as mutually agreed." Any obligation that is purely input-defined (number of sessions, number of pages) rather than outcome-defined (successor team can deploy, operate, and change the system).

Question to put to the vendor

"Would you accept a clause that holds back 15% of total contract value against a successor team successfully deploying the system from your handover package within 30 days of termination?" The answer tells you how confident they really are in their own documentation.

The transition-out period: paid, scoped, and governed

What the clause is for

To buy you a defined window of continued vendor cooperation, at a pre-agreed rate, with named deliverables, so that neither side is negotiating the terms of the handover while the handover is happening.

Wording that protects the buyer

A transition-out services schedule, triggered by any termination notice. It should specify:

• Duration — typically 30-90 days, extendable at your option by a defined further period at the same rate
• Named roles that must be made available (tech lead, DevOps lead, product owner), with minimum allocation (e.g. 50% FTE each)
• Pre-agreed day rate or fixed transition fee, so you are not price-negotiating under duress
• Deliverable milestones — handover inventory delivered by day X, knowledge transfer sessions complete by day Y, successor team deployment test by day Z
• Continued SLA on the live system throughout the transition, at the same levels as the main contract
• Non-solicitation carve-out — if your organisation wants to hire specific vendor engineers who worked on the build, the clause should permit it, or at least define the buyout cost

Wording that quietly does not

"The Supplier shall provide reasonable transition assistance for a period of up to 60 days at its then-current time and materials rates." You have handed the vendor a blank cheque and a motive to pad the hours. Also beware of transition-out services being optional at the vendor's discretion in a termination-for-cause scenario — some templates genuinely do this.

Question to put to the vendor

"What is your fixed fee for a 60-day transition-out with the deliverables listed in Schedule X, quoted now as part of this contract?"

Source-code escrow: when it helps, when it is theatre

Escrow is useful for one specific scenario: the vendor becomes insolvent or disappears, and you need an independent party to release the code and build artefacts to you. UK providers like NCC Group offer this as a standard service.

What escrow does not help with: a vendor who is still trading but uncooperative, a vendor who deposits stale code every quarter, or a vendor whose escrow package is missing half the operational estate described above. If you use escrow, insist on (a) monthly deposits, not quarterly, (b) deposit verification — the escrow agent actually attempts to build the code from the deposit — and (c) a deposit scope that mirrors the handover inventory, not just source code.

Escrow is a complement to a strong exit clause, not a substitute. For most live, actively-maintained enterprise builds, a well-drafted transition-out clause does more useful work than escrow does.

Governance that makes the clause enforceable

A clause only works if someone is checking, during the life of the contract, that handover would actually be possible. The research is blunt: fewer than 30% of enterprises have formal sourcing strategies and governance in place, and poorly-managed governance puts at least 15% of total contract value at risk.

Three practical governance habits, written into the contract or the operating manual:

• Quarterly handover readiness review. The vendor demonstrates that the current state of the system is handover-ready — repo, docs, runbooks, credentials inventory. Not a drill of the full handover, but evidence that it could happen.
• Your names on the cloud accounts, from day one. The vendor can have admin access; you own the root account. This single decision removes most of the credential-transfer risk at exit.
• A shadow engineer or technical product owner from your side embedded in the build, even part-time. The 21% of clients citing loss of institutional knowledge at vendor exit are overwhelmingly the ones who had no internal counterpart during the build.

If you have already signed and the clause is weak

You have more options than you think, in roughly this order:

1. Side letter. Propose a short handover addendum covering inventory, transition-out scope, and acceptance criteria. Frame it as a governance improvement rather than a renegotiation. Most vendors will sign one, especially mid-engagement when the relationship is still healthy.
2. Change request as leverage. The next scope change is a natural moment to attach handover-readiness commitments.
3. Operational hardening on your side. Transfer cloud account ownership to you now, take a copy of the repo, document what you can, embed an internal engineer. None of this requires vendor agreement.
4. If regulated, invoke SS2/21. "We are required to document an exit plan covering stressed and non-stressed scenarios. We need your cooperation to produce it." This is a cooperation request, not a renegotiation, and it is hard for a vendor to refuse.

How CodeNicely can help

We build custom software and AI products for enterprises and scaleups, and we have been on both sides of the transition-out conversation — picking up systems from previous vendors, and handing systems back to in-house teams at the end of an engagement. Our contracts default to full IP ownership for the client, no proprietary framework lock-in, and defined handover deliverables.

If you are mid-engagement with another vendor and worried about what exit would actually look like, the most relevant case study is GimBooks — a YC-backed fintech where we worked alongside the client's internal team from the start, with cloud ownership, repo ownership, and documentation standards defined upfront. The engagement is a useful reference for what a handover-ready operating model looks like in practice, including the governance habits above. For regulated-sector builds that need to meet SS2/21-style exit documentation, we can help scope the inventory and transition-out plan as a standalone piece of work before any build commitment is made.

The three questions that turn a clause into protection

Before you sign — or before your next governance meeting if you have already signed — ask the vendor three questions and get the answers in writing:

1. If we terminate tomorrow, for any reason, what exactly will arrive in our hands within 60 days, and what is the fixed fee for delivering it?
2. What is in your build that we cannot replace without your continued involvement — proprietary frameworks, accounts in your name, undocumented dependencies — and how do we remove each of those from the critical path?
3. Would you accept 15% of contract value held in retention against a successor team successfully running the system from your handover package?

The vendors who answer these cleanly are the ones you want to work with. The ones who flinch are telling you something important about what the exit would actually look like.

Frequently Asked Questions

How long should the transition-out period be in a UK software development contract?

For most enterprise custom builds, 60-90 days is a defensible range, with an option for the buyer to extend by a further 30-60 days at the same pre-agreed rate. Shorter than 30 days rarely leaves enough time for a successor team to run a full build-and-deploy verification; longer than 120 days as a default tends to inflate cost without adding safety. What drives the specific number is system complexity, the number of third-party integrations, whether the vendor hosts any part of the stack, and whether you have an internal team ready to receive or need to onboard a replacement vendor first.

Does source-code escrow replace the need for a strong handover clause?

No. Escrow protects you against one scenario — the vendor disappearing or becoming insolvent — and only works if deposits are frequent, verified by the escrow agent, and scoped to include the full operational estate, not just source code. For the far more common scenarios of relationship breakdown, performance issues, or convenience termination with a still-trading vendor, a well-drafted transition-out clause with pre-agreed deliverables and acceptance criteria does more useful work than escrow does. Treat escrow as a complement, not a substitute.

What should a UK-regulated firm's exit plan cover under SS2/21?

The PRA's Supervisory Statement SS2/21 requires exit plans for material outsourcing arrangements to cover both stressed and non-stressed termination scenarios, with estimates of cost, resourcing, timing, and data recovery priorities. In practice this means a documented inventory of what gets transferred, a named successor arrangement or in-house capability, a tested data export path, and evidence that the plan is reviewed. Your compliance team or external advisers should sign off on the specific documentation your regulator expects — this post is not a substitute for that review.

Who owns the cloud accounts if the vendor set them up on our behalf?

Whoever is on the root account owns them, which is why this should be settled on day one of any engagement rather than at exit. The protective default is: cloud accounts (AWS, Azure, GCP), DNS, CDN, monitoring, and any SaaS tool bought for the project are opened in the client's name with the vendor added as admin. If accounts already exist in the vendor's name, your handover clause needs a defined account transfer path with named timelines, and your governance process should start the transfer well before any termination discussion.

Can we hire the vendor's engineers who worked on our build once the contract ends?

Only if your contract allows it. Most development contracts include a non-solicitation clause of 6-24 months post-termination, and some are drafted broadly enough to cover passive applications as well as active approaches. If you anticipate wanting to retain tribal knowledge by hiring specific individuals, negotiate a carve-out in advance — either an explicit permission, or a defined buyout fee per hire. Your employment lawyer should review both the vendor contract and any UK-specific restrictive-covenant implications before you make an offer.