A handoff is the moment your work stops being your problem and becomes someone else's job. Done well, the client's team can run the website, use the brand system or maintain the code without calling you every week. Done badly, you get a stream of "quick questions," the client feels abandoned, and a new contractor six months later rebuilds half of it because nobody could find the source files.
The test of a good handoff is simple: could a competent stranger pick this up using only what you delivered? This checklist is designed to get you to yes.
TL;DR
The project handoff checklist covers six areas: deliverables and source files, accounts and ownership transfer, credentials, documentation, training, and known issues, ending in written sign-off. Use it whenever finished work moves to a client's team or another contractor. The single most useful test is whether a competent stranger could run the work using only what you handed over; if not, the documentation is not finished.
What's inside
- Inventory — a list of everything being handed over, with location and format.
- Source and working files — editable originals, not just exports.
- Accounts and ownership — domains, hosting, licenses, repositories and tools moved into the client's name.
- Credentials — transferred securely, with your access removed afterward.
- Documentation — overview, how-to guides, third-party contacts, architecture or system notes.
- Training — live or recorded walkthroughs for the people who will own the work.
- Known issues and recommendations — honest list of limits, bugs and next steps.
- Sign-off — written confirmation from the client.
When to use it
Use it at the end of website and app builds, brand identity projects, marketing system setups (email tools, analytics, ad accounts), operations or process work, and any project where someone else will maintain what you made. It is also the right tool when you are handing work to another freelancer or agency mid-stream.
For the broader end of the relationship, including final billing and feedback, run the client offboarding checklist around this one. For a site going live, the website launch checklist covers pre-launch checks before you hand over.
What clients most often cannot find later
Freelancers who do a lot of handoffs see the same gaps:
- Editable source files. The client has PNG logos but not the vector master, or the compiled site but not the repository.
- Font and plugin licenses. Bought under your account, so the client cannot renew or extend them.
- Domain registrar logins. Often set up years earlier by someone else, and the first thing that breaks.
- Who to call. The hosting provider, the payment processor, the email tool. List support contacts for every third-party service.
- Why things are the way they are. A short note on key decisions ("we chose X because Y") stops the next person undoing them.
Ownership versus access
Giving the client a login is not the same as giving them ownership. For anything that matters, such as domains, hosting, repositories, ad accounts and analytics, the client should be the owner or primary admin, and you should be a user they can remove. If accounts were set up in your name, transfer them as part of the handoff. Do the transfers before your last invoice is paid, while you still have the client's attention; chasing a registrar transfer three months later rarely goes well. If intellectual property rights need to change hands formally, an IP assignment agreement records it.
Customize it in your COLO workspace
In COLO you can turn the checklist into tasks inside the project, with statuses, priorities, comments and files, and make selected tasks visible to the client so they can tick off their side. Final files and documentation can be shared in the client portal, where the client also sees the project's invoices and contracts. See Task Management.
Questions during the handoff can stay in the project's chat with the client, so answers are written down rather than lost in calls.
Why this template works
- It separates ownership from access. The client owns what matters.
- It forces documentation. The stranger test makes gaps obvious.
- It lists known issues. Honest limits now prevent blame later.
- It ends with sign-off. Everyone agrees the work has moved.
FAQ
Q: What is a project handoff?
A project handoff is the transfer of finished work, and everything needed to run it, from you to the client or to another team. It covers files, accounts, documentation, training and a list of known issues.
Q: What is the difference between handoff and offboarding?
Handoff is about the work: making sure someone else can own and operate it. Offboarding is about the relationship: final billing, access removal, feedback and follow-up. Handoff is usually one step inside offboarding.
Q: What documentation should a handoff include?
At minimum: what was built or delivered, where it lives, how to log in, how to do common tasks, who to contact for third-party services, and a list of known issues or limitations.
Q: Should I record a training session?
Yes, if the client agrees. A recorded walkthrough of common tasks saves you repeat support requests and helps new staff on the client side months later.
Q: When is the handoff complete?
When the client has confirmed in writing that they have received everything on the checklist, can log in to every system, and accept the known-issues list.