Who this is for. The agency lead closing a project, and whoever at the client will own the site. Afterwards you have a handover pack to fill in, a training plan by role, and the argument for scheduling both as deliverables.
A site is judged by the people who use it every day after launch, and they were not in the project. If an editor cannot add a page without breaking the layout, if nobody knows which job sends the order emails, if the only person who understood the deploy has left, the site is seen as fragile, however well it was built. Most "something is wrong" messages in the first year trace back to a missing piece of handover, not a fault in the code. That is the case for treating handover as a deliverable, scheduled and reviewed, rather than an email on launch day.
A suggested handover pack
- How the site is built, in one page: the page types and the layout each uses, the component library and when to use each component, the global components, the menus and the content types, each with a screenshot and named the way the admin names it.
- An editor's guide built from the client's own content: creating each page type, image sizes and proportions, scheduling and revisions, the SEO fields, and the short list of things not to do, such as nesting components several levels deep or pasting from a word processor.
- The configuration register: every setting changed from its default and why (settings are shared by every site on the account); every site data key by name, never its value; every job, what it does, its schedule and who relies on it; every form and who receives its submissions; the payment and tax providers and where their credentials are kept; and what Core dna has set in each environment's
.settings.json. Most of this exists only in the database, so if it is not written down it exists nowhere (Code deploys, content does not). - Environments and releases: the environments and their hostnames, which branch feeds which, who may merge to production, how to ask for a hotfix, and the release cadence (A branching strategy that works).
- Operations: the health checks and where their alerts go, the logs and who can open each, and who to contact at the agency and at Core dna, for what, with response times (Health checks worth automating, Where the logs are).
- Governance: the rules for adding third-party tags, the performance budgets, and who owns each (governance).
- Decisions and context: the choices that will look strange later and the reason for each, and anything deliberately left for a later phase.
Access is handed over separately and securely, never in the pack: administrator accounts for named people, and for integrations an OAuth client or, the older option, an API key, passed through a password manager. Remove the agency's own accounts and credentials that are no longer needed at the same time.
Training
| Who | What | How |
|---|---|---|
| Editors | Every page type, components, images, publishing and scheduling, revisions, SEO fields | Hands-on, with their own real content, in short sessions rather than one long one. Remember that staging edits are production edits |
| Administrators | Users and groups, forms and their recipients, redirects, the settings they own, reading the configuration register | A walk-through of the admin, then a task each |
| The client's developers or next agency | The repository, the build, the deploy, environments, the records the code depends on, the logs | A session with the repository open, and the README brought up to date |
Train before launch, so that launch-week content is entered by the people who will maintain it, and again about four weeks after, when real questions have come up. Record the sessions; the next new editor will need them.
Where the pack lives
In the client's own tools, where their team looks, not in the agency's. The developer parts belong in the repository's README and beside the code, where they change with it. Date every document, and review the configuration register at each release, because a register a year out of date is worse than none.