The short answer
Knowledge does not transfer through documents. It transfers by your people doing the work while the person who knows it is still available to ask.
That needs weeks, not a final handover meeting.
Plan it backwards from the end date
- Identify what only the departing people know.
- Have your team take over those areas first, with support.
- Let them handle real work, including a release.
- Reduce the support gradually rather than stopping it.
- Keep a short period of availability after the formal end.
Point three is the test. Reading about a deployment process teaches considerably less than doing one with someone watching.
What gets lost most easily
| Knowledge | Why it is lost |
|---|---|
| Why a decision was made | Never written down |
| Which parts are fragile | Only learned by experience |
| How to diagnose a recurring fault | Lives in someone's head |
| Informal contacts at third parties | Personal relationships |
| What was tried and rejected | Invisible in the code |
The last row causes repeated waste. Without it your team will try the approach that was already ruled out, and spend the same time discovering the same thing.
Check nothing depends on them personally
- Accounts registered to their email address
- Services paid on their card
- Certificates or keys issued to them
- Scheduled tasks running under their account
- Access to third parties granted to them individually
Find these before the last day. Each one becomes considerably harder to resolve once someone has moved on.
Do it well even when it ended badly
A rushed or hostile ending costs you the knowledge, not them. Keeping the transfer professional is in your interest regardless of how the relationship went.
Where a relationship has broken down, agreeing a short paid handover is almost always cheaper than reconstructing what you lost.