Project handover document template for a small team

This document is for a small software or side project: a domain, code repository, hosting account, a few subscriptions, and perhaps a payment provider. It also works when a contractor hands a project back to its owner. The example is fictional and only shows how to fill the fields. It is not evidence of a real transfer.

Not legal, tax, or financial advice. A signed operational record does not transfer intellectual property, shares, a domain registration, or a provider account. Check the relevant agreement and each provider’s process for those changes.

What goes in the document?

Use one record for the handover and one row for each resource. A resource can be a domain, repository, deployment, database, email account, payment account, design file, or recurring subscription. Each row needs a named outgoing contact, a named incoming contact, the provider’s actual account holder, billing contact, recovery route, test, observed result, and next action. Keep the row open when any of those facts is unknown.

The distinction between listed, moved, and verified matters. A teammate can write “GitHub: transferred” in a document while the repository still sits in their personal account. The recipient should open the repository under their own login, inspect the owner shown by GitHub, and check the permission they need. A screenshot of the sender’s screen does not test the recipient’s access.

Copy the project handover document template

Paste this into a document or project wiki. Keep it private if it names account holders or recovery contacts. Replace every bracketed field. If a field cannot be confirmed, write “unknown” and assign someone to find out; do not make the document look complete by deleting the field.

PROJECT HANDOVER RECORD

Project: [name]
Handover reason: [role change / contractor exit / cofounder exit / sale / pause]
Record owner: [name]
Outgoing contact: [name and safe contact method]
Incoming contact: [name and safe contact method]
Handover date and time zone: [date, time zone]
Scope: [what is included]
Out of scope: [what is not being handed over]
Source agreement or decision: [document link, if one exists]

CURRENT OPERATING STATE
Live site or product: [URL and observed status]
Code and release location: [repo and deployment location]
Last known good release: [identifier and date]
Where to find the runbook: [link]
Where to report an incident: [contact and channel]
Next renewal or deadline: [item, date, owner]

RESOURCE ROW — copy once per account or asset
Resource and purpose: [name, provider, what it controls]
Current registered/account owner: [name/entity, confirmed in provider]
Current admins: [names/roles, confirmed in provider]
Current payer and billing email: [who pays, who sees invoices]
Incoming owner/admin needed: [name and exact role]
Recovery route: [who controls it; vault/location reference only]
Change required: [invite / account move / registrar transfer / no change]
Provider instructions checked: [official URL and check date]
Change authorized by: [name/role and date]
Change completed by: [name/date or pending]
Recipient test: [specific action they can do with their own login]
Observed result: [pass/fail/untested; date; verifier]
Evidence location: [safe link to screenshot, receipt, or audit log]
Open issue and owner: [gap, next action, due date]

COSTS AND COMMITMENTS
Recurring charges: [provider, amount/currency if known, renewal date, payer]
Unpaid shared expenses: [link to ledger and settlement rule]
Credits, trials, or grants: [terms, expiry, responsible person]
Customer, vendor, or event promises: [link, owner, next date]

FINAL REVIEW
Recipient can access code: [pass/fail/untested]
Recipient can deploy safely: [pass/fail/untested]
Recipient can inspect domain and DNS: [pass/fail/untested]
Recipient can see billing and renewal dates: [pass/fail/untested]
Recipient can locate recovery instructions: [pass/fail/untested]
Known open issues: [links; owner and due date for each]
Outgoing access removal plan: [who, when, after which tests]
Recipient acceptance: [name, date, accepted with listed exceptions]
Outgoing acknowledgment: [name, date]
Next review date: [date]

Do not paste passwords, API keys, recovery codes, identity documents, or full card details into this record. A vault reference tells an authorized person where to start; it is not the secret itself. Share the document only with people who need it.

Acceptance can say “accepted with exceptions.” That is more honest than a clean signature over three untested accounts. Record the exception, the person responsible, and the due date. If an exception blocks the next person from operating the project, leave the handover incomplete until the problem is resolved or an explicit temporary operating plan is agreed.

A filled example: two people, one small product

Here is a fictional example. Ada and Ben built a small web app. Ada registered the domain, created the GitHub repository under her personal account, and pays for hosting. Ben will operate the app from Friday. The team also uses a shared design workspace. They have not formed a company, so the document avoids claiming a corporate owner where none exists.

The current state says: the site is live; the last known good release is v0.8; the deploy runbook is in the repository; domain renewal is next month; and the hosting card remains Ada’s until Ben replaces it. These are example facts for the exercise, not facts about WhoOwnsWhat or a customer.

Friday’s sign-off should list the two gaps: GitHub is still untested, and hosting billing is still invisible to Ben. Ada and Ben can decide to delay the handover or accept it with a named temporary contact and due date. What they should not do is write “all accounts transferred” because the domain and billing rows contradict that sentence.

Notice the difference between access and ownership. Ben’s ability to read DNS proves only that he can read DNS. It does not prove he is the registered domain holder, can renew it, or can change it. His access to the source code does not prove he can deploy. The tests ask for the actual job he will need to do.

How do you run the handover without breaking the project?

1. Agree the scope before editing accounts

