MU Online server succession and sale: a complete, safe guide

Selling or handing off administration of a MU Online server to someone else is an operation that involves far more than transferring files: there's sensitive player data, outstanding financial obligations, hosting contracts, a domain, social media, and above all, the trust of a community built over months or years. Done carelessly, the transition can lead to financial loss, data leaks, or the sudden collapse of the server. This tutorial covers the full process — from valuing the "business" to the final communication with players — for anyone considering selling, buying, or handing off a project's administration.

Why server succession is different from "handing over a password"

A mature MU Online server is, in practice, a small digital business: it has recurring revenue (donations, cash shop, VIP), a user base with personal data (email, IP, possibly tokenized payment data), a brand presence (domain, social media, Discord), and a tech stack with specific dependencies. Treating the sale as a simple FTP password swap ignores legal, financial, and reputational risks that can materialize months after the transaction.

Assessing the server's assets

Before negotiating a price, you need to list exactly what's being transferred. An asset inventory table helps both seller and buyer gain clarity:

Estimating a fair price

There's no single formula, but a common starting point in the private-server market is to consider multiples of recurring monthly revenue, adjusted by qualitative factors:

A healthy practice is for the seller to present screenshots or reports from the payment panel (Mercado Pago, PayPal, etc.) covering the last few months, so the buyer can validate the reported revenue before closing the deal.

Due diligence: what the buyer should check

Before paying, the buyer should verify:

1. Real access to the systems — request a live demo (screen share) of the hosting panel, database, and GameServer running.
2. Legal origin of the files — if the server uses official Webzen files without a license, that risk transfers along with the sale (assess the exposure before buying).
3. State of the custom code — poorly documented exclusive systems can be hard to maintain without the original developer.
4. Outstanding liabilities — hosting debts, open chargeback disputes, or promises made to the community that haven't been delivered (e.g., a promised event that never happened).
5. Moderation history — recent contested bans, open internal disputes.

Structuring the sale contract

Even in an informal transaction between members of the private-server community, a simple written contract protects both parties. Items that can't be skipped:

• Identification of the parties (full name, email, contact method).
• Exact description of the included assets (use the asset inventory table as an attachment).
• Total value and payment method (upfront, installments, with a deposit and balance on delivery).
• Date and method of technical transfer (when passwords will be changed, deadline for the seller to lose all access).
• Responsibility for prior liabilities (chargebacks, debts, disputes open before the cutoff date).
• Confidentiality clause covering player data.
• Non-compete clause (optional), if the seller agrees not to launch a competing server using the same base for a period.

Safe technical handoff

The technical handoff should follow an order that minimizes risk for both parties:

1. Buyer pays the deposit (part of the agreed amount).
2. Seller delivers a full backup (database, server and client files) over a secure channel — SFTP, VPN, or temporary private storage, never unencrypted email.
3. Buyer validates the backup in a test environment before confirming the balance.
4. After confirmation, the seller transfers: hosting panel access, domain (or starts the transfer process), social media, and Discord.
5. All passwords and credentials are changed immediately by the buyer — including payment API tokens, if applicable.
6. Seller loses any remaining access (revoke old SSH keys, remove from admin lists, etc.).

# Example post-sale access-revocation checklist
ssh-keygen -R old_server_ip          # remove old key from the seller's known_hosts
# In the VPS panel: revoke all SSH keys of the previous user
# In the database: change the admin user password and revoke old remote access
# In the domain: transfer to the new account at the registrar or change DNS/nameservers

Player data and compliance

When transferring the player base, treat this as a personal-data transfer, not just a "database file." Good practices:

• Inform the community that the administration has changed and, if possible, who is now responsible for the data.
• Avoid exposing non-tokenized payment data — most donation systems (Mercado Pago, PayPal) shouldn't store card data directly; if yours does, that's a critical risk that must be resolved before the transfer.
• Consider whether LGPD (Brazil's General Data Protection Law) obligations apply regarding the purpose of processing and notifying data subjects about the change of data controller.

Communicating the change to the community

Transparency reduces the risk of a mass player exodus. Effective communication includes:

• An official announcement on the server's channels (site, Discord, social media) explaining the transition of administration.
• Assurance that player data and progress have been preserved.
• A (brief) introduction of the new person in charge, to give the change a face and build trust.
• Commitments that will be kept (scheduled events, prior promises) and what may change (rules, donation policy).

Assisted transition period

It's common and advisable for the seller to offer a support period (1 to 4 weeks) after the sale, answering technical questions about custom systems. This should be spelled out in the contract, with a clear scope and deadline, so the seller isn't indefinitely on the hook after already receiving full payment.

Common errors and fixes

Server succession/sale checklist

• Complete asset inventory (infrastructure, domain, social media, code) compiled.
• Recurring revenue documented and validated by the buyer.
• Technical and legal due diligence done before payment.
• Written contract covering assets, price, deadlines, and prior liabilities.
• Technical transfer following a safe order (backup, validation, payment, credential change).
• All old passwords and access revoked after the transition.
• Transparent communication published to the community.
• Post-sale support period defined, if applicable.

If you're on the buying side or taking over a server for the first time, it's worth reviewing the technical infrastructure fundamentals before signing any contract — check out the server creation tutorial to understand exactly what's behind the files you're about to receive.

Frequently asked questions