Software handover document: template, checklist and example

Published 26 October 2026

A software handover document lists everything a client needs to own, run and change the system without the people who built it: what was delivered against what was agreed, who owns the code, the accounts and environments, the documents, the data, the open items, and who to call afterwards. Below are a template to copy, a filled-in example, a checklist, the test to run before handing over, who owns the code, and what goes wrong.

CHECK THIS BEFORE SUBMITTING: take the zip file you created and unzip it. follow the instructions you have created in step 4. Are you able to build, run, and access everything? If not - you are not done!

— Iowa State University’s senior design course, handover instructions for student teams delivering to a client

What a software handover document includes

• What was delivered, against what was agreed: the requirements version, the change requests delivered, declined or moved, the acceptance, and anything not delivered.
• Who owns what: the written assignment of the code and documents, and the third-party components with their licences.
• The code and how to build it: the repository the client owns, the version handed over, and build and deploy instructions that someone other than the author has followed.
• Accounts and environments: domains, hosting, cloud, app stores, analytics, payments — each with the client as owner and the supplier’s access removed or dated.
• Documents: user and admin guides, a maintainer’s guide, the architecture, the decisions, the test results.
• Data: where it is, the backups, the export format.
• Open items: each one a warranty fix or a change request, with a date.
• Support after handover: the warranty period, the support terms, who answers questions and until when.
• Knowledge transfer: the sessions held and where the recordings are.
• Receipt: who received it, and when.

Software handover document template

Copy it into Word, Google Docs or Confluence. Square brackets are yours to fill in.

SOFTWARE HANDOVER

Project:   [name], [phase or release]
Contract:  [statement of work], [date]
From:      [supplier], [contact]
To:        [client], [who receives it]
Date:      [handover date]

1. WHAT WAS DELIVERED
   Requirements:  version [x.y], agreed
                  [date]
   Changes:       [CR ids] delivered;
                  [CR ids] declined;
                  [CR ids] moved to
                  [phase]
   Accepted:      [UAT sign-off, date]
   Not delivered: [what, and why]

2. OWNERSHIP
   Code and documents assigned to
   [client] by [document], signed [date]
   Third-party components and licences:
   [file or list]

3. CODE AND BUILD
   Repository:  [URL], owned by [client]
   Version:     [tag or commit]
   Build and deploy: [file]; followed
                on a clean machine by
                [who], [date]

4. ACCOUNTS AND ENVIRONMENTS
   [account]  Owner:  [client]
              Admins: [two people]
              Supplier access: [removed
              / until date]

5. DOCUMENTS
   [user guide, admin guide, maintainer
   guide, architecture, decisions, test
   results]: [where]

6. DATA
   [what, where, backups, export format]

7. OPEN ITEMS
   [id]  [what]
         [warranty fix / change request]
         by [date]

8. SUPPORT AFTER HANDOVER
   Warranty:   [from] to [to]
   Support:    [contract, hours, how to
               report a problem]
   Questions:  [who], until [date]

9. KNOWLEDGE TRANSFER
   [topic], [date], recording: [where]

10. RECEIVED
   Name, role:  [   ]
   Decision:    [received / received
                with the open items]
   Date:        [   ]

Software handover example

The customer portal used across this site — a client’s customers see their invoices and pay them by card — at the end of phase 1. In the project sign-off, “Code, scripts, accounts” was accepted on 21 May against “the handover list”. This is that list:

SOFTWARE HANDOVER

Project:   Customer portal, phase 1
Contract:  Statement of work, 2 February
From:      Supplier, delivery lead
To:        Client, product owner and
           IT lead
Date:      21 May

1. WHAT WAS DELIVERED
   Requirements:  version 1.3, agreed
                  7 March
   Changes:       CR-5, CR-7 delivered;
                  CR-6 declined;
                  CR-8 moved to phase 2
   Accepted:      UAT sign-off, 16 May
   Not delivered: nothing in 1.3

2. OWNERSHIP
   Code and documents assigned to the
   client in the services agreement,
   signed 2 February
   Third-party components and licences:
   LICENSES.md in the repository

3. CODE AND BUILD
   Repository:  the client's GitHub
                organization
   Version:     tag release-2
   Build and deploy: README.md and
                DEPLOY.md; followed on
                a clean laptop by the
                client's developer,
                20 May

4. ACCOUNTS AND ENVIRONMENTS
   Domain     Owner: client
              Supplier access: none
   Cloud      Owner: client
              Admins: IT lead, CTO
              Supplier access: until
              19 July (warranty)
   Payments   Owner: client (provider
              account in the client's
              company name)
   Analytics  Owner: client
              Supplier user removed

5. DOCUMENTS
   Admin and support guide; maintainer
   guide; architecture; decision log
   D-1 to D-8; test results release 2:
   the repository's docs/ folder

6. DATA
   PostgreSQL, EU region; daily backups,
   30 days kept; restore tested 14 May

7. OPEN ITEMS
   DEF-34  CSV export shows US dates to
           German users
           warranty fix, by 6 June
   CR-9    Invoices in French
           change request, phase 2

