Short answer
Document it twice over. Write decisions, runbooks and open threads into the team's own files as the work happens, so the record exists before anyone resigns. Then move the access rather than the content: notes that already live in a shared vault need no migration on the last day, because only the membership ends.
The honest answer has two halves, and every template on the first page of a search for this covers only one. Write the decisions, the runbooks and the open threads into files the team already works in, while the work is happening. Then deal with the half no checklist mentions: the files themselves have to change hands, and most of them are sitting in an account somebody is about to close.
A handover that produces only a document produces a description of the work. The work itself, the notes, the drafts, the runbook that was never finished, stays wherever that person was keeping it.
What belongs in a knowledge transfer document?
The template vendors are right about the contents, and there is no point pretending otherwise. A useful handover names the things a successor cannot reconstruct by reading the code or the ticket tracker:
- The decisions, and the reason each one was taken rather than the obvious alternative.
- The regular work: what runs weekly, what runs at quarter end, what breaks and how it is usually fixed.
- Open threads, with their current state and who is waiting on what.
- The people, inside and outside, who have to be introduced before the last day.
- The accounts, vendors and systems that are in one person's name.
That list is not controversial. The problem is when it gets written.
Why the handover pack is written too late to be true
A knowledge transfer plan that starts at resignation asks someone who has already mentally left to spend two weeks writing a document for a person who does not work here yet. They write what they can remember under time pressure, which is the shape of the work rather than its detail. The parts that actually cost a successor three months are the parts nobody thinks to write down, because to the person leaving they are not knowledge, they are just how things are.
The fix is not a better template. It is that the record has to be a side effect of doing the work rather than a separate project at the end. That is the whole argument for a team second brain rather than a documentation push: if the decision goes into a note when it is taken, the handover is already written on the day the resignation lands, and the two weeks go on answering questions instead of typing.
Baalda is built for that half, and it is also built for the half the templates skip, which is what happens to the files.
Where the knowledge is actually sitting on the last day
Before writing a transfer plan, it is worth asking a flatter question: if this person's laptop went into a drawer tonight, what would the team no longer have?
For a lot of teams in 2026 the answer includes things no offboarding checklist lists. A personal Obsidian vault, because Obsidian's own help defines a vault as a folder on your local file system and that file system belongs to the person. A set of private pages in the workspace. And increasingly, the memory of whatever assistant made them fast: Anthropic's documentation states plainly that Claude Code's auto memory "is machine-local" and that the files "are not shared across machines or cloud environments", stored under ~/.claude/projects/<project>/memory/. The accumulated context that made one engineer quick with your codebase is on one disk, and it is not in the handover pack.
What each tool does when a person is removed
This is the part worth checking against the documentation rather than assuming, because the tools differ more than their marketing does.
| Where the work was kept | On the day they are removed | What anyone can recover afterwards |
|---|---|---|
| A shared Obsidian Sync vault | The owner picks "Remove user". Up to that moment every collaborator held "the same permissions as the vault owner" | Their copy is still a folder on their own disk. If the person leaving was the vault owner, the remote vault is on their account |
| Notion, below Enterprise | "That person will instantly lose access to the workspace, and pages from the Private section of their left sidebar will be hidden from view" | Nothing automatic. Rejoining within 30 days restores their private pages to them |
| Notion Enterprise | The same, plus a "Transfer Private Pages" action on the Recently Left tab | Private pages only, only within 30 days, and "content shared with a current workspace member will not be transferrable" |
| Claude Code auto memory | Nothing happens, because nothing was ever shared. It is machine-local | Nothing, unless autoMemoryDirectory was pointed somewhere the team syncs |
Two things stand out. Notion's Enterprise transfer is a real answer and deserves credit for existing, which is more than most tools in this category can say. And in every row the recovery step is a copy: something is exported, reassigned or moved out of one person's space into another's, after the fact, under a clock.
What changes when the handover is an access change
A copy is the wrong primitive for this. The alternative is that the notes never belonged to the individual in the first place, so nothing has to move when they go.
In Baalda a note is a plain markdown file in a vault the team syncs, and a member has edit on a note they created even with no explicit share. That is what makes private by default work: you keep what you wrote. The rule is gated on membership, so when the membership ends the authorship grant ends with it, and the file stays exactly where it is, on its path, in the vault, with its history. The server's own comment on that line explains why the gate matters: a removed user's session outlives the removal, so if authorship survived it they would keep edit on everything they had ever written and could re-mint sync tokens indefinitely.
Withdrawing a person is therefore one call rather than a migration. Over MCP it is manage_access against the vault resource:
{
"resources": [{ "resourceType": "vault", "resourceId": "<organization id>" }],
"audience": { "type": "users", "userIds": ["<the person leaving>"] },
"mode": "private"
}A users-audience mode on the vault resource is that person's absolute level, and it replaces the org-wide grant, the owner or admin shortcut and their authorship together. There is a narrower version for tidying up rather than cutting off, DELETE /api/orgs/:orgId/members/:userId/shares, which drops every per-person grant the vault holds for one member in a single transaction and leaves them with whatever an ordinary member gets.
Both paths recompute what that person can read before and after, then disconnect each document they lost. A note someone still has open stops being a live editor at that moment rather than at their next sign-in. Access that only takes effect on logout is not access control, and offboarding is precisely the case where the difference shows. The same per-file machinery is the one covered in why per-file permissions need a server that can say no.
How do you find out what someone actually wrote?
The other thing a handover needs is an inventory, and teams usually produce it by asking the person to remember. A vault can answer it from its own records instead. Baalda's members page shows each person's roster entry with their last active date, and a per-person activity timeline assembled from version authorship and each note's last editor, listing the notes they created and the notes they edited, with the paths.
It is gated, which matters more than it sounds: the timeline only ever shows notes the person asking could already read. Offboarding is a common excuse for a manager to be handed a list of everything a colleague ever touched, and an inventory that quietly widens who can see what is not a feature.
That list is the agenda for the two weeks. Rather than "write a document", it is "here are the forty notes you own, these eleven are the ones nobody else has edited, start there".
Where this does not help
Plenty of knowledge transfer is not a file problem, and pretending otherwise would be dishonest.
Nothing here captures what was never written. The judgment about which customer to call first, the reason a decision was really taken, the relationships: those move through conversation, shadowing and the mentored handover that the HR guides describe, and those guides are right to describe them. Baalda has no exit checklist, no interview scheduler and no recording. It holds what somebody chose to write.
There is also no importer. If three years of context is in direct messages and a Notion workspace, deciding today that notes should live in a vault does not retrieve any of it, and the last two weeks are still a scramble. The approach pays from the point you adopt it forward, which is an argument for adopting it before anyone resigns rather than after.
And if the team already runs Notion Enterprise, the Transfer Private Pages path covers the private-page half at no extra cost, so switching tools purely for offboarding would be a strange reason to switch. The case for moving is the daily one: several people editing the same notes, permissions per file, and markdown you keep. We went through what Obsidian can and cannot do for that in whether Obsidian works as a team knowledge base, and the workspace comparison sits on Baalda vs Notion.
Finally, the free tier is two people and one synced vault, which is a pair rather than a team. A team of five keeping its record this way is the Team plan at $10 per seat per month, or self-hosting the server under Apache-2.0 with no seat limit at all.