Moving a game server without losing players

Migrating a server is not technically difficult. Copy the files, start the process, point the address at the new box. The part that goes wrong is never the copy — it is the week afterwards, when a third of your regulars never came back because for two days the address they had did not work.

Do the DNS work first, not last

If players connect by hostname, lower the TTL on that record days before you move. A record with a TTL of 86400 will be cached for a day after you change it, so a migration that takes twenty minutes leaves people disconnected for twenty-four hours.

Lower it to five minutes. Wait for the old TTL to expire — the full old value, not five minutes. Then migrate. Then raise it again once things are settled.

Skipping this is the single most expensive mistake in a move, and it is invisible while you make it, because your own resolver will have the new answer almost immediately. This is also the point at which people discover they never had a domain in the first place and have been handing out a raw address for two years.

Run both for a while

The instinct is to shut the old server down the moment the new one works. Do not. Leave it running, with a message of the day pointing at the new address, for at least a week.

Players who connect by saved IP will hit the old box. If it is gone, they see a connection failure and conclude the server died. If it is there and tells them where you went, they follow. That difference is most of your retention through the move.

For a Source server this is a sv_hostname change and a motd. For Minecraft it is the MOTD in server.properties, which appears in the client's server list without them connecting at all: the best possible place for this message.

Copy the data twice, verify once

Copy while the server is stopped. A world copied from a running server is a world mid-write, and the corruption will not show up until somebody visits that region.

Then start the copy on the new box and actually look at it: the spawn, a player's base, the plugin configs, the database. A migration that "worked" because the process started is a migration nobody checked. This is the same discipline as a backup you have actually restored from, and it fails for the same reason when skipped.

The things that break on a new box

Predictably, and worth checking in this order:

• File permissions. A copy made as root leaves files the service user cannot write. The server starts, runs, and fails to save.
• Absolute paths in configs and start scripts pointing at directories that no longer exist.
• Firewall. The new box has its own, and it is default-deny or default-allow, and either one is a problem you have not looked at yet.
• The query port. Forwarded and open on the old host, forgotten on the new one, which is why the server vanishes from listings while working fine for anyone with the address.
• Licence keys and API tokens tied to an IP.

Tell people before, not during

An announcement a week ahead, repeated the day before, costs nothing and changes the shape of the move entirely. Players who know what is happening wait. Players who find a dead server assume the worst, and some of them tell other people the server closed.

Put it wherever your community actually reads, which for most servers is Discord rather than the game, and put it in the MOTD as well, for the ones who only ever see the server list.

What a good move looks like

TTL lowered a week out. Announcement made. Server stopped, data copied, new box verified by hand. DNS switched. Old box left running with a forwarding message for a week. Firewall and ports checked from outside. TTL raised again.

That is perhaps two hours of work spread over ten days, and it is the difference between a migration nobody notices and one that costs you the players you spent a year gathering, which is the same margin that separates a quiet week from a dying server.