8. SUPPORT AFTER HANDOVER
   Warranty:   21 May to 19 July
   Support:    monthly retainer
   Questions:  delivery lead, until
               19 July

9. KNOWLEDGE TRANSFER
   Architecture and deploy, 19 May;
   admin tasks, 20 May; both recorded,
   links in docs/

10. RECEIVED
   Name, role:  IT lead (client)
   Decision:    received with the open
                items
   Date:        21 May

Two lines in it are easy to skip and expensive to miss. “Followed on a clean laptop by the client’s developer” is the difference between instructions and instructions that work. And “Not delivered: nothing in 1.3” names the version: the client can check the claim against the change log, not against memory.

Software handover checklist

Ownership

• The code and documents assigned to the client in writing, signed.
• Third-party and open-source components listed, with their licences.
• Contracts, subscriptions and licences the client must take over or re-sign.

Code and build

• The full source, with its history, in a repository the client owns.
• The version handed over tagged; unfinished work listed with where it is and what is left.
• Build and deploy instructions followed by someone who did not write them, on a clean machine.
• Secrets and deploy keys rotated; the supplier removed as owner or collaborator.

Accounts and environments

• Domain names, DNS, hosting, cloud accounts, app store accounts, analytics, payment provider, email and monitoring: each owned by the client.
• At least two people on the client’s side with admin rights on each.
• The supplier’s access removed, or kept until a named date.

Documents

• User guide for every role, and an admin guide.
• A maintainer’s guide: architecture, configuration, deployment, tests, troubleshooting.
• The requirements as delivered, the change log, the decision log and the test results.
• What it costs to run, and to grow.

Data

• Where the data is, the backups, a restore that has been tested, and an export in an open format.

People and sign-off

• Knowledge-transfer sessions held and recorded; questions answered until a named date.
• Open items listed, each a warranty fix or a change request.
• Warranty and support terms confirmed.
• The handover received in writing.

Platforms move accounts in ways that are easy to get wrong. Changing the owner details of a domain can lock it: ICANN’s rule is that “registrars must impose a lock that will prevent any transfer to another registrar for sixty (60) days following a change to a registrant’s information”, so move the registrar first (ICANN). A transferred GitHub repository keeps its “webhooks, services, secrets, or deploy keys” (GitHub). Apple moves an app only if it “must have at least one version that was released to the App Store” (Apple), and “The transferor is responsible for exchanging the actual code set and building assets directly with the recipient” (Apple). The simplest fix is not to need a transfer: Google’s own advice for Tag Manager is to “make sure your account is managed by someone in your organization, not an external agency” (Google).

The handover test: rebuild it from the package

University software courses that deliver to real clients define “handed over” more strictly than many contracts. Iowa State’s is the test quoted at the top: unzip the package, follow your own instructions, and if you cannot build, run and access everything, “you are not done”. The University of North Carolina tells its teams that “a pointer to a github repo is not good enough. You need to provide a step-by-step process the client can follow to get the system set up and executing” (UNC COMP 523). Northern Arizona University ends with a check-off the client signs: “Your signature documents that you have received the product in good working order, and are confident that you’ll be able to operate it going forward.”

Run the test with the people who will receive it, not only with the people who built it. The best proof of the build instructions is the client’s developer following them, as in the example above.

Who owns the code after handover

Paying for software does not by itself make the client its owner. The UK Intellectual Property Office: when you commission a work, “the first legal owner of copyright is the person or organisation that created the work and not you the commissioner, unless you otherwise agree it in writing” — and its example of shared ownership is a website built by a contractor together with a company’s own employee (UK IPO). UK law adds that “An assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor” (CDPA s.90), and US law has the same rule for a transfer of copyright (17 U.S.C. §204).

Even government model contracts do not hand the code over by default. The UK’s G-Cloud contract: “neither Party shall acquire any right, title or interest in or to the Intellectual Property Rights (“IPR”s) (whether pre-existing or created during the Call-Off Contract Term) of the other Party or its licensors unless stated otherwise in the Order Form” (G-Cloud 14 call-off contract).

So the handover document points to the signed assignment, made when the work was agreed — in the contract or the statement of work — not at the end. Where the supplier keeps the code, source-code escrow is the usual fallback. This is general information from official guidance, not legal advice.

What was agreed, and what was delivered

A handover document that lists only artefacts misses the question the client will ask first: does the system do what we agreed? Cornell’s software engineering course asks its teams for “a detailed summary of which originally-requested features were delivered, which were revised (with client approval) over the course of the project, and which could not be delivered” (Cornell CS 5150). NASA’s systems engineering handbook lists, among what travels with a delivered product, “applicable baseline documents (configuration baseline, specifications, stakeholder expectations)” and the test results (NASA).

