Project Handover Template for Freelancers

A project handover template records what you have delivered, where the client can find it, what they have accepted and who owns any unfinished work. For a small freelance project, I would use one shared record plus a short handover email. Sending a folder is only one step: the client also needs the right access, instructions and support expectations.

Download the free project handover template

No signup is required. Open the editable text file or paste it into your usual document tool. It contains the handover record, a completion checklist and an email you can adapt. This guide is for freelance service delivery, such as copy, design or a small website project; it is not a construction, safety-critical or regulated project sign-off procedure.

What to include in your handover document

Start from the scope and terms already agreed, rather than inventing new conditions at the end. The onboarding checklist prepares the project to start; this record helps the client take responsibility for its outputs.

For each deliverable use: item | version/location | recipient | access checked | acceptance status | next action. Write “not applicable” where appropriate. Do not fill a record with account details simply because the template has an access section.

Keep delivered, accepted and paid separate

A deliverable can be sent but not yet reviewed. It can be accepted while the invoice is still within its agreed payment period. Payment may also arrive before the final delivery. I would track all three states explicitly instead of compressing them into a single green “done” label.

• Delivered: the agreed item has been made available to the intended recipient in the agreed form.
• Accepted: the decision required by your agreed process is recorded. An email saying “received” may only acknowledge delivery.
• Paid: the actual payment has been reconciled against the invoice, rather than merely requested.

Check the contract checklist if your acceptance or payment process is unclear. Do not add a new silence-means-acceptance rule in a handover email. If the client does not respond, follow the agreed process and record the unanswered request.

Worked example: handing over website copy

This is a fictional example, not a client result or a suggested market rate. A UK freelance writer has agreed a £600 two-page website-copy project, with one consolidated revision round. The example assumes the writer is not VAT registered. £300 has been paid upfront; the remaining £300 is due seven calendar days after final delivery, as agreed before work began.

The approved scope includes editable copy and a clean reading copy. Website publishing and future marketing are excluded. At handover, the writer records:

The accurate conclusion is delivered, awaiting acceptance and balance payment. The writer should not call the whole project accepted or overdue. Nor does an excluded publishing task become unfinished freelance work simply because the client has not published the pages.

If the client now requests a third page, record a new scope request. If the delivered file has the wrong approved company name, assess it as a correction against the existing brief. The distinction is what was agreed, not whether the request arrives after handover. Use the client-boundary scripts to discuss extra work clearly.

Check files, accounts and instructions before you leave

Ask the recipient to open the final files using their own account. A link that works for you may rely on permissions the client does not have. Keep a simple file list with clear version names; remove superseded drafts from the final-deliverables folder without deleting records you still need to retain.

For a website or other account-based project, identify who controls the subscription, billing, domain, recovery method and ongoing administration. Use the service’s supported transfer or invitation process. Avoid moving an entire personal account when only a project or permission needs to change, and do not paste passwords, recovery codes or API keys into the handover document.

Agree when your access ends. Confirm the client has appropriate control before removing your access, and keep any continuing support access limited to the agreed job. If a transfer is blocked, record the specific dependency and owner instead of announcing a complete handover.

Instructions should cover the tasks the recipient will actually perform: where to edit content, which file is print-ready, what needs renewing, how to request help and what the project does not include. One concise walkthrough may be enough for a simple deliverable. Do not promise training or maintenance that was never part of the scope.

Clarify usage rights and retained client information

Delivering editable files and transferring copyright are different matters. The Intellectual Property Office explains that a commissioned creator is generally the first copyright owner unless otherwise agreed in writing. Record the actual licence or ownership arrangement and any third-party asset restrictions; the handover template does not itself assign rights.

Check font, stock-image, plugin and other third-party terms where they affect the client’s intended use. Do not promise that every supplied asset can be reused without restriction. Ask separately before publishing client work in your own portfolio case study.

Where you act as a processor of the client’s personal data, follow the agreed processing contract and the client’s documented instructions. The ICO’s contract guidance requires end-of-contract terms for return or deletion at the controller’s choice, with existing copies deleted unless UK law requires storage. Keep any necessary business records under their appropriate retention rules; do not promise indiscriminate deletion of every project record. Get appropriate advice if responsibilities or retention duties are unclear.

A project handover email you can adapt

Subject: [Project] handover: files, review and next steps

Hi [name],

The agreed [deliverables and version] are available here: [link].
The handover record lists the files, access, instructions and open items: [link].

Please confirm you can open the files, then [specific review action]
by [agreed date], using [agreed acceptance process].

The remaining items are [item, owner, next action and date], or none.
The following work is outside this handover: [relevant exclusions].

The payment position is [accurate status], with [invoice reference]
due [agreed due date]. Included support is [scope] until [agreed date].
For anything additional, contact me so we can agree the work first.

My access will [agreed access action and timing], once [dependency].
Please tell me if any file or access does not work.

Thanks,
[name]

Replace every bracketed prompt. Omit irrelevant fields, and match dates to the actual agreement. For a missing payment after its due date, use the separate overdue-invoice emails; a delivery note is not a substitute for an accurate payment record.

When is the handover complete?

I would close the operational handover when the agreed deliverables and instructions are available, access works, required acceptance is recorded and remaining responsibilities are explicit. If a material gap prevents the client from using the work, keep that item open. If an agreed later action remains, identify its owner and date rather than hiding it in a completed checklist.

A shared document and folder are usually enough for a small project. Use your existing project system if several people need to update owners, deadlines or versions; buying a new tool solely to send this template is unnecessary. Keep invoice follow-up separate through your invoicing process, and review actual project time using the billable-hours record before quoting similar work again.

Spot something that needs correcting? See the corrections process.