Before you remove a contractor, collect a handover pack: merged code and open branches, build and deploy notes, a dependency list, an inventory of credentials and integrations they touched, and a list of known risks. Do this while they are still reachable, because after they leave, questions go unanswered.
Handover is not offboarding
The contractor offboarding checklist is about closing access. Handover is about keeping knowledge. They overlap in time and fail for different reasons. Access gets forgotten when nobody owns the date. Knowledge gets lost when everyone assumes the pull request history explains itself.
Schedule handover for the last week or two, with a review meeting before the final day.
The handover pack
| Item | What to collect | Why |
|---|---|---|
| Code state | Merged work, open pull requests, unmerged branches and what to do with each | Orphan branches hide unreviewed code |
| Build and deploy notes | How to build, test and release, with commands | Avoids a single person bottleneck |
| Dependency list | New packages added, why, and any known issues | Next owner can patch later, see dependency approvals |
| Credentials and integrations | Every key, token, webhook, service account and deploy key touched | These outlive the person, see deploy keys |
| Design decisions | Short notes on why, not only what | The code rarely explains the reason |
| Known risks | Shortcuts taken, tests missing, TODOs | Honest list beats a surprise |
| Ownership | Internal owner per path, see ownership map | Accountability after exit |
A one week plan
- Day one. Ask the contractor for a draft of the pack. Name the internal owner who will receive it.
- Day two. List open branches and pull requests. Merge, close with a note, or reassign each one.
- Day three. Walk through the credentials inventory. Mark each as rotate, transfer or delete.
- Day four. Run a build and deploy from the notes, done by a staff member, not the contractor. Whatever fails is a gap in the notes.
- Day five. Review known risks with the owning team and file tickets for each.
Test the notes, do not just read them
The most valuable single step is having a staff engineer follow the notes cold. Where they get stuck is where tomorrow's incident will be. Ask the contractor to fix the notes while they can.
What to do with open branches
An unmerged branch is code nobody reviewed. Do not leave it sitting in the repository, where someone may later merge it on trust. Either review and merge, or archive it with a note, or delete it. Record which.
After the pack is accepted
Then run exit: remove access, delete or rotate credentials, revoke tokens, confirm in writing that local copies are deleted, and note that, as GitHub documents, removed people may keep local clones. See what happens to a local clone.
Try it yourself
Click through it at your own pace, or open it full screen.
Use it to see what a dependency inventory looks like, then compare it with the list a contractor hands you.
Safeguard's dependency scanning and SBOM generation can produce the dependency list for the pack automatically, and compliance and evidence automation can store the review record. See the free scan.
Quick check
When should the handover happen?
In the last week or two, while the contractor is still available to answer questions, and before access is removed.
What do I do with unmerged contractor branches?
Review and merge, archive with a note, or delete, and record which. Do not leave unreviewed code waiting to be merged on trust.
Sources
Last reviewed: 19 October 2026.
