Project handover checklist for freelance client work

Handover makes delivered work usable by someone else

A project handover transfers the outputs, knowledge and day-to-day responsibility needed for a client to use the work without relying on your memory. Start with an inventory, name the receiving owner for each item, demonstrate essential tasks and record any unresolved operational questions. Sending a folder is only one part of that transfer.

OnlinePMCourses describes handover as moving project outputs into beneficial use and routine maintenance. Its guidance emphasizes preparation by both the project team and the receiving operational team. For a freelancer, that might mean one client contact successfully opening the source files and another taking responsibility for a website account, rather than a large formal transition programme.

Keep delivered, accepted and paid as separate states

Delivered means the identified output has been supplied. Accepted means an authorized reviewer has made the relevant decision about that version. Paid means money has been received and allocated to the financial record. A client downloading a file does not establish all three, and a paid invoice is not delivery acceptance.

Reference the existing acceptance decision instead of inventing new approval criteria during handover. If something remains under review, say so and explain whether it prevents operational transfer. Follow the agreed delivery and ownership terms; the checklist itself does not change intellectual-property rights, licensing restrictions or payment conditions.

Handover also differs from offboarding. This guide asks whether the recipient can operate the work. Offboarding asks whether the engagement has been administratively closed, with financial records reconciled and ongoing responsibilities documented.

Build an inventory that a receiving owner can follow

Use one row per meaningful output or system, not one row for every tiny file. Link the exact version and distinguish editable sources from exported deliverables. Avoid names such as “final-final” when a version identifier and delivery date would resolve the ambiguity.

Copyable inventory fields: item; version; location; supplied formats; receiving owner; permitted use or licence reference; required software or account; operating instructions; transfer evidence; open issue and action owner. The evidence might be a confirmed download, successful account invitation or a completed practice task.

1. Match the inventory to the agreed deliverables and approved changes; identify omissions rather than silently replacing them.
2. Check that links open for the intended recipient, not only for your administrator account.
3. Include the source files, exports and documentation actually promised, with any third-party restrictions visible.
4. Assign ownership of renewals, backups, maintenance and updates where those activities apply.
5. List unresolved issues separately with their impact, temporary arrangement, owner and next decision date.

Transfer access without transferring your personal identity

Prefer named client accounts and the service provider’s supported ownership-transfer process. Confirm the recipient through an established contact channel before changing privileged access. Do not put passwords, recovery codes or secret keys into the general handover document, an ordinary email thread or a meeting recording.

The client should control its own recovery address and authentication methods. Where a secret genuinely must be transferred, use an agreed secure method and plan any necessary rotation. Check integrations before rotating a key: removing your credential may stop an automation unless a client-controlled replacement is installed first.

Document who can authorize the eventual removal of your access and when it should occur. Test the replacement owner’s ability to administer the system before removing the only working administrator. Any temporary support access should have a defined purpose, appropriate permissions and a review or end date, not an indefinite invitation.

Worked example: handing over a workshop resource library

In this fictional example, freelancer Owen has built a small resource library for a training business. The agreed package contains a published library, editable session worksheets and an operating guide. Client coordinator Leena owns content updates; operations contact Marco owns the hosting account and renewal reminders.

The record says: “Library release 1.0 supplied October 9; worksheets version 3 supplied in editable and PDF formats; guide version 1 linked in the client folder. Leena confirmed that both worksheet formats open. Marco confirmed administrator access from his own account. Acceptance: recorded separately against release 1.0. Payment: final invoice outstanding under its agreed terms.”

The transfer session takes 35 minutes: 5 to locate the inventory, 15 for Leena to add and remove a practice resource, 10 for Marco to check account administration and recovery settings, and 5 to confirm support contacts. The 5 + 15 + 10 + 5 allocation is an illustrative agenda, not a standard duration.

Marco discovers that renewal notices still go to Owen. The item remains open with Marco as owner until the address is changed and confirmed. That specific exception is more useful than calling the entire handover complete because everyone attended the meeting.

Teach the tasks the client will actually perform

Choose the small set of routine and recovery tasks that matter for this deliverable. For a design package, demonstrate editing text and exporting the agreed format. For a website, show a safe content update and explain who handles recovery if something breaks. Avoid promising recovery procedures that were never configured or tested.

Let the recipient perform the task while you observe. A recording of you doing everything does not show that their permissions, software and understanding are sufficient. Record a short guide or session only with appropriate agreement, keeping personal information and secrets out of the capture.

Place instructions beside the inventory and name their version. Explain known limitations and escalation routes plainly. The client should not have to search your private chat history to discover that a licensed font, subscription or external provider is needed.

Draw a clear boundary around post-handover support

Refer to the agreed support terms: covered work, excluded changes, reporting channel, service hours and any end date. Separate acknowledgment expectations from resolution commitments. Receiving a support request within a day is not a promise to fix every problem within a day.

For Owen’s fictional project, the handover note refers to an already-agreed ten-calendar-day question period beginning October 10 and ending October 19, inclusive. It covers questions about the supplied operating guide; new worksheets require a separately agreed scope. This is a chosen example arrangement, not a default warranty or a limit on any legal rights.

End with a dated record of what transferred, what the recipient demonstrated and what remains open. If an important operational dependency is unresolved, name the temporary owner and next action instead of claiming an unconditional transfer. Then use the offboarding checklist for the administrative close.