The Discord Server Handover Checklist: What You Should Receive on the Last Day
Seven items separate a delivered build from an owned one. Here is the packet to ask for, and the ten minute test that proves you actually have it.
Delivered is not the same as owned
Delivery is the moment the invite works. Ownership is the moment your own team can change the server without consulting anyone outside it.
Contracts mark the first moment. Nothing marks the second, which is why so many organisations are still messaging a contractor eight months later to ask where the welcome message lives.
For whoever owns growth, this is operationally expensive. The server is about to absorb campaign traffic, launch traffic and partner traffic, and every one of those brings a change request. Change requests that route outside the company move at the speed of somebody else's calendar.
Seven items
| Item | What it must contain | Why it matters |
|---|---|---|
| Ownership | The holding account, named, plus the transfer date | Removes a single point of failure |
| Permissions map | Every role, its capabilities, its current holders | Stale roles are where quiet failures live |
| Automation inventory | Function, location, owner, cost, failure mode | Silent failures cost weeks of joiners |
| Entry flow | Door questions, storage, triggers, member view | Lets you change the door without a rebuild |
| Moderation ruleset | Exported config, thresholds, escalation contact | A ruleset one person can access is not yours |
| Channel owner list | Purpose line and named owner per channel | Unowned channels go quiet inside a month |
| Change log and backlog | Window changes, close date, later requests | Becomes the roadmap you inherit |
The automation inventory deserves the extra attention. Function and location are easy to write. The failure mode is the field that tells your team what they are looking at six months from now when joiners stop receiving a role and nothing in the interface indicates why.
Similarly, the channel owner list looks like administrative tidiness and behaves like retention infrastructure. A visitor judging your community counts how many channels have recent activity, and unowned channels reliably have none.
Ask early, not late
Request the packet at kickoff. A packet requested in the final week is reconstructed from memory, and reconstruction from memory is where the automation nobody remembers configuring gets left out. A packet promised at kickoff is written alongside the work, which costs the builder very little and is worth a great deal to you.
Proving it
Complete documents can still leave you dependent, so test rather than trust. Give four tasks to a colleague who did not build the server, with no help available.
- Create a role and grant it access to exactly one channel.
- Adjust a channel so one role can read but cannot post.
- Find where the welcome message is configured and change a line.
- Pause an automation, verify it stopped, then restart it.
Four out of four is ownership. Three points at one documentation gap you can close in an hour. Below three, the handover is unfinished, and the moment to say so is while the builder is still engaged and well disposed toward you.
About shadow support
Two weeks of post-handover availability is sensible. Real operation raises questions no document predicts, and paying for that access is cheaper than guessing.
The trap is letting it run indefinitely. Support with no end date turns into a standing dependency that nobody ever decided to accept. Bound it explicitly, then either sign a defined ongoing arrangement or close it out.
Two weeks of help is a service. Eight months of help nobody agreed to is an outage waiting for a holiday.
The layers above this one
Holding the keys is not the same as operating the community. Still ahead: coverage hours and weekend answering, the engagement rhythm that brings members back, a moderation staffing model that scales with volume, documentation that answers recurring questions once, and reporting that carries what members say into product and support decisions.
What the packet does is narrow and valuable. It takes the person you hired off your critical path, so every improvement after this is something you can make yourself, on your own schedule.
The cost of a dependency is measured in the changes you quietly decide not to make. More at danieljeong.org.
Want a properly managed community?
Get Your Free Analysis →