1. Complete an everyday update
Take an illustrative business website with services, product pages and a contact route. Choose a routine change, such as updating the phone number. The person responsible signs in with their own account, finds the content, makes the change, checks the preview and publishes it using the supplied instructions.
Then check the number on a computer and a phone, including the tap-to-call link. Record where the process stops: a missing permission, an unclear instruction or duplicated content. This establishes how independently your team can work. If the supplier will handle updates, agree how to request, approve and price them instead.
2. Identify who controls each service
Create a short account inventory. Each service needs a named contact, a verified access route and a renewal date. The domain, email and hosting may have different administrators. Completing the website should also leave responsibility for email clearly assigned.
Record the agreed way to transfer access, keeping passwords and secret keys out of the handover document and source files. Where available, use individual invitations and permissions appropriate to each role, following OWASP’s credential management guidance.
| Item | Check to complete |
|---|---|
| Domain | Registrant account, renewal and contact for configuration changes. |
| Hosting and services | Administrator, active plan, renewal and payment arrangements. |
| Content and images | File location, origin and usage terms to consult. |
| Email and enquiries | Recipient for enquiries and an agreed delivery check. |
3. Receive source files you can actually use
Agree what is transferred: editable code, original images, configuration files without secrets, instructions and tool versions. Ask for the delivered version to be rebuilt in a separate environment using those instructions. Any step known only to the developer needs documenting.
A repository copy does not automatically cover every connected service. GitHub’s backup guidance distinguishes, for example, repository content, large files and other project data. Your inventory should identify where editable content, uploads and databases live, if the project uses them.
4. Test returning to an earlier version
In a test environment, publish a small change and restore the agreed version. Record the visible result and who can perform the operation. Some hosting services provide dedicated controls: Cloudflare Pages, for example, can restore a previous production deployment.
For a web application, test data recovery separately. Restoring code does not demonstrate that enquiries, attachments or user edits have been recovered. Agree which data needs backing up, how frequently and what potential loss interval is acceptable. Verify the recovery procedure using test data.
5. Define work after handover
Summarise recurring costs and ongoing responsibilities on one page. Separate corrections covered by the proposal from new features. Name the person responsible for updates, the support channel and the agreed response arrangements. A general statement that “maintenance is included” leaves too much open to interpretation.
- Which services renew, and who receives the reminders?
- Who checks enquiry delivery after an update?
- Which changes need a separate quote?
- How will files and access be handed over if the supplier changes?
6. Close with a checkable handover record
Keep the record short: version and date, received materials, completed checks, unresolved points and a responsible person for each. Link every issue to a reproducible example and the agreed decision. This checklist can help define deliverables at the quotation stage; adapt it to the project’s actual features.
Explore an example
ImportGuard is a demonstration project using synthetic data. You can inspect its source code, instructions and checks. It is a limited example of handover materials that can help you ask specific questions about a different project.
Explore the ImportGuard materials ↗Prepare your project brief
A reusable text template: objectives, users, features, materials and acceptance checks. Download it without registration and edit it with your team.
Download the project brief (.txt) ↓Technical references
Published by Ospivia Studio, prepared with AI assistance and checked against the linked technical sources. Examples are illustrative and are not customer results.