How to Migrate a MU Server from a Home PC to a VPS

Running your MU server on a home PC works fine at first — it's cheap and you have physical control of the machine. But as the project grows, the limits show up: the power flickers and the server vanishes, residential internet has low upload and a dynamic IP, the PC needs to reboot for updates and nobody can play, and exposing your home IP becomes a real risk of a DDoS aimed at your house. Migrating to a VPS solves all of that at once: a dedicated uplink, a static IP, redundant power and network, and the ability to reboot without disrupting your personal life. The catch is that a migration done wrong can corrupt the database, lose player progress, or leave the server down for hours. This guide shows how to make the move consistently and with the least possible downtime.

Migration is an advanced task because it blends database, network, DNS, and client files. If you're not yet comfortable with the structure of a MuServer, it's worth reviewing the step-by-step on how to create a MU Online server before tackling the environment change — this migration assumes you already understand how the components talk to each other.

Prerequisites

• A working server on the PC, with access to SQL Server and the MuServer folder.
• A rented VPS, with Windows Server and administrative access (RDP + a KVM/VNC console from the panel).
• The same version (or a compatible one) of SQL Server on the VPS and the PC. Restoring a backup from a newer version onto an older one doesn't work.
• Enough disk space on the VPS for the database, the MuServer, and some room to grow.
• A domain (recommended) with access to the DNS panel, so you don't tie the client to an IP.
• A maintenance window agreed on with the players (give plenty of notice).
• A file-transfer tool (RDP with drive sharing, FTP/SFTP, or a cloud service).

Sizing the VPS

Choosing the right VPS avoids rework. The numbers below are a starting point (they vary by provider/version and by the actual number of players):

The most important factor is usually the disk: SQL Server is sensitive to I/O, so favor NVMe/SSD. Insufficient RAM makes the database page to disk and the server stutter during events. Leave some CPU headroom for spikes like Castle Siege.

Strategy overview

To minimize downtime, the migration is split into two phases:

1. Advance preparation (no rush): you build out the entire VPS — SQL Server, MuServer, ports, firewall — using an old copy of the database just for testing. No one notices, because the production server keeps running on the PC.
2. Final switchover (short window): you stop the production server, take the final, consistent backup, restore it onto the already-prepared VPS, adjust the IPs, and switch the DNS. Because the VPS is already fully configured and tested, the real downtime drops to a few minutes.

That separation is what sets an amateur migration (server down for hours) apart from a professional one (down for minutes).

Phase 1 — Prepare the VPS in advance

Step 1: install the base on the VPS

