How to Migrate Your MU Server's Website to New Hosting Without Downtime

Migrating your MU Online server's website to new hosting is one of those tasks that looks scary at first glance, because the fear is always the same: players landing on a page that's down, registrations getting lost, or the site coming back broken at peak hours. The good news is that, with planning, a migration can be done with zero perceptible downtime — players keep logging in, registering, and voting while you swap the floor out from under their feet. The secret isn't speed, it's parallelism: you prepare and validate the entire site on the new host before sending any visitor there, and only then redirect traffic in a controlled way, keeping the old environment on standby until the dust settles. This tutorial walks through that method step by step, from the initial inventory to the DNS switch and the safe shutdown of the old host. The examples assume a PHP site with a database, the standard for MU servers, but the method works for any stack. Paths, panels, and service names vary by host, so adapt them to your provider.

Prerequisites

Migration is an operation on something that already works. If your site isn't live yet or you're still building the server, start with the guide on how to create a MU Online server and come back here when you need to change hosting.

• Full access to the old host (files, database, and configuration).
• A new host rented and accessible (a VPS or shared hosting with compatible PHP).
• Access to the domain's DNS panel (where you edit A/CNAME records).
• Access to the game's SQL Server firewall, to allow the new host's IP.
• A transfer tool (rsync, SFTP, or the panel's file manager).
• A planned low-traffic period for the final switch (the small hours, for example).

The concept: parallelism, not replacement

The classic mistake is treating the migration as an instant swap: shut down the old, turn on the new. That guarantees downtime and panic if anything fails. The zero-downtime method works the other way around — the two environments coexist:

1. You build the full site on the new host, pointing it at the same game database.
2. You test the new host by accessing it via its direct IP, without touching DNS.
3. Only when the new environment is 100% validated do you point DNS at it.
4. You keep the old host running throughout the entire DNS propagation.
5. You shut down the old one only once you've confirmed all traffic is going to the new one.

Because the game's database stays single and in place, there's no risk of losing registrations — both hosts read from and write to the same place.

Step 1 — Full inventory

Before copying anything, map everything the site needs. A forgotten item is exactly what breaks a migration:

Step 2 — Reduce the DNS TTL in advance

This is the most neglected step and the most important one for "no downtime." The TTL (time to live) defines how long providers keep your domain's IP cached. If it's set to 86400 (24h), an IP change can take a full day to propagate. 24 to 48 hours ahead of time, lower the A record's TTL to 300 seconds (5 minutes):

; Before (default)
servidorx.com.   86400   IN   A   200.100.50.10

; Adjusted 48h before the migration
servidorx.com.   300     IN   A   200.100.50.10

By doing this in advance, when you finally change the IP, the change propagates in minutes.

Step 3 — Prepare the new host in parallel

With the inventory in hand, build the new environment without touching DNS:

1. Install the same PHP version and all the extensions listed in the inventory.
2. Copy all the site's files. With SSH access on both sides, rsync is the most reliable:

rsync -avz --progress \
  -e ssh usuario@host_antigo:/var/www/site/ \
  /var/www/site/

1. Adjust the site's configuration file on the new host. The database credentials still point to the game's SQL Server — which doesn't move — so confirm that the new host can reach it over the network.

1. Allow the new host's IP through the game's SQL Server firewall:

New-NetFirewallRule -DisplayName "SQL Site Novo Host" `
  -Direction Inbound -Protocol TCP -LocalPort 1433 `
  -RemoteAddress 203.0.113.25 -Action Allow

1. Reissue the SSL certificate for the new host (with Let's Encrypt, generate it already pointing to the domain, validating via DNS if needed so it doesn't yet depend on the IP change).

Step 4 — Test the new host before the switch

Never migrate blind. Force your own machine to see the domain at the new IP by editing the local hosts file, without changing public DNS:

# Windows: C:\Windows\System32\drivers\etc\hosts
# Linux/Mac: /etc/hosts
203.0.113.25   servidorx.com www.servidorx.com

Now, in your browser, servidorx.com resolves to the new host, but only for you. Test everything:

• The home page loads and shows game data (rankings, online count).
• Registration actually creates an account in the database.
• Login works.
• The download page and voting operate.
• Cron jobs run on the new host.
• HTTPS is valid, with no certificate warning.

Only move on when all the flows pass. Afterward, remove the line from hosts to return to the normal state.

Step 5 — The DNS switch

With the new host validated and the TTL already low, make the switch during the lowest-traffic time. In the DNS panel, change the A record to the new IP:

; Final switch
servidorx.com.   300   IN   A   203.0.113.25

From here on, new visitors start landing on the new host as the 300s cache expires. Since the database is the same, anyone still landing on the old host during propagation also works normally — nothing is lost.

Step 6 — Monitor propagation

Track propagation by checking the record from several points. Locally:

nslookup servidorx.com 8.8.8.8
nslookup servidorx.com 1.1.1.1

Also use a global DNS checker to check multiple regions. When they all return the new IP, propagation is complete. Meanwhile, monitor the logs on both hosts to confirm that traffic is migrating and that no errors appear on the new one.

Step 7 — Shut down the old host safely

Don't shut down the old host as soon as you switch DNS. Wait for full propagation plus a safety margin (24 hours is prudent, covering providers that ignore TTL). Before shutting it down for good:

1. Confirm that the old host's logs have stopped receiving meaningful traffic.
2. Take one final full backup of the old files and database.
3. Remove the SQL Server firewall rule that allowed the old host's IP (if it's no longer used).
4. Only then cancel or shut down the old service.

Once everything has stabilized, restore the DNS TTL to a normal value (3600 or 86400) to reduce queries and ease the load on resolvers.

Common errors and fixes

Special case: migrating the database too

This tutorial assumes the game database stays in place — the most common and safest scenario. If you also need to move the database, zero downtime becomes much harder, because you can't have simultaneous writes to two diverging databases. In that case, plan an announced maintenance window: put the site into maintenance mode, take the final dump, restore it into the new database, point the site at it, and reopen. Don't try to migrate a database in production without freezing writes.

Launch checklist

• Full inventory (PHP, extensions, credentials, uploads, crons, SSL, .htaccess)
• DNS TTL lowered to 300s 24–48h in advance
• New host built with the same PHP version and extensions
• Files synchronized via rsync/SFTP
• New host's IP allowed through the game's SQL Server firewall
• SSL reissued and valid on the new host
• Full test via the local hosts file (registration, login, votes, crons)
• DNS switch made during low-traffic hours
• Propagation monitored with nslookup and a global checker
• Old host kept live until propagation completes + margin
• Final backup and safe shutdown of the old host
• TTL restored to a normal value after stabilizing

Frequently asked questions