On this page
- Quick read
- Readiness check
- Define what the handover must transfer
- Start the handover before the last week
- Map the code, not only the tickets
- Record the environment and access state
- Walk through one live change together
- Name the new owner for each open item
- Remove access on a written schedule
- Test the handover with a small change
- Role brief
- Frequently asked questions
- Sources
Is the handoff ready?
Use these checks before access expands or the first ticket begins.
Owner
Ready: A named receiving engineer owns each open area before the handover starts.
Needs work: The work returns to a general queue with no individual owner.
Knowledge
Ready: The receiver has run a change in the area with the departing engineer present.
Needs work: The only transfer is a recorded walkthrough nobody has replayed.
State
Ready: Environment, feature flags, and open decisions are written down.
Needs work: The receiver is told to read the commit history.
Access
Ready: The removal date and the approver are recorded for every account.
Needs work: Access stays active because nobody remembers which accounts exist.
Define what the handover must transfer
A code handover is not a repository transfer, because the repository already belongs to the client. The handover must transfer the knowledge needed to change the code safely, the state of the environments, and the ownership of open decisions. Write those three categories down before the last week. A handover that covers only file locations leaves the receiver unable to act.
Include the unwritten parts: why a workaround exists, which test is flaky, which migration is pending, and which vendor contact answers which question. These details are usually the first to disappear when an engineer leaves. Ask the departing engineer to list them explicitly rather than assuming the receiver will infer them. The list becomes the agenda for the handover sessions.
Start the handover before the last week
A handover compressed into the final week becomes a tour of unfinished work. Start at least two or three weeks before the last day, and name the receiving owner at the start. Give the receiver time to run a real change while the departing engineer is still available. That practice is more valuable than another document.
Schedule the sessions around actual work rather than around a slide deck. Each session should end with the receiver doing something and the departing engineer reviewing it. Record the questions the receiver had to ask, because those questions show where the written material is weak. Update the material before the next session.
Map the code, not only the tickets
Walk through the main entry points, the data flow, and the places where the code makes an assumption about the environment. Mark the modules that are fragile, the tests that are slow, and the areas with no coverage. A map that shows only directories is less useful than one that shows where a change is likely to break something. Mark the files that changed most often in the last two releases, because those are the places the receiver will touch first.
Include the build and release path, the feature flag system, and the observability tools the team uses. Show the receiver how to find a specific request in the logs and how to correlate it with a deployment. If the team uses a runbook, test it during the handover rather than reading it aloud. A runbook that has not been followed is a hypothesis.
Record the environment and access state
List every environment the team uses, including staging, preview, and any shared sandbox. Record the accounts, the roles, and the owner of each environment. Note which credentials are personal and which are shared, because shared credentials are a risk that should be removed during the handover. The receiver should know how to request access through the approved process.
Check the state of feature flags, scheduled jobs, and open migrations. A flag that was left on for a test can change behavior long after the engineer leaves. Record the intended state and the person who can approve a change. If the state is unknown, mark it as unknown rather than guessing.
Walk through one live change together
Choose a small, real change in the area the receiver will own, and run it end to end with both engineers present. The change should include a branch, a review, a test run, and a deployment to a non-production environment. The receiver should drive while the departing engineer observes. This exercise exposes gaps that a document cannot.
After the change, ask the receiver to explain the decisions and the rollback path without prompting. If the explanation is incomplete, repeat the exercise with a different change. Record what was practiced and what remains untested. The goal is confidence based on evidence, not a signature on a checklist.
Name the new owner for each open item
Every open ticket, incident, and decision needs a named owner before the departing engineer leaves. A general queue is not an owner. Record the owner, the next action, and the date the item was transferred. If an item has no owner, escalate it rather than leaving it in the handover document.
Include the decisions that are waiting on a client or a vendor, because those can outlast the engineer's tenure. Record the contact, the question, and the last response. The receiver should be able to continue the conversation without reconstructing it. A decision log that ends with the engineer's departure is not a handover.
Remove access on a written schedule
Access removal is part of the handover, not an afterthought. List every account, token, and group membership the departing engineer holds, and set a removal date. The date should be tied to the last working day or earlier if the role changes. Record who will perform the removal and who will confirm it.
Check for indirect access through shared accounts, CI secrets, and vendor portals. Those are often missed because they are not in the identity provider. Revoke or rotate them according to the risk, and record the action. A handover that leaves a former engineer with production access is incomplete regardless of how good the documentation is.
Test the handover with a small change
After the departing engineer has left, ask the receiver to complete a small change in the area without help. Time the change and record where the receiver had to stop. Those stops are the remaining gaps in the handover. Fix the documentation or the access before the next larger change.
Review the result with the technical owner and decide whether the handover is complete. If the receiver needed to contact the former engineer, record why and whether that contact was appropriate. A handover is complete when the receiver can act independently, not when the last meeting ends. Record the owner's decision and the date, and keep it with the handover notes.
Copy-ready brief
Put the operating agreement in writing.
A named engineer who owns the area and has practiced a real change.
Entry points, data flow, fragile modules, tests, flags, and observability.
Environments, accounts, scheduled jobs, open migrations, and intended flag values.
Access removal dates, confirmations, and the first independent change.
Frequently asked questions
How long should a handover take?
It depends on the area, but two to three weeks is a reasonable minimum for a single engineer with active work. A complex area needs longer and should start earlier.
Is documentation enough?
No. Documentation is necessary but not sufficient. The receiver should run a real change with the departing engineer present and then repeat it alone.
What about knowledge held by a vendor?
Include the vendor contact, the contract owner, and the support path in the handover. The client should not depend on one engineer's personal relationship with a vendor.
When should access be removed?
On or before the last working day, with a recorded confirmation. Any shared secret the engineer could see should be rotated if the risk warrants it.
Sources
- NIST Secure Software Development Framework
Practices for maintaining software and transferring knowledge.
- CISA Cybersecurity Performance Goals
Access removal and credential hygiene expectations.
- Google Engineering Practices, code review
Review and knowledge-sharing practices used in the walkthrough.