English
Build your map

Free tool

What has to change hands in a software handover?

Forty-one items across nine areas. Tick them off here, or print the whole thing and take it into the meeting.

Build your map

0 of 49 done

Code and history

The repository is the easy part, and the part people assume is finished when it is not.

Environments
Infrastructure and accounts

The only section that can leave you permanently worse off rather than merely delayed. Establish ownership before revoking anything.

Deployment and release
Data and recovery
Integrations and dependencies
Operations
Understanding

The part that decides how long the handover takes, and the part that is almost never specified in a contract.

Closing the transfer

Ticks stay in this browser. Nothing is submitted, no account is needed and no email address is asked for. Print it, or clear it and start again.

  • 41 items
  • no account, no email
  • prints cleanly
  • ticks kept in your browser
Free tool Reviewed

Short answer

A software handover has to transfer four things: ownership of the accounts, the ability to operate and release the system, an understanding of what it contains, and the reasoning that exists only in people's heads. This checklist covers all four across nine areas — code, environments, infrastructure, deployment, data, integrations, operations, understanding and the mechanics of closing the transfer.

#The order these should happen in

The list is grouped by area for working through. The sequence is different, and getting it wrong is expensive.

  1. Ownership first, before notice is given if at all possible. This is the only category that can leave you unable to operate rather than merely delayed.
  2. The technical picture second, because its gaps are the agenda for everything after it.
  3. Demonstration third — run it, deploy it, restore it, while the people who know are still available.
  4. Reasoning fourth, and this is where the outgoing team's remaining attention should go, because nothing else can produce it.
  5. Rotation last, after ownership is confirmed and your own routes in are verified.

#What replaces 'documentation delivered'

If you write one thing into the engagement, write these three, as acceptance criteria:

  1. Ship. The incoming team deploys a real change to production without contacting the outgoing one.
  2. Recover. They restore a backup into a scratch environment.
  3. Explain. They answer ten questions about the system — chosen by you — correctly, in writing.

They are cheap to run, impossible to fake, and they change the incentives of everybody involved from the first week.

#What this checklist does not cover

What this does not do

  • Commercial and legal terms: intellectual property, notice periods, liability, warranties. Those need somebody qualified to look at your contract.
  • Anything specific to a regulated industry — payment, health and public-sector handovers all carry obligations this list does not know about.
  • Code quality, security and architecture review. A handover establishes that a system can be operated, not that it is good.
  • People. Whether the incoming team is capable is not something a checklist can establish.

Questions people actually ask

No. It is on this page, it prints, and there is no gate of any kind. A checklist behind an email form is a lead magnet rather than a checklist.

In this browser only, so a reload does not lose them. Nothing is sent anywhere — there is no server behind this page.

Yes. Several people do exactly that with lists like this one. If you do, add the three acceptance tests as the completion criteria rather than "documentation delivered".

The understanding section is the one that takes weeks.

A technical picture derived from the system itself covers most of it in hours, and turns the rest into a specific list of questions for the outgoing team. The first one is free.

Build your project map — free Check readiness first