Start with a map of the website
A useful handover lets someone who was not involved in the build answer three questions: what does the website do, who is responsible for each part, and how can the team make a safe change? Begin with a short overview of the site’s purpose, main audiences and most important tasks. For a community organization, those tasks might be finding opening hours, registering for an event and contacting staff. This gives future editors a reason for the choices they see, rather than leaving them to guess.
Record the main pages, navigation structure, forms and connections to other services. Note anything that behaves differently from a standard page, such as an event listing that pulls entries from another system. A simple table can identify each component, its purpose, the person or supplier responsible for it, and where its settings are managed. Keep this map in a location the organization controls, and include the date it was last checked so it can be updated as the site changes.
Confirm ownership and transfer access safely
List the services needed to keep the site running: domain registration, hosting, the content management system, email delivery for forms, analytics, backups and any paid themes or plugins. For each service, document the account owner, billing contact, renewal arrangement and support route. The organization should understand which accounts it owns and which, if any, remain with an agency or contractor. A site may appear complete while still depending on a supplier’s personal account for a critical service.
Transfer access through each service’s account or user-management tools where possible. Give named staff members appropriate permissions instead of sharing one administrator login. Store recovery details and credentials in an approved password manager, not in the handover document or an email attachment. Before the project closes, test that the organization can sign in, receive account recovery messages and reach its domain and hosting settings. Agree when temporary project access will be removed.
Make routine content changes repeatable
Editors need instructions for the work they will actually do. Document how to update common page types, replace a document, publish a news item, edit navigation and review a form submission. Screenshots can help, but pair them with short written steps because interfaces change. Identify which fields are required and what each one controls. For example, explain whether a page summary appears in search results, on a listing page or both.
Include the organization’s content conventions: preferred tone, heading structure, image sizes or cropping needs, alt text guidance and the process for checking links before publication. Clarify who drafts, approves and publishes updates. A small team might decide that one person prepares event details and another checks dates, links and contact information. Save a few completed examples alongside the instructions so a new editor can compare their work with a known-good page.
Record maintenance, measurement and known limits
The handover should distinguish everyday editing from technical maintenance. State who handles software updates, backups, restore testing, accessibility fixes and reports of broken pages. Describe the expected backup location and how to request a restore, without assuming that having backups guarantees an easy recovery. If there is a staging site, explain when to use it and how changes move to the live site. Record any outstanding issues, accepted compromises and planned improvements in a separate, prioritized list.
Document what the organization measures and why. This may include visits to key service pages, completed forms or downloads of an important guide. Name the measurement tools, who has access and where the team can check that a form or event is still being recorded. Avoid handing over a dashboard without explaining what its labels mean or which decisions it supports. If tracking depends on a consent setting or a third-party service, note that dependency too.
Finish with a walkthrough and a test
A handover is complete only when the receiving team can use it. Schedule a walkthrough in which a staff member, not the project supplier, performs a few realistic tasks: update opening hours, publish a draft, find the latest backup status and identify who to contact about a failed form. This reveals missing steps while the people who built the site are still available to answer questions.
After the walkthrough, give the team a single index linking to the site map, editing guide, account inventory, maintenance notes and issue list. Assign an owner to review those materials when services or staff change. The goal is not to document every decision made during the project. It is to leave a clear, secure path for the next person who needs to keep the website useful.
