A content team handover is the written record and one live conversation that let a replacement pick up a departing writer or editor’s work without guessing: the editorial calendar and draft status, CMS and tool access, the style guide, the contact list for freelancers and approvers, and every open loop still in motion. Start the day notice is given, not the last day. Skip any of the five and the gap shows up two weeks later as a missed deadline or a locked-out login.
Why most content team handovers fail
Not because nobody tries. Because the handover gets treated as a single document handed over on the last day, when it is really two things done over two weeks: writing down what is normally kept in one person’s head, and then talking through it with the person who inherits it.
The document alone misses tone, exceptions and the reasons behind decisions that never made it into any file. The conversation alone is not searchable three months later when the successor forgets what was said. A content team handover needs both, and most failures trace to skipping one of them rather than doing either one badly.
What the handover document should cover
Five sections, in the order a successor actually needs them.
Editorial calendar and pipeline status. Every piece in progress, its stage, its deadline, and what is blocking it. Not “it’s in the folder,” which tells a successor nothing about what is done, what is half-done, and what has been sitting untouched for a reason nobody wrote down.
Access to the tools that run the site. Logins, publishing permissions, and which platform the team actually uses day to day. This is also the moment to check whether a successor without technical background can actually log in and publish without a developer, because a handover that assumes technical comfort the new person does not have fails on day one, not week three.
The style guide and standards. If the departing person carried decisions in their head that never made it onto paper, that gap becomes visible the first time the successor has to guess. Pointing them at a one-page editorial style guide they can actually read in ten minutes does more for continuity than a long process manual nobody opens.
Contacts and the approval chain. Freelancers, subject-matter experts, whoever signs off before something publishes. Introduce them, don’t just list names, so the new person is not cold-emailing a freelancer who has never heard of them.
Open loops. Unanswered messages, pending revisions, anything half-finished that has no obvious next step written anywhere else. This section is the one most handovers skip, and it is the one that causes the most visible mess afterward.
Access comes with a decision, not just a password
Handing over logins is the mechanical part. The harder question a departure often forces is whether the current setup still makes sense once the person who understood it best is gone.
If the departing team member was the one who kept a self-hosted platform running, who is on call at 2am becomes a real question rather than a hypothetical one, because the answer used to be “them.” Worth asking honestly during the handover, before assuming the next person absorbs that responsibility by default. Similarly, if nobody left on the team can troubleshoot the CMS without outside help, that is the moment to settle whether the site needs a developer on call at all, rather than discovering the gap during the next outage.
Neither question has to be answered before the person leaves. But if the handover conversation does not raise them, the team finds out the hard way, usually during an incident rather than during a calm review.
The conversation the document can’t replace
A written handover, however thorough, misses the things nobody thinks to write down: why a client rejected a draft last spring, which freelancer needs extra lead time, which “obvious” step is not actually obvious.
A 2026 handover guide from Go1, read 2026-09-18, makes the point plainly: even a short dedicated session between the departing person and their successor surfaces details that never make it into documentation, and the exchange works best when the successor is encouraged to ask questions in real time rather than review the document silently afterward. Thirty minutes, scheduled deliberately, does more than another page of notes.
Keep it to one clear agenda: walk the calendar, walk the open loops, and let the successor interrupt with questions. A meeting with no agenda turns into a general chat and the specific gaps never surface.
Freelancers and contractors need a different handover
An employee’s handover assumes an ongoing relationship with the site. A freelancer’s departure is usually final, and that changes what needs documenting.
freelancewriting.com’s guide to managing freelance writers, read 2026-09-18, recommends settling sourcing requirements, linking policy and what counts as a complete submission up front, precisely so those standards survive when the writer who knew them informally moves on. When a freelancer leaves, write down not just what they were working on, but the standards they were quietly enforcing that were never in the brief template: how much revision was normal for their work, what triggered a rewrite versus a light edit, and any client-specific quirks they had learned by trial and error.
Revoke access as part of the handover, not as an afterthought weeks later. A freelancer who no longer works with the team should not still hold live credentials to the CMS or the shared drive, however amicable the departure.
When there is no notice at all
Sometimes the person is gone before any of this happens: a sudden resignation, an extended medical leave, a contract that simply is not renewed. There is no two-week runway and no calm conversation to schedule.
In that case, skip the polish and grab what exists. Pull the last month of the editorial calendar as it stands, list every draft currently open in the CMS regardless of stage, and change every shared password the departing person had access to the same week, not eventually. A messy, thirty-minute audit done immediately beats a thorough handover document that never gets written because there was nobody left to write it with.
The one thing worth doing even here: ask whoever worked closest with the departing person, a co-editor, a frequent collaborator, to write down what they remember about open commitments and quirks, while it is still fresh. Secondhand knowledge, captured quickly, is better than firsthand knowledge that nobody wrote down at all.
What nobody puts in the handover document
The gap that causes the most trouble is judgment, not information. A handover document lists tasks and passwords well. It rarely explains why a decision was made a particular way, which makes the successor either repeat a mistake that was already fixed once, or second-guess a choice that was actually deliberate.
The fix is small: for every non-obvious decision on the calendar or in the style guide, add one sentence on why, not just what. “We stopped running listicles on this section because engagement dropped” tells a successor something a bare rule never does. Nobody enjoys writing these sentences because they take longer than a checklist item, which is exactly why they are the ones that go missing, and exactly why including them is the actual information gain in a handover that otherwise looks the same as every template online.
A simple content team handover checklist
- Editorial calendar with stage, deadline and blocker for every open piece
- CMS and tool access, transferred and old credentials scheduled for removal
- The style guide, current and short enough to actually be read
- A contact list with introductions made, not just names listed
- Every open loop written down with its next step
- One scheduled conversation, agenda set in advance
- For freelancers specifically: sourcing and revision standards, and access revoked on departure
FAQ
How long should a content team handover take?
Start the day notice is given, not the last day. A two-to-four week notice period sounds generous until ongoing deadlines and time off are subtracted from it, so the handover document should be started immediately and refined over the remaining weeks rather than written in one sitting at the end.
What is the single most important thing to document first?
The editorial calendar and pipeline status. Everything else, access, contacts, style guide, supports understanding the work in progress, but the calendar is what a successor needs on day one to avoid a missed deadline in the first week.
Do freelancers need a formal handover, not just an email?
Yes, and it looks different from a staff handover. Document the sourcing and revision standards they were enforcing informally, introduce them to whoever inherits the relationship if the arrangement continues with someone else, and revoke their access as part of the departure rather than afterward.
What happens if someone leaves without much notice?
Prioritize the calendar and access first, since those cause the most immediate damage if missing. The style guide and the reasons behind past decisions can be reconstructed later from remaining team members and old drafts; a missed deadline in week one cannot be undone as easily.
Who should own the handover document after the transition is done?
The successor, once they have used it for a few weeks and know what was missing. A handover document is a starting point, not a permanent record, and it should be corrected and kept current for whoever leaves next rather than filed away unread.
