The Discord Server Handover Checklist: What You Should Receive on the Last Day

A Discord server handover checklist has seven items: ownership in writing, a permissions map, an automation inventory, the entry flow, the moderation ruleset, a channel owner list, and the change log with the open backlog. Then prove it by having someone who did not build the server perform four routine changes with nobody helping.

---

The gap between delivered and owned

A build is delivered when the invite works. A build is owned when somebody on your payroll can change it on a Tuesday afternoon without asking permission or advice from the person who made it. Those two moments are usually weeks apart, and nothing in the contract marks the second one. The invoice clears on delivery. The dependency stays. This matters most to whoever holds the growth number, because the server is about to become a destination for campaigns, launches and partner traffic. Every change those campaigns require, a new channel, a new role, a new automated welcome, arrives as a request to an external party unless the packet below exists.

The packet, item by item

1. Ownership, in writing

Name the account that holds server ownership and the date it transferred. Ownership sitting with a contractor is not a filing problem, it is a single point of failure, and the recovery path when that person is unreachable is genuinely painful. If the server was built inside the builder's account, the transfer is a discrete event with a date. Put that date in the packet.

2. The permissions map

Every role, what it can do, and who holds it today. This is one table. Most servers have between five and twelve roles, and by month three nobody remembers which one carries channel management. The map matters because permissions are where the quiet failures live. A role that can delete messages, held by someone who left, is a problem you will discover at the worst possible time.

3. The automation inventory

Every bot and every automated behaviour, with five fields each: what it does, where it is configured, which account owns the configuration, who pays for it, and what visibly breaks if it stops. That last field is the one people skip and the one you need. An automation nobody can describe the failure mode of will fail silently, and silent failures in onboarding cost you weeks of joiners before anyone notices.

4. The entry flow, written down

The questions asked at the door, where the answers are stored, which answer triggers which role, and what the new member sees at each step. Write it as a sequence rather than a description. Someone should be able to follow it while clicking through the server as a test account.

5. The moderation ruleset

The filter configuration exported rather than described, the account age and verification thresholds, the escalation path, and the name of the person who gets contacted when something serious happens. A ruleset that exists only inside a tool that one person can log into is not yours.

6. The channel owner list

Each channel, one line describing its purpose, and one named owner. Channels without owners go quiet within a month, and a quiet channel makes a busy server look abandoned to a first time visitor.

7. The change log and the open backlog

What changed during the revision window, the date that window closed, and the list of requests that arrived after it. The backlog is not an accusation. It is the roadmap you inherit, and it prevents the same six suggestions from being raised again next quarter as though they were new.

⚠️ Ask for this packet at kickoff, not at the end. A packet requested in the final week gets assembled from memory. A packet promised at kickoff gets written while the work is happening.

---

The ten minute test

Documents can be complete and still leave you dependent. Run this before signing anything off. Pick someone on your team who did not build the server and give them four tasks with nobody available to help:

• Create a new role and give it access to exactly one existing channel
• Change one channel's permissions so a specific role can read without posting
• Locate where the welcome message is configured and edit one line of it
• Pause one automation, confirm it stopped, and restart it Four completions means you own the server. Three means you have a documentation gap in a known place, which is fixable in an hour. Fewer than three means the handover is not finished, and that is worth saying plainly while the relationship is still warm.

The purpose of the test is not to catch anybody out. It is to find the gap while the person who can close it is still on the project.

Shadow support, bounded

Two weeks of availability after the packet lands is reasonable and worth paying for. Questions surface during real operation that no document anticipates. What should not happen is shadow support becoming permanent, where every quarter still opens with a message to an external party asking how something works. Bound it the same way you bound the revision window: two weeks, then a defined support arrangement or nothing.

What this checklist does not give you

Ownership of a server is not the same as running a community. Above this layer sit coverage hours and who answers on a Sunday, the engagement rhythm that gives members a reason to return, the moderation staffing model as volume grows, documentation so recurring questions are answered once, and the reporting loop that carries member evidence back to product and support. The packet solves one problem completely and permanently: it removes the person you hired from your critical path. Everything else in the operating model is still ahead of you, and it is much easier to build once you can change your own permissions.

Every external dependency you tolerate becomes a reason not to change something later. Take the keys. More at danieljeong.org.