16 June 20268 min read
Partnerships end. Sometimes badly, more often for entirely ordinary reasons: the client's work finishes, your capacity needs change, the partner shifts focus, a key person leaves and the team is not the team you contracted with. None of that is a scandal.
What decides whether the ending is quiet or expensive is a handful of terms that both parties are least motivated to negotiate at the moment they can, which is the beginning, when everyone is optimistic and eager not to seem distrustful.
The terms that make an exit survivable
Six provisions do nearly all the work. They are unremarkable to include and painful to be without.
- Notice, on both sides, long enough to restaff. Thirty days is common and often too short for a team of any size; sixty is more honest for anything beyond one or two people.
- A transition period after notice, during which the partner continues working at agreed rates, plus a stated obligation to cooperate in handover. Without it, notice ends and so does everything else.
- Deliverables on termination, named specifically: repositories, credentials, environment configuration, infrastructure access, documentation, and anything that exists only on a partner machine.
- Data return and deletion, with a deadline and written confirmation, matching whatever you promised your client in the data processing agreement.
- Survival of confidentiality, IP assignment and non-solicitation past the end date, so that termination does not quietly release the protections.
- Payment on termination: what is owed for work in progress, and what happens to any prepaid or committed amount.
A partner who resists all six is telling you something useful early. A partner who has their own version of the list has been through this before, which is a good sign rather than a bad one.
The knowledge that leaves with them
The commercial terms are the easy part. The costly part of an ending is understanding: why the integration retries three times, which client stakeholder must approve a schema change, what the workaround in the payments module is protecting against. Almost none of that is written down at the point notice is given.
The best defence is not a heroic handover document written in the final fortnight, which will be thin because nobody can recall what they know on demand. It is a habit of continuous documentation during the engagement: decisions recorded where they were made, runbooks updated as part of done, environment setup that a new person can follow without help. This is one of the arguments for keeping the partner in your tooling and your repositories throughout, because knowledge captured in your systems stays when the people go.
You cannot extract three years of understanding in two weeks of notice. You can only have been writing it down as you went.
Handover, in the order that works
When an ending is planned, sequence it deliberately rather than treating the last day as a cliff.
Freeze scope first. Stop starting new work at the point notice is given, and finish or explicitly abandon what is in flight. Half-built work with no author is worse than no work.
Then run the documentation sprint: architecture and its reasoning, the operational runbook, known issues and their history, and the environment setup, verified by someone who does not already know it. Documentation nobody has followed end to end is a draft, not a handover.
Then overlap the people. The incoming team, whether your own or another partner's, works alongside the outgoing one for a defined period while the outgoing team is still paid and still accountable. Paying two teams briefly is cheaper than a cold start on a system nobody understands, and it is the step most often cut for budget reasons and most often regretted.
Then transfer access and revoke it. Every credential, repository permission, cloud role, third-party account, and shared secret, on a list you can tick through. Revocation is a security event, not an administrative one, and it should have a date and an owner.
Finally, close the loop on data: return, delete, confirm in writing, and file the confirmation where your client's auditors could find it.
What the client should hear
If you disclosed the partner arrangement properly, this conversation is small: the delivery partner is changing, here is the transition plan, here are the dates, accountability is unchanged. That is the whole message, and it should arrive before the client notices new names rather than after.
Do not explain the ending by criticising the partner. Even when the partner was genuinely the problem, telling the client so raises a question they had not asked, which is why you chose them and what your judgement is worth. Take the transition as your responsibility, because it is.
Do be realistic about pace. A team that has just taken over will be slower for a while, and saying so in advance costs one uncomfortable sentence, while discovering it together costs trust.
Endings that should not be endings
Two situations get mistaken for a reason to terminate. The first is a single failed project inside an otherwise good relationship. Run the post-mortem before the decision: it is common to find the specification was thin or the direction was yours, and replacing the partner would move the same failure to a team that has to learn everything again.
The second is a quiet period in your pipeline. Ending a working partnership because there is no work this quarter means paying the full ramp again in six months. A dormant arrangement with a small continuous stream, or an agreed pause with the terms intact, keeps the option open for far less than a restart costs.
Ending well is a commercial asset
The industry is small and people move. A partner who was treated fairly on the way out refers work, takes your call in a crisis, and speaks well of you to people who are deciding whether to trust you. Pay the final invoice on time, honour the transition period rather than trying to shorten it once you have what you need, and say plainly why it ended. It costs almost nothing at the point it matters, and it is the part of a partnership people remember most clearly.