How to migrate your MU Online server from a VPS to a dedicated server

Migrating a private MU Online server from a VPS to a dedicated server is the natural next step when the community grows and shared CPU, disk IO, and network limits start causing lag, login timeouts, and freezes during peak hours. Unlike a simple plan upgrade, this migration involves switching physical hosts, which usually means a new IP, a fresh OS install, and the need to move an entire MySQL database without losing a single character. This tutorial covers hardware planning, preparing the new environment, migrating data and files, the DNS switch, and the final cutover with the smallest possible downtime, plus the mistakes that most often derail this migration in practice.

Why migrate from VPS to dedicated

A VPS shares CPU, disk, and network with other VPS instances on the same physical host, even when the plan promises "guaranteed" resources. On a MU server with many concurrent players, MySQL handles a high volume of queries per second (login, movement, trade guards, PK logs), and it's precisely the shared disk IO that tends to be the bottleneck — not CPU. A dedicated server delivers exclusive disk (ideally NVMe) and network, eliminating the "noisy neighbor" that steals performance during peak hours. Dedicated servers also tend to have larger network links and more stable routing, reducing the latency spikes players feel as "ping spikes."

Assessing whether the timing is right

Before spending money on a dedicated server, measure the actual symptoms. A top/htop showing high IO wait during peak hours, together with slow queries in MySQL's slow_query_log, is the main indicator that the VPS is the bottleneck, not your poorly indexed database. It's worth confirming this first, because migrating to a dedicated server doesn't fix poorly written queries — it only buys more hardware headroom.

Choosing the dedicated server hardware

For a MU Online server with hundreds of concurrent players, the real bottleneck is almost always disk IO and RAM available for MySQL to cache, not raw CPU. Prioritize NVMe disk in RAID 1 (redundancy), at least 32 GB of RAM (so the InnoDB buffer pool can grow comfortably), and a CPU with good per-core clock speed (the GameServer and MySQL scale better with high clock speed than with many weak cores).

Planning the maintenance window

Announce the date and time at least 3-5 days in advance, across every channel (Discord, website, launcher). Choose the lowest-traffic time (usually the middle of the night) and estimate the real duration based on a dry-run — not just an optimistic guess. A common mistake is announcing "30 minutes" and having the actual migration take 3 hours because the database dump was never tested beforehand.

Preparing the dedicated server before cutover

All the heavy lifting should happen before taking the old server offline. That includes: installing the operating system, configuring MySQL/MariaDB with the same (or compatible) versions as the source, installing the MuServer/emulator, copying the game's static files (Data/, configs, maps), and running a full boot test of GameServer and ConnectServer pointed at a test database. Only after that test passes should you schedule the real window.

# On the new dedicated server, test that MySQL comes up correctly
sudo systemctl status mysql
mysql -u root -p -e "SHOW VARIABLES LIKE 'version';"

# Validate available disk space before the migration
df -h

Migrating the MySQL database with zero data loss

The most critical step. After putting the server into real maintenance (ConnectServer refusing new logins), generate the full dump:

# On the source VPS, after blocking new logins
mysqldump -u root -p --single-transaction --routines --triggers MuOnline > mu_dump_final.sql

# Validate size and integrity before transferring
ls -lh mu_dump_final.sql
md5sum mu_dump_final.sql

Transfer the dump via rsync or scp to the dedicated server (never by email or third-party upload service, given the volume and sensitivity of account data). At the destination, restore it and check the md5sum of the received file before importing:

scp mu_dump_final.sql user@dedicated-server-ip:/backup/
mysql -u root -p MuOnline < mu_dump_final.sql

After importing, run a sanity check: character count, account count, and the last logged login date should match what existed at the source at the moment of the dump.

Migrating static files and configs

Besides the database, copy the entire server folder (GameServer/ConnectServer/JoinServer executables, .txt/.xml config files, maps, and any custom event scripts). Use rsync -avz to preserve permissions and avoid silent corruption on large binary files. Review MySQL connection strings in each config — the dedicated server will have a different local IP (or socket) from the VPS.

Adjusting DNS and the client's fixed IP

Update your domain's A record to the new dedicated server IP, and lower the DNS TTL to something low (300 seconds) a few days before the migration, so propagation is fast at cutover time. If the game client uses a hardcoded fixed IP instead of a domain (common in many launchers), you'll need to distribute a client or launcher update with the new IP — plan for this with extra lead time, since DNS propagation doesn't solve this case.

Executing the cutover

1. Announce the start of maintenance and block new logins on the old VPS.
2. Generate the final MySQL dump and validate the checksum.
3. Transfer the dump and files to the dedicated server.
4. Restore the database and confirm the sanity counts.
5. Bring up GameServer, ConnectServer, and JoinServer on the dedicated server and test login with a GM account.
6. Update DNS (or distribute the new IP via the launcher).
7. Keep the old VPS running, not accepting logins, for 24-48h as a fallback.
8. Announce completion and monitor the dedicated server through the first peak hours.

Keeping the old VPS as a temporary fallback

Don't shut down or cancel the VPS right away. Keep it active (not receiving game traffic) for at least 24 to 48 hours after cutover, with the most recent dump also stored there. If something critical fails on the dedicated server, you can quickly revert DNS while you investigate, instead of losing your player base entirely.

Common errors and fixes

Migration checklist

• Bottleneck symptoms confirmed (IO wait, CPU, slow queries).
• Dedicated server hardware sized and provisioned.
• Full dry-run done before the real window.
• Maintenance window announced in advance.
• MySQL dump generated after login block, with checksum validated.
• Static files and configs migrated via rsync.
• DNS/IP updated and tested.
• Old VPS kept as fallback for 24-48h.

With the server now running stably on the dedicated hardware, the next step is to revisit your backup and monitoring strategy now that you have full control over the hardware — and, if you don't yet have a documented process from scratch, it's worth reviewing the MU Online server creation tutorial to check whether anything got left behind in the new infrastructure.

Frequently asked questions