Handing Off a Finished Project: Files, Access, Documentation and Sign-off

A handoff is a transfer of responsibility

At the end of a project, the client takes over something you have been looking after: a website, a brand system, a campaign, an app. A good handoff makes that transfer explicit. The client knows what they now own, how to use it, who has access to what and what support, if any, continues after launch.

A rushed handoff leaves those questions open. Months later the client cannot find the logo files, does not know who still has admin access to their site, or assumes that a bug fix next year is included. None of that is the client's fault, and most of it is easy to prevent with a little structure.

This guide describes the handoff as a package with five parts, then sets out the order to deliver them in.

Plan the handoff at the start, not the end

Handoff goes smoothly when it was part of the plan from the beginning. At kickoff, agree:

• Which formats and files the client receives, including whether editable source files are part of the deal.
• Who will own each account you set up or use, such as hosting, domains, analytics or social profiles.
• What support follows launch, for how long and what it covers.

During the project, keep a running list of every account you were given access to and every third-party asset you used, such as fonts, stock images, plugins and licenses. Reconstructing that list at the end is slow and error-prone.

The handoff package

Think of the handoff as five things the client receives:

1. Final files
2. Access and credentials
3. Documentation
4. A recorded sign-off
5. Post-launch terms

1. Final files

Collect the final deliverables in one clearly named place, separate from work in progress. For each one, the client should be able to tell what it is and when to use it.

• Formats for everyday use and, where agreed, editable source files.
• Variants the client will need, such as logo versions for light and dark backgrounds or image sizes for different placements.
• License information for fonts, images, icons or code you did not create, including who holds the license and any restrictions on use.
• A short index listing each file and its purpose.

Remove drafts, rejected options and internal notes from the final set. If the client wants the history of the project, it already exists in the earlier versions and approvals.

2. Access and credentials

This is the part of a handoff with the most potential for lasting problems, because access tends to outlive the project.

Work through your access list and, for each item, do one of the following:

• Transfer ownership to the client, if the account was created in your name on their behalf.
• Remove your own user from accounts the client already owns.
• Change the credential if it was shared with you, and give the new one to the client.

The OWASP Secrets Management Cheat Sheet recommends rotating secrets regularly so that a leaked credential stops working quickly. The end of a project is a natural point to do this for API keys, service accounts and shared passwords.

When you do need to pass a credential to the client, send it through a password manager that supports secure sharing, and keep it out of email, chat and the handover document. The National Cyber Security Centre's guidance on managing passwords recommends password managers and turning on two-step verification, and it is worth suggesting both to the client for any account they now own.

Keep a written record of what you transferred, changed or removed, and when. It answers the question "who still has access?" if it comes up later.

3. Documentation

The handover note is what the client reads when you are not there. Write it for the person who will look after the work day to day, who may not have been in any of your meetings.

A structure that works for most projects:

• What was delivered. A short summary of the work and the final deliverables.
• Where everything is. Locations of files, accounts and any related services.
• How to do common tasks. For a website, this might be editing a page, adding a blog post or updating contact details. Keep each one to a few numbered steps.
• What to avoid. Settings or files that should not be changed without help.
• Known limitations. Anything deliberately left out of scope, and anything that will need attention later, such as a license renewal date.
• Accessibility notes, for web projects. If you designed or tested against the Web Content Accessibility Guidelines published by the W3C, say which version and level, and give the client simple rules for keeping new content accessible, such as writing alt text for images.
• Who to contact for questions during the support period.

Do not include passwords. Reference the password manager entry instead.

4. A recorded sign-off

The final approval confirms that the client accepts the finished work. It should point to the final version of each deliverable, not to a description of it.

Request it the same way as any other approval in the project, with the version, what you are asking them to confirm and a respond-by date. If you used a staged approval process, the final sign-off should be short: earlier approvals already cover direction, structure and design, so this one confirms that the delivered whole matches what was agreed. The design approval workflow article covers how to set up those stages.

In Ayebridge, you can request approvals on the final file versions, or on a deliverable described in text such as "launched website and handover documentation". Every decision is stored with the person's name, the version and the date, and your team can export the approval record as a PDF to keep with the project files or attach to a closing email.

5. Post-launch terms

Clients often assume that support continues indefinitely. Make the terms clear in writing:

• The support period, if one is included, with start and end dates.
• What counts as a fix (something that does not work as delivered) and what counts as new work (changes or additions).
• How to ask for help, and the response time you can offer.
• What happens after the support period, for example an hourly rate or a separate maintenance agreement.

The handoff sequence

The order matters. Sign-off before access transfer means the client accepts work they can still check with your help; access transfer before the final update means the update can confirm it is done.

1. Freeze the work. Agree that no further changes go into the deliverables except fixes found in final review.
2. Final review. Walk the client through the finished work, ideally in a short call, and note any last fixes.
3. Make the fixes and upload the final versions.
4. Request final sign-off with a respond-by date.
5. Transfer access and credentials, following your access list.
6. Deliver the documentation and the file index.
7. Post a closing update that summarizes everything above.
8. Archive the project once the support period ends or the client confirms they have everything.

Write the closing update

The closing update is the last entry in the project history and the first thing anyone will read if they come back to it later. Post it where the rest of the project lives. In Ayebridge, that is the project's updates timeline, which the client sees in their portal.

A template:

Project complete: [project name] The final deliverables were approved by [name] on [date]. You can find them in the Final deliverables folder, along with the file index. Access: ownership of [accounts] has been transferred to you, and our access to [accounts] has been removed. Shared passwords were changed on [date] and sent through [password manager]. Documentation: the handover note is in the same folder. Support: fixes for anything that does not work as delivered are included until [date]. To report an issue, [how to contact]. Thank you for working with us.

After the handoff

• Check in once, a few weeks after launch, to ask whether anything is unclear. Questions at this point often reveal gaps in the documentation worth fixing for future projects.
• Keep your records: the approval export, the access log and the closing update. They take little space and answer most later questions.
• Review your own process. Note what took longest to assemble and start collecting it earlier next time.

Project handoff checklist

• Final files collected in one place, with formats, variants and a file index
• License details for third-party assets included
• Drafts and internal notes removed from the final set
• Every account on the access list transferred, removed or changed
• Credentials shared through a password manager, never in email or documents
• Access changes recorded with dates
• Handover note written for the person who will maintain the work
• Final approval requested on the final versions and recorded
• Post-launch support terms stated in writing
• Closing update posted
• Project archived when support ends

A careful handoff takes a day or two of focused work. It is also the last impression the client has of the project, and often the one they remember when the next piece of work comes up.