Staff offboarding and transition on MU Online servers: a complete guide
A complete process for safely offboarding a staff member from a MU Online server: revoking access, rotating shared credentials, auditing past actions, and communicating with the community, minimizing the risk of sabotage or leaks.
Every MU Online server staff team — GMs, moderators, developers — eventually goes through offboarding, whether friendly or conflictive. What sets a mature server apart from an amateur one isn't avoiding these departures, but having a clear process to carry them out without leaving security gaps, wit
Every MU Online server staff team — GMs, moderators, developers — eventually goes through offboarding, whether friendly or conflictive. What sets a mature server apart from an amateur one isn't avoiding these departures, but having a clear process to carry them out without leaving security gaps, without losing operational knowledge, and without destabilizing the community. This tutorial covers the complete process: from the technical revocation of access to auditing past actions, redistributing responsibilities, and proper public communication.
Why staff transitions are a security risk
A staff member, by definition, has access to sensitive systems: the admin panel, in-game GM commands, possibly the database, the server's FTP, private Discord channels. A poorly handled offboarding leaves those doors open — literally, credentials that remain valid — creating a real risk of sabotage (improper item/Zen distribution, wrongful player bans, information leaks) even after the person has formally "left" the team.
Prerequisites
- An up-to-date list of every access granted to each staff member (panel, database, FTP, Discord, social media).
- A GM action logging system enabled (commands used, items/Zen distributed, bans applied).
- At least two people with authority to carry out the revocation (avoids depending on a single person at the critical moment).
Step 1 — Map all of the member's access before the departure
Even before starting the offboarding, have (or build on the spot) a complete list of what that specific staff member had access to:
| System | Access example | Action needed on departure |
|---|---|---|
| MuCMS/site admin panel | Admin/moderator login | Remove the account or downgrade the permission |
| In-game GM commands | Account with GM/admin flag | Remove the flag in the database |
| Database | SQL user with write permission | Revoke/delete the user |
| Server FTP/SSH | File access credential | Remove the key/user |
| Discord (community server) | Staff role, access to private channels | Remove the role and remove from the private channel |
| Shared credentials (if any) | Hosting panel password, etc. | Change the shared password immediately |
Step 2 — Revoke technical access the same day
The practical rule is: technical revocation happens the same day the offboarding decision is made, regardless of whether the formal conversation/communication has already concluded. This avoids the risk window between "the person knows they're leaving" and "their access is still active." Revocation priority:
- GM/admin flag on the game account (highest potential for immediate damage).
- Access to the database and the CMS admin panel.
- Access to FTP/SSH and any shared infrastructure credential.
- Role and access to private Discord channels.
Step 3 — Rotate shared credentials
If the staff member had access to any shared password (hosting panel, admin email, payment account), rotate those passwords even if the departure was friendly — this is standard security hygiene, not personal distrust. Document the new credential in a password vault shared only among those who truly need it (not in a plain text document on Discord).
Step 4 — Audit the departed staff member's recent actions
Before considering the process complete, review the logs of the member's activity over the past few weeks:
- GM commands used (item distribution, Zen, teleport, ban/unban).
- Changes made in the admin panel (news editing, shop settings).
- Unusual patterns — for example, a spike in rare item distribution in the days before the departure is a warning sign that deserves investigation and possible targeted rollback.
Step 5 — Revert any improper actions identified
If the audit reveals improper distribution of items, Zen, or bans applied without justification, consider a targeted reversal via GM command or a specific character rollback, avoiding a general server rollback that would penalize innocent players. The faster this step happens after the departure, the higher the chance of reverting it without side effects on the overall economy.
Step 6 — Redistribute responsibilities
Identify what that member did that nobody else does today — moderating a specific channel, organizing events, technical support for a given system — and redistribute it among the remaining members or open recruitment for the position. Use the moment to document processes that only existed in the departed person's head, reducing dependence on individual tacit knowledge going forward.
Step 7 — Communicate the departure to the community (when applicable)
How you communicate depends on the tone of the departure:
| Type of departure | Recommended approach |
|---|---|
| Friendly (personal reasons, time, studies) | Public announcement with thanks for their service |
| Conflictive (proven breach of trust) | Discreet, professional communication, without unnecessary details, avoiding public drama |
| Suspicion of serious misconduct | Factual, minimal communication, prioritizing community trust over personal case details |
Avoid unproven public accusations — even in serious cases, prefer factual, institutional language ("the member is no longer part of the team") over personal attacks that could create reputational or legal problems.
Step 8 — Review the onboarding process for new members
Every departure is an opportunity to review how new members are integrated: is the access granted truly minimal and necessary (principle of least privilege)? Is there a standard access checklist when hiring/promoting someone, so the next departure is just as fast to audit?
Step 9 — Document the process for next time
Record what worked and what slowed things down in this specific offboarding — which access was forgotten, which log was missing, how long it took. A living checklist, updated with every departure, is what turns this process from reactive and stressful into routine and controlled.
Common errors and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Ex-staff can still use GM commands | Flag not removed from the database | Confirm and remove the flag immediately after the decision |
| Shared credential is still valid | Password not rotated because it "didn't seem necessary" | Rotate it as standard practice, regardless of the departure's tone |
| Improperly distributed items/Zen not identified | Log audit not performed | Review the last few weeks of logs before closing the process |
| Community reacts badly to the announcement | Abrupt or accusatory communication | Use factual, institutional language, without unnecessary drama |
| Process takes too long and creates a risk window | No predefined checklist | Document and reuse a standard offboarding checklist |
Offboarding and transition checklist
- Complete list of the member's access mapped.
- GM/admin flag removed the same day as the decision.
- Access to database, panel, and FTP revoked.
- Shared credentials rotated.
- Audit of the last few weeks of logs performed.
- Improper actions identified and reverted where applicable.
- Responsibilities redistributed and documented.
- Community communication delivered in the appropriate tone for the case.
With a structured offboarding process, your team gains the resilience to handle staff changes without putting security or community trust at risk — and if your server still doesn't have a formal, documented access and permissions policy, this is a good time to revisit the server creation tutorial and formalize that process starting from the basic operational structure.
Frequently asked questions
Do I need to change ALL passwords when a staff member leaves, even on good terms?
Yes. Regardless of the reason for leaving, any credential the member had access to (admin panel, database, FTP, Discord) should be rotated as standard practice, not only in conflictive departures. This isn't personal distrust, it's basic security hygiene.
What if the staff member who left was the only one with access to something critical?
That's a symptom of a structural problem: critical access concentrated in a single person. Once you spot this during the transition, document and distribute that access among at least two trusted people immediately, so the risk isn't repeated.
Should I publicly announce a staff member's departure?
It depends on the reason. Friendly departures can be announced with public thanks. Offboarding due to a breach of trust is generally better communicated discreetly and professionally, without exposing details that create unnecessary drama in the community.
Is it possible to recover items/Zen improperly distributed by a staff member before leaving?
In many emulators, yes, through a targeted rollback of specific characters or manual removal via GM command, as long as you've identified the action in the log audit. The faster the audit, the higher the chance of reverting it without affecting other players.
Is it worth having a contract or responsibility agreement with volunteer staff?
Yes, even an informal one. A simple term defining what staff can and can't do, and what happens to their access when they leave, reduces ambiguity and gives you backing to act quickly in a conflictive departure.