In this guide 6 sections
Start the handover the day you hear about the exit. Capture runbooks, decision records and recorded walkthroughs while the engineer is still present. Overlap with the replacement for a sprint. Remove access in a fixed order, rotate every shared credential last, and sign off the handover against a written list.
Inventory what only this person knows
Open the repository history, the ticket board and the chat threads. List every service, cron job, deployment script, certificate and vendor account that the engineer touched during the last six months of commits and tickets. One committer means risk.
Then ask the engineer directly. People remember the odd things: a nightly export that fails every March, a certificate that renews by hand, a staging database nobody else can reset. Write each down.
Sort the list into three piles. Documented already, needs a written runbook, and needs a recorded session because it is too tangled to write.
- Services and repositories with one main committer
- Cron jobs, queue workers and scheduled exports
- Manual steps in the release process
- Third party consoles, such as DNS, payment gateway and app store accounts
- Local scripts that live only on the engineer’s laptop
Turn tacit knowledge into runbooks and decision records
A runbook answers one question: what do I type when this breaks at two in the morning? Keep each to a page. Include the command, the expected output, the log location and who to call if it still fails.
Decision records explain why. A short markdown file per choice is enough. It states the problem, the options weighed, the pick and the date. Skip this and the next engineer, with the best intentions and no context, will quietly undo a sensible workaround that took a week to find. It happens.
Record the hard parts on video. Ask the engineer to share a screen and walk through a real deployment, a rollback and a database restore. Half an hour of narrated footage beats ten pages of prose.
- Runbook per service: start, stop, deploy, roll back, restore
- Architecture diagram with data flows and external calls
- Decision records for non obvious choices
- Recorded walkthrough of a live release
- Glossary of internal names, flags and environment variables
Overlap with the replacement before the last day
Bring the new engineer in at least a sprint before the exit. Pair them on a real ticket, with the leaver driving on day one and the newcomer driving by day five, so that the handover is practised rather than described. Simple.
Give the replacement the written material cold. Whatever they cannot follow without help is a gap in the documents. Fix it while the author is still reachable.
Plan a shadow week after the departure as well. A short paid window for questions by email costs little and has saved many a failed deployment.
Remove access in a fixed order
Do not cut everything at once on the final afternoon, because you may lock out the one person you still need for questions. Work in stages. Tick each off.
Start with write access to production, then cloud consoles, then source control, then ticketing and chat. Keep read access to the shared drive until sign off. Hardware and the work email go last.
If the engineer worked for a vendor, ask the vendor to confirm in writing that its own laptop images and VPN profiles are revoked.
- Production database and server shells
- Cloud console, CI runner and container registry
- Git hosting, with deploy keys checked
- Password manager vault memberships
- Ticketing, chat, shared drive and email
Rotate credentials and sign off the handover
Any secret the engineer could read must now be treated as known. Rotate database passwords, API tokens, signing keys, webhook secrets and SSH keys. Do it only after the replacement has taken over and has deployed once, so that nothing breaks halfway through the handover.
Check the places people forget. Environment files in CI, mobile signing certificates, the shared service account for outbound email and any personal access token used by a bot.
Finish with a thirty minute sign off. Walk the inventory line by line, mark each item done or deferred with an owner, and file the result where the next exit will find it.
Engineer exit handover tracker
Single page, four blocks. The first lists every system and repository with columns for owner, documentation link and status. The second lists access items in removal order with a date and a tick box. The third lists credentials to rotate with the rotation date. The fourth records the overlap days and the sign off name.
Open a blank worksheet to printQuestions owners ask
How long should the overlap with a replacement last?
One full sprint is a sensible minimum for a service with live users. Smaller codebases can manage with a week. The test is whether the newcomer has shipped a change alone.
Should we remove access before the engineer’s last day?
Remove production write access early if the work is done. Keep read access and chat until the sign off meeting. Cut the rest on the final day.
What if the engineer will not write documentation?
Offer a recorded screen walkthrough instead. Many people find talking easier than writing. Transcribe the recording afterwards and store it beside the repository.
Do we need to rotate every credential?
Rotate any secret the person could read or export. If you cannot tell which ones, rotate all of them. A short list of what was rotated and when is worth keeping.