The site is live, the invoice is paid, and the developer sends a folder called “final.” Three months later, a domain renewal notice goes to an account nobody in the business can access.
A handover should make it possible for an authorized person to operate the system. That requires more than source files. Ownership, access, billing, recovery and day-to-day procedures all need an explicit destination.
Treat the handover as a deliverable from the start of the project. It is easier to agree account ownership before accounts are created than to untangle it after launch.
Start with an ownership register
List the domain registrar, DNS provider, source repository, hosting account, email service, database, backups and any paid third-party tools. For each one, record who owns it, who can administer it, where renewal notices go, and how access is recovered.
Use business-controlled accounts where appropriate, with individual access for the people who need it. Shared passwords in a handover document make it harder to know who still has access. Keep credentials in an approved password manager and document the access process separately.
GitHub documents repository and organization ownership transfers, including their requirements and effects. If that is where your code lives, review those details before arranging a transfer rather than assuming a downloaded ZIP transfers the whole working setup. Repository transfers, organization ownership.
Ask for an operating guide
The guide should explain the routine tasks someone actually performs: changing content, deploying an update, viewing an error, restoring data, renewing a service and removing a departing colleague's access.
It should identify prerequisites, not hide them. If a deployment requires a particular runtime, a secret, a build command and a database migration, those dependencies belong in the guide. Secret values themselves should be transferred through an appropriate secure channel.
Ask the supplier to distinguish the production environment from the test environment. A new administrator should not have to infer which button changes the public website.
Test the handover with another person
Choose an authorized colleague who did not build the system. Have them follow the guide in the test environment. Let the original developer observe, but avoid rescuing every missing instruction verbally.
Can the colleague find the code, identify the current release, make a small test change and see the result? Can they locate the recovery procedure and support contact? Record every step that depended on undocumented knowledge.
That exercise does not require the colleague to become a developer. It establishes whether the documentation and escalation route are usable by the people expected to operate the service.
Close the open decisions
| Deliverable | Evidence of completion |
|---|---|
| Ownership | Business can access and recover the relevant accounts |
| Source and configuration | Repository and documented environment requirements |
| Deployment | A demonstrated release to the test environment |
| Recovery | A documented procedure and agreed test evidence |
| Billing | Named renewal owner and known recurring services |
| Support | Hours, contact route, scope and escalation |
| Access cleanup | Former or temporary access reviewed and removed where appropriate |
Document outstanding issues instead of describing a project as finished while known problems remain implicit. Agree which issues are accepted, which are still due, and who owns them.
Keep the document alive
An accurate handover can become stale after a hosting move, a personnel change or a new integration. Assign an owner and update the affected parts when the system changes.
Include this question in your proposal review: “What will our business be able to operate independently at the end, and what will still require support?” The answer helps you compare suppliers and plan an ongoing relationship with fewer surprises.
Have a version of this problem?
Let’s talk it through.