Four months after a project ended, a client emailed my team asking for the admin password to a system we'd built for them. The person who had run the integration on their side had left. Nobody remembered which email address the account was under. The developer who'd set it up had rolled off to another client and was on leave.
We sorted it out in a day. But that day cost us money we'd never bill, and it cost the client a week of confidence in a system that was working perfectly.
That email is the most common message an agency gets after a project closes. Not a complaint. Not a bug. A request for something that should have changed hands months earlier and quietly didn't.
Before starting Scopeyard, I spent years running a product development studio and delivering AI automation projects across healthcare, recruitment and operations. Almost every "the vendor didn't deliver" story I've heard from the client side was actually a handover failure. The work was fine. The transfer wasn't.
Industry research puts a number on it: roughly 60% of project benefits fail to materialise fully because of poor transition planning, weak knowledge transfer, or insufficient operational readiness, and only about 37% of organisations say they manage knowledge transfer adequately at all. Your delivery can be excellent and still land in that 60%.
Handoff Quality = Documented System + Transferred Access + Named Owner + Confirmed Acceptance
Miss any one of those four and the project isn't finished, whatever the invoice says.
1. Start the handoff at kickoff, not in the last week
Most agencies collapse the entire handover into the final 48 hours, then wonder why it feels rushed and why the client keeps coming back.
The fix is boring: treat handoff as a phase with its own dates, not an event at the end. Split it into three.
| Phase | When | What happens |
|---|---|---|
| Prepare | T-30 days | Name the receiving owner on the client side. Audit accounts and credentials. Start the runbook. Book the training session. |
| Transfer | T-7 to T-0 | Walk through the system live. Move ownership of accounts. Deliver documentation. Get written acceptance. |
| Stabilise | T+1 to T+30 | Warranty window. Named contact for questions. One check-in call. Then it ends, formally. |
The highest-leverage item there is naming the receiving owner at T-30. Not "the marketing team". A person, with a name, who knows they're inheriting this and has time blocked to receive it. If the client can't name that person, you've found the real project risk, and you've found it while there's still time to do something about it.
I have never regretted asking that question early. I have repeatedly regretted not asking it.
2. Transfer ownership, not just access
This is the one that bites. There is a difference between the client being able to log in and the client owning the account.
If the domain is registered under your agency's email, if the cloud project sits in your organisation, if the API keys are on your billing card, then you haven't handed over a system. You've handed over a dependency. And you're carrying liability for infrastructure you no longer maintain.
Go through it item by item:
| Category | What actually transfers |
|---|---|
| Domains and DNS | Registrar account ownership, not just DNS records |
| Hosting and cloud | Billing owner moved to client, agency downgraded to a named collaborator or removed |
| Repositories | Repo ownership moved to the client organisation, including CI secrets and deploy keys |
| Third-party services | Analytics, email, payment, CRM — ownership reassigned, agency seats removed |
| API keys and model access | Rotated after transfer, not just shared. Assume anything shared over Slack is compromised |
| Design and source files | Editable originals, not exports. Fonts and licence records included |
| Intellectual property | Written confirmation of what the client owns, what is licensed, what stays yours |
That last row is where agencies get sloppy and where disputes start. Your contract says something about IP. Restate it in plain English in the handover document, specific to this project: the client owns the custom code and the brand assets; the component library you brought in is licensed to them for this product; the internal tooling stays yours. Nobody argues about a sentence they read and approved at handover.
Rotate credentials once the transfer completes — not out of distrust, but because it's the only clean line between "we had access" and "we don't".
3. Write the runbook, not the documentation
Documentation is what you write to prove you documented. A runbook is what someone opens at 9pm when something is broken.
The distinction matters because the expertise you're transferring is mostly tacit — the unwritten knowledge that sits in your team's heads is commonly estimated at 80% or more of what an organisation actually knows. You will never write all of it down. So write down the part that gets used.
A runbook that earns its place answers, in this order:
- How do I do the five things I'll do most often? Add a user. Change the copy on this page. Export the monthly report. Pause the automation. Update the pricing.
- What breaks, and what do I do first? The three or four realistic failure modes, with the actual first step. "If the sync stops, check the queue at this URL. If it shows red, retry from here."
- What costs money? Which services bill, on whose card, at roughly what monthly rate, and what makes the bill go up. For AI projects this is not optional — token spend surprises people.
- Who do I call? Your support contact, the client's internal owner, and any third-party vendor, with escalation order.
- What did we decide and why? A short decisions log. This is the one clients thank you for two years later, when someone new asks why the system works that way.
Record the walkthrough. Thirty minutes of your lead actually operating the system beats 40 pages of prose and takes half an hour to produce. Store it with the documents, not in someone's inbox.
For automation work, the runbook and the maintenance agreement are two halves of the same conversation — see what to include in an AI maintenance contract.
4. Get acceptance in writing, per deliverable
"They stopped replying, so I assume we're done" is not acceptance. Neither is a thumbs-up in a group chat six weeks before launch.
Formal acceptance does three things. It starts the warranty clock. It ends the drift of small extra requests. And it makes the final invoice uncontroversial, because the client has already said in writing that the thing was delivered.
Keep it lightweight, but keep it specific:
- Acceptance is per deliverable, not one blanket sign-off at the end. Blanket sign-offs get held hostage by the one item nobody has reviewed.
- Every request names what's being accepted, what to check, and by when.
- Silence has a defined consequence, agreed at contract stage. Five working days, then it's accepted. Enforce it politely.
- Open items get logged with owners and dates, not folded silently into "post-launch".
If your mid-project reviews are already sharp, handover acceptance is just the last one. If they aren't, fix that first — a better client review process is the upstream version of this problem, and slow approvals are already costing you cash flow whether or not you've measured it.
5. Decide what happens on day 31
Every project has a support cliff. The question is whether you designed it or fell off it.
Three defensible options, and one that isn't:
| Model | What it means | Best for |
|---|---|---|
| Warranty then stop | 30 days of bug fixes at no charge, then the relationship ends unless renewed | One-off builds, clients with real in-house capability |
| Warranty then retainer | Warranty rolls into a named monthly scope at a fixed fee | Systems that need monitoring, most AI and automation work |
| Warranty then blocks | Prepaid hours the client draws down, expiring quarterly | Clients with irregular, unpredictable needs |
| "Just message me" | An open-ended, unpriced, unbounded obligation | Nobody |
The fourth row is what most agencies actually do, and it's the reason so many teams carry 10–15% of a delivery person's week in unbilled goodwill.
Retainers have become the norm rather than the upsell — Promethean Research's 2026 survey found 78% of digital agencies now use them, up from 64% in 2023 — and handover is the natural moment to propose one, because the client has just watched you transfer a working system and is acutely aware of what they now have to run alone. The broader version of that decision is when an agency should move from projects to retainers.
Price the ongoing scope before the handover call. Walking in with a number is a proposal. Promising to "send something over" is a maybe.
6. Do the commercial half of the handover
Handover isn't only operational. It's the highest-trust moment you will ever have with this client, and most agencies waste it by treating the last day as admin.
Referrals are still the top source of new business for digital agencies — SparkToro's industry survey found around 66% naming existing and past clients as their main referral source — and referred clients tend to stay significantly longer than ones acquired through other channels. That pipeline is built in the week after launch, not in a quarterly email campaign.
So run the commercial track alongside the technical one:
- Ask for the testimonial while the result is fresh. Two weeks after launch, not two quarters. Give them a draft to edit — people will approve a good paragraph they'd never write from scratch.
- Ask for the referral specifically. "Who else do you know dealing with the problem we just solved?" beats "let us know if you hear of anything" by a distance.
- Book the results review for 60 days out. It's a genuine service and the most natural second-project conversation you'll ever have.
- Do an internal retro. What was underestimated, what the client struggled with, what you'd price differently. Feed it into your estimates.
Handover is also where the record of the project earns its keep. When approvals, deliverables and sign-offs live in one place instead of scattered across email threads, the handover pack is mostly assembled already — that's the problem Scopeyard was built to solve, so the last week is a transfer rather than an archaeology exercise.
7. The checklist, in one place
Steal this, adapt it, make it part of your delivery template rather than something you rebuild every time.
T-30
- Receiving owner named on the client side, by name
- Account and credential audit complete
- Runbook started, walkthrough recording scheduled
- Ongoing support model priced
T-7 to T-0
- Live walkthrough delivered and recorded
- Ownership transferred: domains, hosting, repos, third-party services
- Credentials rotated, agency access removed or downgraded
- IP and licence position confirmed in writing
- Runbook, decisions log and source files delivered
- Written acceptance obtained per deliverable
- Open items logged with owners and dates
- Final invoice issued
T+1 to T+30
- Warranty terms and end date confirmed in writing
- One check-in call held
- Testimonial requested
- Referral asked for, specifically
- Results review booked for T+60
- Internal retro run, estimates updated
- Support model signed, or the relationship formally closed
Final thoughts
The reason handover gets skipped is that it happens at the exact moment everyone is tired, the invoice is nearly out, and the next project has already started. It feels like tidying up. It isn't. It's the last thing the client experiences, and it's the thing they'll describe to the next person who asks about you.
An agency that hands over badly is renting its reputation. An agency that hands over well gets paid twice for the same project — once by the client, and once by whoever they send you.
Finish the project properly, or you haven't finished it.