1. Connect to the VPS over RDP and install SQL Server at the same version/edition as the PC.
2. Install the MuServer dependencies (the runtimes/redistributables your version requires — this varies by version).
3. Copy the MuServer folder from the PC to the VPS. Keep the same folder structure so you don't break internal paths.
4. Take a test backup of the current database (it can be done with the server running, since it's only a rehearsal) and restore it on the VPS.

Step 2: take a test backup of the database

In the PC's SQL Server Management Studio (SSMS), generate a full backup:

BACKUP DATABASE [MuOnline] TO DISK = N'C:\Backups\MuOnline_teste.bak'
WITH FORMAT, INIT, NAME = N'MuOnline - Teste de Migracao', STATS = 10;
GO

If your server uses additional databases (for example Me_MuOnline, Ranking, Event), back up all of them. Transfer the .bak files to the VPS and restore them there:

RESTORE DATABASE [MuOnline] FROM DISK = N'C:\Backups\MuOnline_teste.bak'
WITH MOVE 'MuOnline'     TO N'C:\SQLData\MuOnline.mdf',
     MOVE 'MuOnline_log' TO N'C:\SQLData\MuOnline_log.ldf',
     REPLACE, STATS = 10;
GO

Step 3: recreate the SQL login and map the user

A classic problem after restoring: the database came over, but the SQL login the MuServer uses doesn't exist on the VPS, or exists with a different SID (an "orphaned user"). Recreate the login and realign it:

-- Create the login used by the MuServer (adjust the real name and password)
CREATE LOGIN [muserver] WITH PASSWORD = 'SenhaForteAqui', CHECK_POLICY = OFF;
GO

USE [MuOnline];
GO
-- Fix the orphaned user, linking it to the freshly created login
ALTER USER [muserver] WITH LOGIN = [muserver];
GO

Step 4: adjust the MuServer configuration files

Here is the heart of the network migration. Several files still point to the home PC's IP and to the old database credentials. Walk through them and adjust (the names/paths vary by version):

• Database connection: files such as MuServer\GameServer\Data\...ODBC or a connection .ini. Point them to 127.0.0.1 / localhost on the VPS (the database is on the same machine) and to the correct login/password.
• ConnectServer / server list: replace any old public IP with the VPS's new public IP. If you're going to use a domain, many setups let you put the domain in the file the client reads.
• Listen bind: confirm that the services listen on 0.0.0.0 (all interfaces) so they accept external connections.

Step 5: open the ports and the firewall on the VPS

Replicate the server's port scheme on the VPS: ConnectServer, GameServers, and, if the website lives there too, web. Block SQL and the internal ports. The breakdown by group (game/connect/web) is in the per-port firewall tutorial; the essential thing is to open only what the internet needs and restrict RDP to your IP.

Step 6: end-to-end test on the VPS

With the test copy running on the VPS:

1. Bring up the processes (DataServer, ConnectServer, GameServer) and check the logs to confirm they connect to the database without errors.
2. Temporarily edit your client to point at the VPS IP and try logging in, creating a character, entering a map, saving, and reconnecting.
3. Validate a simple event and the write to the database (create a test character and confirm it persists after restarting the server).

If everything works with the test copy, the VPS is ready. Now it's just the final switchover with the real data.

Phase 2 — The final switchover

Step 7: enter maintenance and stop the production server

At the agreed time:

1. Notify the players (an in-game/Discord message) and put the server into maintenance.
2. Stop all MuServer processes on the PC (GameServer, ConnectServer, DataServer). This guarantees nothing else writes to the database.
3. Confirm there are no active sessions before continuing.

Step 8: final, consistent backup

With the server stopped, generate the definitive backup — this is the one that carries the real progress:

BACKUP DATABASE [MuOnline] TO DISK = N'C:\Backups\MuOnline_final.bak'
WITH FORMAT, INIT, NAME = N'MuOnline - Migracao Final', CHECKSUM, STATS = 10;
GO

Repeat for all the auxiliary databases. CHECKSUM helps detect corruption at restore time. Transfer the .bak files to the VPS.

Step 9: restore on the VPS and bring it back up

1. Restore the final databases on the VPS (the same RESTORE command from Step 2, now with the final .bak files and REPLACE).
2. Re-run the orphaned-user fix (Step 3) if needed.
3. Bring up the MuServer processes on the VPS and watch the logs.

Step 10: switch the DNS (or distribute the new client)

• If you use a domain: change the domain's A record to the VPS's new IP. Since DNS propagation takes time, use a low TTL (e.g., 300s) configured in advance to speed up the switch.
• If the client points to a hardcoded IP: you'll need to distribute a patch/launcher with the new IP. That's why a domain is so strongly recommended — it avoids this rework every time.

Step 11: post-migration validation and shutting down the PC

1. Connect with a real client and validate login, creation, movement, saving, and reconnection.
2. Ask a few trusted players to test before reopening to everyone.
3. Confirm that events, ranking, and the shop/website work.
4. Keep the old PC intact for a few days as a fallback plan, without bringing the server back up on it (so you don't end up with two divergent databases). Only decommission it for good once the VPS has proven stable.

Common errors and fixes

Launch checklist

• VPS sized (CPU, RAM, NVMe disk) for the season and the audience
• SQL Server on the VPS at the same version/edition (or newer) as the PC
• MuServer copied with the same folder structure
• Test backup restored and server validated on the VPS (Phase 1)
• SQL login recreated and orphaned user fixed
• All configuration files pointing to the new IP/domain
• Services listening on 0.0.0.0 and ports open in the firewall
• RDP restricted to my IP and the KVM/VNC console tested
• DNS TTL lowered in advance
• Players notified of the maintenance window
• Production server STOPPED before the final backup
• Final, consistent backup (with CHECKSUM) of all databases
• Final restore applied and server live on the VPS
• DNS switched (or patch/launcher distributed)
• Post-migration validation with trusted players
• Old PC kept intact for a few days as a rollback

Migrating from a PC to a VPS is, at its core, an exercise in discipline: prepare everything calmly, freeze the server at the right moment, take a consistent backup, and switch the DNS with the environment already tested. Done in that order, the change happens with just a few minutes of downtime and without losing a single character — and your server gains the stability and protection that residential internet could never offer.

Frequently asked questions