A project is not fully handed over when the final presentation looks good. The customer needs the files, access and instructions required to use the work after the delivery team leaves. A missing source file may be a small inconvenience today and a costly reconstruction later. A publishing account controlled by the wrong person can make a routine update unexpectedly difficult.
Use this operational checklist for a defined project involving brand materials, a website, content or a configured system. It is not a compliance audit, and it does not replace the agreed contract or the current instructions for a particular platform. Begin before the last week. Ownership and access are easier to arrange while the people who created the work are still available.
1. Create an inventory the recipient can follow
List every deliverable in the agreed scope and the place where the final version will live. Give each item a recognizable name. A folder called “final assets” is not enough if it contains several contradictory versions. The inventory should tell a new person which file to use and what it is intended for.
Separate final outputs from working material. A published image, an editable design file and a reference image serve different purposes. Mark drafts clearly or move them to a separate archive. The customer should not need to reconstruct the project’s history to find the approved logo or the current campaign copy.
Add a status for each item: ready, awaiting approval, excluded by agreement or still to be delivered. Keep unresolved work visible. A handoff can include an open-item list, but it should not imply that outstanding work has disappeared. Assign an owner and a next action to anything unfinished.
2. Confirm the account owner, not just the login
For each service used in delivery, identify the legal or administrative account owner, the billing contact and the people with access. A person who can sign in may not be able to change ownership or recover the account. Have the intended customer administrator verify the permissions that matter for ongoing use.
Use supported invitations and ownership-transfer methods instead of sharing passwords in a general document. Review recovery details and authentication arrangements within the platform’s own controls. The customer should be able to maintain access if a staff member or supplier leaves. Do not include secrets in a handoff inventory that will be distributed broadly.
If a code repository is included, check the destination organization and transfer requirements. GitHub’s repository transfer documentation describes permissions and consequences that need attention. Other platforms have their own rules, so use the current official instructions for the actual service rather than assuming every transfer works the same way.
3. Check brand files in the formats people need
A brand handoff should reflect how the business will use the identity. The customer may need an editable vector logo, common image exports, color values and a short explanation of suitable variants. Test a sample in the intended context, such as a presentation or website header. An impressive preview does not prove the exported file is usable.
Record font names and licensing arrangements. If a typeface or photograph requires a separate license, explain what the customer needs to obtain and what rights are already covered. Avoid treating possession of a file as proof of permission to use it everywhere. The engagement should make ownership and third-party rights understandable.
Include a small usage guide when the scope calls for it. Show which logo works on a light background, which works on a dark one and what should remain unchanged. Keep the guidance proportional to the project. A few clear examples may serve a small business better than a long document nobody will consult.
4. Verify the live experience from the customer’s side
For a website or configured system, test the journeys the customer expects to use. Open the site on the agreed device types, follow the primary navigation and check the relevant forms using an authorized test method. For a business system, run through a representative task with the intended user permissions.
Do not test only from the supplier’s administrator account. That account may have access ordinary staff lack. Ask the customer’s designated user to perform the task while the delivery team observes. Record any missing permission, unclear label or undocumented step. The review should reveal whether the handoff works for the person who will actually receive it.
Make the results specific. “Website checked” is less useful than a dated record of the journeys tested and any known limitations. If a third-party integration cannot be verified yet, state that and assign the remaining check. A visible limitation is manageable; an assumed success can sit unnoticed until the customer needs the feature.
5. Provide instructions for ordinary maintenance
A handoff guide should answer the questions likely to arise in the first month. How is a page edited? Where are approved images stored? Who renews the relevant subscription? What should staff do if an expected report does not arrive? Organize the guide by task rather than by the order the supplier performed the work.
A short screen recording can help, but written steps remain useful for scanning and updating. Label recordings with the task and date, and make sure the customer can access them without the supplier’s personal account. If the interface changes often, point to the platform’s official help material alongside any project-specific explanation.
Distinguish routine maintenance from specialist changes. A customer may be comfortable updating text but need help altering a custom integration. The guide should identify that boundary and the information a future provider would need. It should not make the customer dependent on an undocumented piece of knowledge held by one person.
6. Agree on the support window and open issues
The final conversation should cover what happens after delivery. State how corrections are reported, what is covered by the agreed support arrangement and when that arrangement ends or changes. New requests should have a separate route. The customer needs to know the difference between reporting a defect and commissioning an additional feature.
Review the open-item list together. A delayed customer approval, a platform limitation and an unfinished supplier task are different situations. Record each accurately, with an owner and an expected next step. Avoid a single “pending” label that hides who needs to act.
If training is part of the engagement, check who attended and where the material is stored. Someone absent from the final call may become the main operator later. The handoff should contain enough information for that person to begin, or clearly state what further training would be needed.
7. Review access and keep a final record
Once the customer has confirmed ownership and usability, review supplier access according to the agreed arrangement. Remove access that is no longer needed, retain only what ongoing support requires and document the reason. The customer should know which outside parties can still reach its systems after the project is closed.
Save the inventory, acceptance record, open issues and maintenance instructions in a customer-controlled location. Confirm that someone other than the original project contact can find them. That small check protects the handoff against ordinary staff changes and busy schedules.
Finally, hold a short review of the delivery itself. Atlassian’s project post-mortem template provides a structure for recording lessons. Note what was hard to find, which permissions caused delays and what should be arranged earlier next time. The result should be a better delivery routine, with the next customer receiving a clearer, more usable package from the start.