A project handoff transfers everything the client needs to own the work without you: source files in editable formats, every credential you hold, written documentation, a recorded walkthrough, and an honest note on known limitations. Do it as a scheduled 45-minute session rather than an email, and deliver a structured pack rather than a folder link that will lose permissions in six months. The section agencies leave out and should include is what to watch - the decisions you made and the things that will need attention later. It feels like exposing yourself and it is the clearest possible signal that you optimised for their outcome rather than for lock-in.
The handoff is the last thing a client experiences and the first thing they remember when someone asks what you were like to work with.
It is also, in most agencies, an email with some links in it. The work was good, the relationship was good, and the ending is a Dropbox folder and a hope that the credentials in there are current.
That gap is worth closing, and not only for goodwill. A weak handoff generates support requests you are not being paid for, creates a security exposure that is genuinely yours as much as theirs, and quietly costs you the referral - because the thing a client describes to a peer is rarely the design, it is how the whole engagement felt to run.
This guide covers what belongs in a handoff pack, running the session, the technical checklist by discipline, security and access, and what to agree about support afterwards.
Why it is worth the hour
The handoff is unbilled work that happens after the project is finished, competing against the next client's urgent needs. It loses unless the value is clear.
Four things it buys: no unpaid support tail, no lingering security exposure, a referral you would otherwise not get, and a former client who can operate what you built - which is the precondition for them coming back.
Handoff versus offboarding
Related, not the same.
The handoff is the transfer of the work itself - assets, access, documentation, knowledge. Operational and largely technical.
Offboarding is the wider process of ending the relationship: closing billing, requesting a testimonial, staying in contact. Covered in our guide to client offboarding.
The handoff sits inside offboarding, and it is the part with a checklist.
The one-line test
A good handover answers one question: could the client operate, update and hand on this work if you disappeared tomorrow? If the honest answer is no, the pack is incomplete regardless of how many files it contains.
The handoff pack
One structured deliverable rather than a scattering of links. Six sections.
1. Summary of what was delivered
Two or three paragraphs against the original objectives, with results if they exist.
This is not ceremonial. It is the document that gets forwarded internally when someone asks what the agency actually did - including to people who join the organisation a year later and are looking at your work with no context.
2. Every asset, in an editable format
Source files, not just exports. Design files, working documents, original images, fonts with their licences noted.
Organised and downloadable, not a link to your workspace. A shared folder in your account is not a handover; it is a dependency on your continued goodwill and a permission problem waiting to happen. Give them a structured set that lives in their world.
3. Credentials and access
Everything you hold, listed, with what each is for: domains, hosting, DNS, analytics, CMS, third-party services, repositories, email or DNS records you configured.
Two rules. Never send credentials in plain text - use a password manager share or their IT process. And list even the things you think they already have, because the ones nobody remembers configuring are exactly the ones that cause a crisis eighteen months later.
4. Documentation
How to operate and update what you built. Written, in their language rather than yours.
Cover the common tasks - adding a page, changing content, updating a price, adding a user. Not an exhaustive manual; the ten things they will actually need to do.
5. A recorded walkthrough
Twenty minutes, screen recorded, talking through the same ground.
This is the highest-value-per-minute item in the whole pack. It costs you twenty minutes and it is what the person who joins their team next year will actually watch, because nobody reads documentation first.
6. Known limitations and what to watch
The section that feels risky and matters most.
What is deliberately not handled. Decisions you made and why. Things that will need attention in six or twelve months - a certificate, a dependency, a plugin that will need replacing. Anything a future supplier should understand before changing it.
Agencies leave this out because it reads like listing your own shortcomings. It reads as the opposite. A handover that names its limitations is a handover from someone confident in their work, and it is the clearest available signal that you optimised for the client's outcome rather than for making yourself hard to replace.
The handoff session
Forty-five minutes, scheduled, with the people who will own it afterwards - not only your day-to-day contact.
Ten minutes: what was delivered, against the objectives.
Twenty minutes: the walkthrough. Screen shared, going through the actual system. Record it.
Ten minutes: access and documentation. Confirm they can get into everything while you are still on the call. This is important - "here are the credentials" and "I have confirmed you can log in" are different things, and the gap between them is discovered at the worst possible moment.
Five minutes: what happens next. Support arrangements, who to contact, and for how long.
Invite whoever will maintain it, even if they were not involved in the project. The most common handoff failure is transferring everything perfectly to a person who leaves four months later.
Print it, do not remember it
Every item below is obvious in isolation and forgettable at 5pm on the Friday a project ends. A printed or pinned list is the entire mechanism.
The checklist by discipline
Websites and applications
- Repository access transferred, with your team removed
- Hosting, DNS and domain access confirmed working
- SSL certificates - who renews them, and when do they expire
- CMS admin accounts created for their people, yours removed
- Analytics and tag manager ownership transferred, not just shared
- Environment variables and configuration documented
- Backup arrangement explained - what is backed up, where, how to restore
- Third-party services listed with account ownership and renewal dates
- Any licences that need transferring or renewing in their name
Design
- Source files in editable format, with layers named sensibly
- Fonts, with licences and whether they transfer
- Image assets, including originals rather than only exports
- Brand guidelines if produced
- Design system or component library, with usage notes
- Anything licensed by you on their behalf, and what happens at renewal
Content and marketing
- All copy in an editable format
- Access to publishing platforms and scheduling tools
- Campaign structures, audiences and configurations documented
- Tracking and attribution setup explained
- Editorial calendar and anything scheduled beyond your end date
Every discipline
- Passwords transferred securely and rotated afterwards
- Your team's access removed and the removal confirmed in writing
- Support window and what it covers stated explicitly
Security and access removal
The part most likely to be done sloppily and the one with real consequences.
Remove your team's access, and say that you have. Lingering access to a former client's systems is an exposure for both parties. It surfaces badly in their next security review, and it is the kind of thing that damages an otherwise excellent relationship.
Have them rotate any credential you knew. Standard practice, not an accusation, and framing it as routine makes it easy: "we'd recommend rotating these now that we're handing over - normal practice at the end of any engagement."
Confirm removal in writing. A short list of what was removed and when. It protects you as much as them.
Say what data you are keeping, why, and for how long. If they want it deleted, do it and confirm.
Agreeing support afterwards
The ambiguity here generates more friction than anything else in the handoff.
State the support window explicitly. Two weeks or thirty days of questions included, and say what "included" covers - answering questions about what you built, not new work or fixing things they change.
Say what happens after it. Hourly rate, a small support retainer, or nothing. Any of those is fine; silence is not, because silence means every future request is a negotiation.
Distinguish a defect from a change. Something not working as specified is yours to fix. Something working as specified that they now want different is new work. Agree the distinction while everyone is relaxed rather than during the first request.
Name a contact and a route. Who to email, and what response time to expect. A named person is worth a great deal to a client who has just taken ownership of something unfamiliar.
The documentation that actually gets used
Most handover documentation is written once, is too long, and is never opened. Three principles change that.
Write for the task, not the system. Nobody reads "how the CMS works." People read "how to add a new case study." Organise documentation around the ten things they will actually need to do, in the order they will need them.
Show, do not describe. A short screen recording of adding a page is worth several pages of written steps, and it takes four minutes to make. Written documentation should exist alongside it for searchability, not instead of it.
Assume the reader joined the company after you left. The person who worked with you knows the context; their replacement in eighteen months does not, and they are the reader who will actually need the document. That means expanding acronyms, naming systems in full, and explaining why things are set up as they are.
The test: could someone who has never spoken to you complete the five most common tasks using only what you handed over? If not, the handover is a formality rather than a transfer.
Common handoff failures
Five patterns, each with a specific cost.
Access transferred but not verified. Credentials handed over that turn out to be stale, or that grant the wrong level of permission. The gap between "here are the details" and "I have watched you log in" is where this hides, which is why the session includes a live check.
The recipient leaves. You transferred everything perfectly to one person, who moves on four months later taking all of it with them. Mitigate by inviting whoever will maintain it, not only your day-to-day contact, and by putting the documentation somewhere organisational rather than in one inbox.
Assets delivered as exports only. PDFs and PNGs rather than editable source. The client discovers this the first time they need a change and cannot make one, which is precisely the moment they conclude you built in a dependency.
No support boundary. Ambiguity about what is included generates months of unpaid questions and eventual awkwardness on both sides.
The known-limitations section omitted. The one that feels risky to include. Its absence means the next person to touch the work will make a change that breaks something you knew about, and they will attribute it to you.
What a bad handoff costs
Worth being concrete, because handoffs get skipped on the grounds that the project is finished and unbilled.
Unpaid support. A weak handover produces months of small questions you answer for free because refusing feels petty.
A lost referral. The handoff is the final impression, and it is what gets described to a peer.
A security incident that becomes partly yours. Retained access to a client's systems is a genuine liability.
The next supplier's opinion of you. Whoever picks up the work will form a view within a day and will share it. Agencies get referrals from other agencies more often than they expect, and a clean handover is disproportionately effective at generating them.
No re-engagement. A client who cannot operate what you built either becomes dependent - which sounds commercially attractive and is actually resentment accumulating - or replaces it entirely at the next opportunity.
Handing off to another agency
A specific and increasingly common case: the client is moving to a different supplier, or bringing the work in-house.
The instinct is to do the minimum. Do the opposite, for entirely self-interested reasons.
The incoming team will form a view of you within a day, based entirely on what they receive. That view gets shared - with the client, and in an industry that is smaller than it feels. Agencies refer work to each other more often than most people expect, and a clean handover to a competitor is one of the more reliable ways to generate that.
Offer a call with the incoming team. Thirty minutes, technical, no commercial content. It costs almost nothing and it is remembered.
Do not editorialise about the client or the decision. Whatever the circumstances, the incoming team is not the audience for it, and saying anything makes you the problem in the story.
Document decisions, not just artefacts. The most useful thing you can give a successor is why things are the way they are - the constraint that forced an odd choice, the thing that was tried and did not work. It saves them weeks and it is invisible in the files.
Building the pack in an hour
The objection to all of this is time, and the answer is a template.
Section headings, pre-written. Six of them, always the same, so nobody starts from a blank page.
Standard language for the boilerplate. The support window, the access-removal confirmation, the credential-rotation recommendation. Written once, reused every time.
A per-discipline checklist, pruned to what you actually deliver.
A recording, not a document, for the walkthrough. Twenty minutes of screen recording replaces several hours of writing and is more useful to the recipient.
With those four in place, assembling a handover pack is roughly an hour of genuinely project-specific work - the summary, the known limitations, the credential list. Without them it is a day, which is why it does not happen.
The 30-day check
One short message a month after handover:
Hi Sarah - it has been a month since we handed over. Is everything behaving? Anything unclear in the documentation that I could add to?
Two purposes. It catches the gap in the handover that nobody noticed at the time, which is cheap to fix now and expensive later. And it is a natural, non-salesy point of contact that keeps the relationship warm ahead of the 90-day check-in described in client offboarding.
If the answer reveals something missing, add it to the pack and to the template. A handoff template improves fastest from the questions clients ask afterwards.
Handing over an ongoing retainer
Different from a project handoff and worth treating separately, because there is no natural end point to organise around.
Create the moment. When notice is given, book a wrap-up session immediately rather than letting the final month drift. Without a scheduled event, a retainer simply stops on the last invoice and nothing is transferred.
There is far more accumulated context. A retainer client has had you inside their systems for months or years. The handover pack needs a section on the things you have been quietly maintaining that nobody has thought about since month two - the scheduled job, the certificate, the integration that needs a token refreshing annually.
Document the decisions, not just the state. Why things are configured as they are. On a long engagement this is the single most valuable thing you can leave behind, and it is entirely in people's heads.
Expect the reason to be about value. Retainers rarely end because the work finished. Ask why, honestly, at the wrap-up - the answer is usually about visibility or reporting rather than delivery quality, and it is worth knowing.
The support window in practice
The clause that generates the most post-handover friction, and it is easy to get right.
State a specific duration. Thirty days is common and reasonable. "We'll be around if you need us" is generous-sounding and produces an obligation with no end.
Define what it covers. Answering questions about what you built, and fixing anything that does not work as specified. Not new work, not changes, not fixing things the client altered.
Say what happens after. An hourly rate, a small support retainer, or nothing. Any answer is fine. Silence means every future request becomes a negotiation, usually at an awkward moment.
Distinguish a defect from a change, explicitly. Something not working as specified is yours. Something working as specified that they now want different is new work. Agree this while everyone is relaxed rather than during the first request, when it will feel like you are avoiding responsibility.
Making it repeatable
Three things to build once.
A handoff pack template with the six sections. Turns a day into an hour.
A per-discipline checklist, from the lists above, pruned to what you actually deliver.
A trigger. The handoff session should be created as a task when a project reaches its final phase, with an owner - not remembered. Everything in this guide is easy; all of it falls outside the window when anyone is naturally paying attention, which is why it needs scheduling rather than intending. Same reason the retrospective and the testimonial request need one.
An hour of preparation and a 45-minute session. Against a support tail you are not paid for, a security exposure, and the referral you did not get - it is one of the better returns available in agency operations, and almost nobody does it.