Handover (software handover)
Also called handoff, knowledge transfer, project handover.
Moving the code, accounts, documents and know-how of a product from the team that built it to the team that will run it.
Last updated
What it is.
A handover happens when a supplier finishes a build, when a contract ends, or when work moves to an in-house team. A complete one covers the code repository, build and deploy steps, every account and credential, architecture notes, open bugs and known technical debt, and a few sessions where the new team asks questions.
The easiest handovers are the ones prepared from day one: repositories, cloud accounts and app store listings already in the client's name, and documentation kept up as the work goes.
Why it matters
If the handover is weak, the next team spends weeks rediscovering how things work, and the product depends on people who have left. A good one is what makes IP assignment real in practice and keeps vendor lock-in low.
In a product build
Handover is planned as the last milestone of a product build, with its own checklist, rather than left for the final week.
Common mistakes.
- 01
Accounts opened in the supplier's name for speed and never moved.
- 02
Documentation written in the last week, from memory.
- 03
No overlap period where the new team can ask questions while the old team is still around.
Work it out with a tool.
Related terms.
- IP assignmentThe part of a contract that transfers ownership of code, designs and other work from the people who made them to the client.
- Source code escrowAn arrangement where a vendor's source code is held by a neutral third party and released to the customer if agreed events happen.
- Vendor lock-inWhen leaving a supplier, platform or tool would cost so much time or money that you are effectively stuck with it.
- Technical debtThe future cost of shortcuts taken in code today.