That is the part the next team misses most. Thirty agile teams studied at handover “perceived the biggest gaps in the usefulness of available design and requirements documentation” (Stettina and Kroon, 2013). One consultant who rescues failing projects: “This is why understanding the requirements is more important than the code” (Hacker News, 2018). And in a controlled experiment, people maintaining someone else’s system with links from requirements to code “performed on average 24 % faster on a given task and created on average 50 % more correct solutions” (Mäder and Egyed, 2015).

So the first section of the template is the requirements baseline as delivered: the version, the change requests since it, and the acceptance — the same record as the UAT sign-off and the project sign-off.

What goes wrong at a software handover

Research on handover is thin — a 2013 thesis calls it “a strongly under-researched and neglected domain” — but what it finds is consistent. Five organisations interviewed about handover named the same problems: insufficient system knowledge, lack of domain knowledge, poor communication, inadequate documentation, and changes nobody tracked. “All the organizations studied have pointed out the problem of inadequate or insufficient documentation at the moment when the system is being handed over”, because teams are “so much in a hurry to deliver the system so that they wait with completing the documentation” (Khan and Kajko-Mattsson, 2010).

The accounts are in the wrong hands. One commenter’s town: when “the One Guy at the biggest web agency quit in anger”, “nobody else at that company had the passwords to liberate the domains, dozens of businesses in my town had to buy new domains” (Hacker News, 2015). Another describes an agency employee who, at the end of a contract, “removed himself as an admin on the page in order to “hand over the keys.” Except he hadn’t made anyone else an admin yet”; the client was locked out for four months (Hacker News, 2021).

The code is held back. “I had a client who’s previous agency flat out refused to hand over anything. All invoices were paid and the website was running launched and running since months” (Hacker News, 2015).

The documents are out of date, or unread. Handover documents, one commenter writes, “should all read “For historical purposes only” because you will inevitably trip over reality if you rely on them for live systems” (Hacker News, 2017). This is measurable: 28.9% of the most popular projects on GitHub reference code that no longer exists (Tan et al., 2023). And written is not read: one developer left a wiki of known gotchas, was called three months later about a system that was down, and asked why nobody read the docs. “They responded “what docs?”” (Hacker News, 2020).

The “why” is gone. 66% of developers surveyed at Microsoft rated “understanding the rationale behind a piece of code” a serious problem (LaToza et al., 2006). A decision log, kept during the work, is how the reasons travel.

One meeting stands in for years of context. “We call them “KT” sessions (knowledge-transfer). I shiver all down my spine when I hear “KT”” — one hour “to brain dump their entire existance” (Hacker News, 2023). Studies of product transfers at Ericsson found that “competence transfer through documentation and theoretical training even in co-location is inefficient” (Šmite and Wohlin, 2011); working on real tasks with the original team worked best.

Expect a dip. The same researchers: “transfers are never complete: a 100 percent transfer of knowledge and experience is impossible. The first year of independent performance is critical and often associated with decreased efficiency” (Šmite and Wohlin, 2011). In one transferred product, releases that came twice a year slowed to eight months, then to a year (Jabangwe and Šmite, 2012). The warranty and the “questions until” date in the template are there for that year.

Plan the handover at the start

Every item on the checklist is cheaper at the start of the project than at the end. The domain, the cloud account and the app store account can be the client’s from the first day, with the supplier added as a user — one freelancer’s rule: “company resources should be created under accounts belonging to the company, which you are granted access to” (r/freelance, 2024). The assignment of the code goes in the contract. The documents grow with the work, not in the last week.

Public-sector contracts write this down. The UK’s Model Services Contract requires the supplier to deliver an exit plan “within 3 months after the Effective Date”, and to keep a configuration database detailed enough “to permit the Authority and/or Replacement Supplier to understand how the Supplier provides the Services” (Schedule 21). The US federal clause on continuity of services has the contractor “furnish phase-in, phase-out services for up to 90 days after this contract expires” (FAR 52.237-3). The software maintenance standard’s summary puts it in one line: “Ideally, maintenance planning should begin during planning for software development” (IEEE/ISO/IEC 14764).

For a client project, that means three lines in the statement of work: who owns the code, what will be handed over, and how long the supplier answers questions afterwards.

Handover document vs project sign-off vs knowledge transfer

The project sign-off accepts the handover as one of its deliverables; the handover document is the list behind it. “Handover” and “handoff” mean the same thing here; in searches, “handoff” now also means passing work from one AI coding session to the next.

Handover email

Subject: Handover: [project], [release]

Hi [name],

The handover of [project], [release], is
attached, with:

- what was delivered against
  requirements version [x.y]
- the repository, now in your account
- the accounts, each now owned by you
- the documents and the recordings
- [n] open items, each with a date

Please check you can sign in as owner to
each account, and that your developer
can build it from the instructions.

The warranty runs from [date] to [date].
I'll answer questions until [date].

Please reply "Received" or "Received
with the open items", or tell me what is
missing.

Thanks,
[name]

Where Specroot fits

This is the problem Specroot works on: the requirements as delivered — every version, every approved change, and who agreed each — kept as one record that can be handed over with the code, instead of reassembled from email at the end. Specroot for agencies and consultancies.