Software Project Handover Template for Client Handoffs
A project handover template records what a vendor handed over, in which version and who owns which account. Here's what to include, with a template to copy.
Overview & context
The handover document usually gets written on the project's last day. Below you'll find what belongs in a software project handover, a project handover template to copy and a filled-in example.
1. Project handover document vs. handover checklist
Two documents meet at an app handover. The handover checklist is for the vendor's team: what needs to be transferred, checked and prepared. The project handover document goes to the client, who signs it.
The handover document records what was handed over, in which version, who owns which account afterwards and which known limitations the client accepts. The client opens it when dealing with a warranty claim, a vendor change or an audit, so it has to make sense to someone who wasn't there for the handover.
2. Project handover template
The template covers the handover of one app. Fill in the values in angle brackets and leave out the parts that don't apply. For transferring a repository to the client, see GitHub's guide Transferring a repository.
# Sample project handover document: <app name>
## 1. Parties and date
- Vendor: <company, responsible person>
- Client: <company, responsible person>
- Handover date: <date>
## 2. What's being handed over
- App: <name, short description>
- Version: <version number>, repository tag <v1.0.0>
- Environments: <production, staging> with URLs
## 3. Accounts and access
| Service | Owner after handover | Transferred | Where credentials are stored |
| --- | --- | --- | --- |
| Repository | <client> | <yes/no> | <client's password manager> |
| Hosting | <client> | <yes/no> | <…> |
| Domain and DNS | <client> | <yes/no> | <…> |
| Email service, payment gateway, … | <…> | <…> | <…> |
## 4. Documentation
- Developer and operations docs: <link>
- User documentation: <link>
- Overview of the app's links: <link>
## 5. App status
- Known bugs and limitations: <list or link>
- Technical debt: <list or link>
## 6. Open tasks
- <task, who finishes it, due date>
## 7. Support after handover
- Warranty period: <until date>
- Support contract and SLA: <link>
- Where to report bugs: <help desk, email>
## 8. Acceptance
- Client accepts the handover: <without reservations / with reservations>
- Reservations: <…>
- Signatures: <vendor, date> / <client, date>3. Project handover document example
Here's what part of a filled-in handover document can look like for a small web app an agency hands over to a client and keeps maintaining.
## 2. What's being handed over
- App: Ordering portal for wholesale customers
- Version: 2.0.0, repository tag v2.0.0
- Environments: production https://orders.example.com, staging https://orders-test.example.com
## 3. Accounts and access
| Service | Owner after handover | Transferred | Where credentials are stored |
| --- | --- | --- | --- |
| GitHub repository | Client | yes | GitHub, client's organization |
| Azure hosting | Client | yes | Client's password manager, Orders folder |
| Domain example.com | Client | earlier | Client's password manager |
| Email service | Agency | no, stays with the agency | Agency password manager |
## 5. App status
- Known bugs: CSV order export loses accented characters in Excel (fix in 2.0.1)
- Technical debt: the payment module uses an older gateway SDK, upgrade planned for Q14. How to write a handover document that still works a year later
A handover document that only makes sense to the people who were there won't help a year later. These points keep it readable for a new admin or the next vendor.
5. Handover information that stays current
The handover document captures the state on handover day. A few months later, there's a new environment, a new version or a new support contact and the document no longer matches reality. If you keep maintaining the app, the client needs a place with the current state and the handover document can link to it.
In AboutTheApp, you attach links to the repository, docs, hosting and support that concern only that client's installation. You mark them private and the client sees them with their unlock code on their About page, together with environments, deployed versions and release notes. The support contacts and a link to the SLA sit in the same place.
AboutTheApp holds the links and the overview, but it doesn't transfer accounts. The repository, hosting and domain have to be transferred in each service directly.
6. Legal disclaimer
The template and examples in this article are for illustration only. They aren't a legal document or legal advice. Always have your own legal counsel review any handover document and adapt it to your contract and the applicable law.
Frequently asked questions
What should a project handover document include?
The parties and handover date, the app with its version and environments, a list of accounts with their owner after handover, links to documentation, known bugs and technical debt, open tasks, support terms after handover and signatures from both sides.
Who signs the project handover document?
The vendor's responsible person, usually the project lead, and the client's responsible person, who has the authority to confirm acceptance. If the client accepts with reservations, they're written into the document before signing.
What is the difference between a project handover document and a handover checklist?
A handover checklist is the vendor team's task list before the handover. The handover document is the final document for the client that records what was handed over, and both sides sign it.
When should you start preparing a project handover?
At the start of the project. It's easier to record accounts, environments and documentation as you go than to dig them up at the end. Before the handover, you only add the version, app status and signatures.
Where should the client find app information after the handover?
In one place that stays up to date with the app. In AboutTheApp, the client sees links, environments, deployed versions and support contacts for their installation on their About page.
In short
A good handover document says what was handed over, in which version and who owns what. It also links to a place where the client finds the current state after the handoff.
Want to hand over apps with a live overview?
Add your app to AboutTheApp for free and attach the client's links, environments and support contacts.