Hand over more than the repository. A good handover pack has the source and history, committed lockfiles, a current dependency inventory or SBOM, written build and deploy steps, a list of accounts and secrets that must be rotated, and a named owner for updates. Without these, the client inherits code they cannot safely maintain.
Why the handover is a supply chain event
When an agency delivers a site or app, the client takes on every library, build tool and pipeline credential that came with it. Most clients cannot see those. If the agency leaves, nobody knows which packages are in use, which are outdated, or which tokens still work.
A handover pack turns that hidden state into something the client can read, store and hand to the next team.
The checklist
| Item | What to include | Why it matters |
|---|---|---|
| Source and history | Full repository with branches and tags | Lets a new team audit changes |
| Lockfiles | package-lock.json, poetry.lock, composer.lock or equivalent, committed | Makes installs repeatable |
| Dependency inventory | An SBOM in SPDX or CycloneDX, or a dated list of direct and transitive packages | Gives the client something to check against new advisories |
| Build and deploy steps | A README that a stranger can follow, plus the CI config | Removes dependence on one engineer |
| Third-party services | Hosting, DNS, analytics, email, payment, with the account owner for each | Shows what the client now depends on |
| Secrets list | Every token, deploy key and API key used, with where it lives | Drives rotation after handover |
| Update plan | Who patches, how often, and how a vulnerable package gets raised | Prevents silent decay |
| Known issues | Open advisories and accepted risks, with dates | Keeps the record honest |
Rotate, do not just transfer
Moving a repository usually keeps webhooks, secrets and deploy keys attached. GitHub's documentation says these "will remain associated" after a transfer. That is convenient and also a risk, because credentials the agency created keep working. Treat every item on the secrets list as something to reissue under client ownership, then revoke the agency copy.
Keep it short enough to be read
A 40 page report is filed and forgotten. Aim for a one page summary on top, with the table above, and attachments below. Date everything. A dependency list from launch day is useful evidence of what shipped, but it is not a statement about today.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory view and look at how direct and transitive packages are separated. That split is the part most handover notes leave out.
Quick check
Do we need an SBOM for a small brochure site?
Not always. A lockfile and a dated package list may be enough for a small site. Use an SBOM when the client asks for one, or when the app handles sensitive data.
Who owns the updates after handover?
Whoever the contract names. If it names nobody, assume nobody. Write the owner into the handover pack.
Safeguard
Safeguard's SBOM and dependency scanning can produce the inventory for a repository, and you can run a free scan at gold.safeguard.sh/scan before you hand the code over.
Sources
Last reviewed: 19 October 2026.