Write down what moves and what stays. “The project” can mean code, domain, hosting, customer data, design files, invoices, and ongoing obligations. One person may hand over operations while keeping an unrelated personal account. A different person may own a domain registration while another pays its renewal. The document should make those edges visible before anyone clicks a transfer button.

If the handover follows a cofounder exit or sale, identify the agreement or decision that authorizes it. The operating record cannot settle a dispute about legal rights. It can say that a question is unresolved and link to the place where the parties will resolve it. That keeps the technical handover from quietly pretending to be a legal one.

2. Inventory the dependencies

Start with the domain and the email used for account recovery. Then list source code, hosting, database, authentication, analytics, payments, design, support inbox, and subscriptions. Look for dependencies between them. If the recovery email for your domain lives on that same domain, write down the fallback route. If the deploy token was created by the outgoing person, log the token’s location and a planned replacement; never copy the token into the handover file.

Use the access audit to find accounts you may have forgotten and the bus factor guide to find one-person dependencies. The document here captures the transfer and acceptance record. The handover checklist helps you walk through categories while doing the work.

3. Check what the provider actually allows

Do not assume every provider has a transfer button. Some have a team owner role, some offer an account move, and some require a new account and migration. Record the official provider instructions next to each resource and check them on the day you make the change. Include prerequisites, possible downtime, billing implications, and who is authorized to start it.

For GitHub, a repository transfer is a specific operation with permission requirements and possible feature effects. GitHub says the person transferring needs administrative access and that the target organization must allow repository creation. A move to a different plan can affect features. Read GitHub’s repository transfer instructions before making the change.

For domains, changing the registered holder and transferring to another registrar are distinct operations. ICANN explains that an authorization code is used for a registrar transfer, not as proof that any document changed ownership. See the ICANN Auth-Code explanation and check the registrar’s current process and domain extension rules. If timing matters, verify locks and contact-change order before editing details.

4. Give the recipient their own access and test it

Where a provider supports separate users, invite the recipient with the minimum role needed to perform their job. Have them sign in on their own device. Ask them to demonstrate the operation that matters: view the renewal date, see the deployment history, open the admin settings, export a non-sensitive report, or locate a backup. Write the observed result in the document. “Invitation sent” is not “access verified.”

Keep the test non-destructive where possible. Do not rotate production secrets or remove the outgoing admin as a rehearsal. For a deployment, a safe check might be viewing the pipeline and reviewing a documented dry run. A live release belongs in a planned change window. If the only way to prove a capability is a real change, plan it, get the right authorization, and record the result separately.

Billing needs its own test. GitHub’s organization ownership instructions explicitly separate adding an owner from updating payment information. Use that as a reminder to check the bill, invoice access, and renewal contact for every provider. A new admin may still be unable to see billing.

5. Handle secrets and outgoing access last

List which credentials, keys, webhooks, and recovery routes depend on the outgoing person. Record a secure location and a responsible person, not the secret value. Follow each provider’s documented process to replace access. When a credential must change, prepare the replacement, test it, and only then revoke the old one. Track what you changed and what you still need to check.

Remove outgoing access only after the recipient’s required capabilities pass. The exact order can differ for a payment account, domain registrar, or organization. If the departing person still needs a temporary role to resolve an open issue, define that role, its scope, and its end date. Do not leave a broad permanent admin role because the document says “handover complete.”

What counts as proof?

A good proof is tied to a specific claim. “Ben can see hosting invoices” can be supported by Ben’s successful login and a screenshot showing the invoice list without payment details. “The domain holder changed” needs confirmation from the registrar’s account or notice. “The repository moved” can be checked by opening its new owner path and settings. Keep evidence in a restricted folder; the handover document should link to it, not expose private data publicly.

Do not create evidence by publishing secrets or personal details. A verifier name, date, pass/fail result, and restricted evidence link are enough for most small teams. If a row fails, the failure itself is useful. It tells you what to fix while the outgoing person is still available.

How do you close the record?

Review the resource rows together. Every critical row should be marked passed, failed, or untested. There should be no blank status that could be mistaken for success. Assign each failed or untested item an owner and a due date. Record any temporary operating arrangement, such as “Ada remains billing contact until Ben confirms invoices on Thursday.”

The recipient then accepts the handover with those exceptions written out. The outgoing person acknowledges the same version. Put a review date in the document because subscriptions, people, and roles change. If you later fix a failed row, add the new test result and date. Do not overwrite the original failure; the sequence explains what happened.

One last test is simple: ask the recipient, without the outgoing person’s help, “Where is the live code? How would you check a failed deploy? Who pays for the domain, and when does it renew? Which account could lock us out?” If the answers are still in one person’s head, the document needs another pass.

Frequently asked questions

Sources and related pages

Provider guidance checked 11 November 2026. Recheck the instructions when you make a change; roles and transfer rules vary.

• GitHub Docs: transferring a repository — prerequisites and effects.
• GitHub Docs: transferring organization ownership — role and billing steps.
• ICANN: About Auth-Code — registrar transfer code and its role.
• Project handover checklist — categories to inspect while working.
• Access audit — discover who controls each account.
• Bus factor guide — find one-person dependencies before the move.