A development handover is successful when someone else can make the next change without reconstructing the project from messages. Repository access is only one part of that. The receiving team also needs to know how the site runs, which decisions matter and where responsibility changes hands.
For an agency, this is a commercial issue as much as a technical one. Every unclear ownership boundary becomes another support conversation between the client, the account manager and the developer.
Start with the next ordinary task
Instead of beginning with a long architecture document, list the first things the receiving team is likely to do. Publish a landing page. Update a plugin. Change a notification recipient. Investigate a failed enquiry. Renew a service subscription.
For each task, identify the tool, access level, procedure and escalation route. This exposes gaps that a diagram alone will miss. An account can exist without anyone knowing who receives its renewal notice or whether access depends on a former contractor's personal email address.
A hypothetical agency handover might include a working repository and deployment pipeline but omit the transactional email dashboard. The website appears complete until the first delivery problem arrives. A short service ownership register would reveal that omission before launch.
Document decisions where they affect future work
Useful documentation explains why a decision exists and what would justify changing it. If a booking integration lives outside the theme, say which responsibilities it owns and what the theme is allowed to assume. If a plugin is retained for one critical workflow, name the workflow and its acceptance check.
Avoid copying large configuration dumps into a document that will become stale. Link to the maintained source where possible. Keep secrets in the agreed credential system and document how authorised people obtain access, rather than embedding passwords in the handover itself.
A compact delivery pack can include:
- A setup guide that has been followed from a clean checkout.
- A service register with named business owners.
- The deployment and recovery procedure.
- The important user journeys and how to check them.
- Known limitations, with their practical consequences.
Make the boundaries explicit
Separate a defect in the delivered scope from a new request, a third-party outage or an ongoing maintenance task. These distinctions should be agreed in the project arrangement and reflected in plain operational language.
For example, a broken form following the agreed launch procedure is different from adding a second CRM destination three months later. A useful handover gives the agency enough information to describe either situation without making an unsupported promise to the client.
White-label work also needs a communication rule. Who can speak to the client, who approves technical recommendations and who explains delays? The answer can vary between projects, but it should not be discovered during an incident.
Rehearse the handover
Ask the receiving developer or agency team to complete one routine change in staging using the documentation. Watch where they need help. Update the guide while the missing context is still obvious.
Then run through a simulated failure: an enquiry does not arrive, a deployment fails or a third-party integration becomes unavailable. The exercise is successful when the team can locate the relevant evidence and contact the right owner. It does not require manufacturing a production incident.
The handover should leave the agency with a maintainable asset and a clear working relationship. That is the standard we aim for in agency development partnerships, from a single build to ongoing engineering support.