In this article
Illustrative photo by Zulfugar Karimov / Unsplash.
Client offboarding is the handoff between finishing your assignment and the client taking responsibility for the delivered work. Confirm what is being delivered, who can use it and what happens to your access. This operational checklist helps make the transition explicit; it is not a contract or a legal retention policy.
Agree what completion means
Return to the agreed scope and compare it with the deliverables. List anything still unresolved and identify who owns the next action. Do not describe the project as complete if an essential item is still awaiting review.
For an illustrative website copy project, the package might contain three approved page drafts and a short publishing note. Editable files should be included when the agreement calls for them; offboarding is not the moment to assume that every working draft or internal file belongs in the delivery.
Create a delivery index
Use a small README or delivery document listing each final item, its format and location. Mark the approved version clearly and explain any dependency the client will need, such as a font license or an account they control.
Ask the recipient to open the delivered files and confirm access. Sending a link is not proof that the client can use it. Check permissions from their perspective where possible and provide the agreed format rather than assuming that they own the same applications you do.
Transfer control without leaving hidden dependencies
Identify accounts or assets that still depend on your personal email, storage or subscription. Agree how the client will take control before removing your own access. Use supported ownership transfers or invitations where available, and avoid placing passwords or secret keys in the delivery document.
Have the account owner confirm that an appropriate administrator remains and that recovery information is under their control. For technical systems, record which person will handle any necessary credential rotation and verification. Removing an account prematurely can interrupt the client’s operation.
Separate access removal from data retention
Your need for continued login access and your obligation to retain or delete records are different questions. End temporary access according to the agreed handoff. Separately, check applicable obligations and the agreement before deleting or retaining client material.
If continued support is agreed, document its scope and review date. Do not keep broad administrative access merely because it might be convenient later. Where the correct retention treatment is unclear, obtain appropriate advice instead of making deletion an automatic checklist action.
Use a final handoff record
Project and client contact: Agreed deliverables and locations: Client confirmed files open: Outstanding items and owners: Accounts transferred and verified: Temporary access removal owner/date: Retention decision and basis checked: Ongoing support, if agreed: Closure confirmation:
A short walkthrough can help the client understand how to use the work. Explain where the final files are, what needs maintaining and who handles future questions. Avoid promising support that was never included in the assignment.
Send a closure message with a clear next step
An example is: “The approved files are at [location], and the delivery index explains each item. Please confirm you can open them. The remaining action is [item and owner]. My project access will end on [agreed date] once the handoff is verified. Future requests can be sent through [channel].”
Replace the placeholders and keep only commitments that match the engagement. Save the acknowledgement with the project record. Afterward, note any confusing part of the handoff and improve the checklist for the next client.
