Moving a Server to a New Host Without Losing Players

Moving a game server to a new host is technically straightforward. You copy some files, start a process, and it works. The part that goes wrong is everything around the files: the address people bookmarked, the listing that now points nowhere, the regulars who tried once on Saturday, got nothing, and did not try again.

The migration that loses players is not the one that failed. It is the one that succeeded on a schedule nobody was told about.

Do this first, whether or not you are moving

Put the server behind a domain.

If your players connect to a raw IP address, then your address is a property of your host, and changing host means changing your address. Every bookmark breaks. Every forum post from the last three years points somewhere wrong. Every player who does not read your announcement simply finds the server gone.

With a domain, the address is yours. Moving becomes a DNS change and nobody has to be told anything.

This costs about ten dollars a year and it is the single highest-leverage thing an owner can do about a move, including a move you are not currently planning, because the day you need it is the day it is too late to set up. Custom domains and SRV records is the whole procedure, including the SRV trick that lets Minecraft players connect without typing a port.

If you are reading this because you are already mid-move on a raw IP, do the domain move and the host move at the same time. It is one disruption instead of two, and it is the last time you will have to do either.

Lower your TTL a week early

DNS records have a time-to-live: how long resolvers are allowed to cache the answer. Default values are often an hour or a day.

If your TTL is 86400 and you change the record, some players will continue resolving the old address for up to a day. They connect, get nothing, and conclude the server is down.

A week before the move, drop the TTL to 300 seconds. Then the cutover propagates in five minutes instead of a day. Put it back afterwards.

This is the step everyone does last and it is the one that has to be done first, because lowering the TTL only takes effect after the old TTL has expired. Lowering it an hour before the move accomplishes nothing.

The order that works

1. Get the new machine running the same software, before you move anything. Same game version, same plugins, same versions of those plugins. Start it, connect to it yourself, confirm it works with a fresh world. You are testing the environment, not the data.

1. Test the query path from outside. A server nobody can query vanishes from every list at once, and this is one of the most common post-migration surprises — the game port was forwarded, the query port was not. Test from a network that is not yours. How queries work and port forwarding both cover why these are frequently different ports.

1. Announce the window. A day or two of notice, with a time and an expected duration. This is what separates a migration from an outage in the mind of a player.

1. Take the old server down and copy the data. Stop it first. Copying a world or a database from a running server produces a file that is subtly corrupt in a way you will discover later.

5. Verify the data on the new machine before switching anything. Start it, connect, check that the world is the right one, that player data is present, that permissions survived. Do this while the old server is still there to fall back to.

1. Change DNS. With a low TTL this is minutes.

1. Watch for an hour. Under real load, not your one connection.

1. Keep the old machine for a week. Do not cancel immediately. A week of overlap costs one month's fee and buys you the ability to go back if something surfaces on day three.

What people forget

Permissions and ownership. Copying files as the wrong user produces a server that will not write its own data. It usually starts fine and fails on the first save.

Anything referencing an absolute path. Configs, scripts, cron jobs, backup destinations. A new host frequently means a different directory layout.

Backup jobs. They were configured on the old machine. They are not running on the new one. This is the migration mistake with the longest fuse: everything is fine for two months and then something happens and there is nothing to restore. Backups should be reconfigured and tested on day one at the new host.

Monitoring and alerts. Same problem. Whatever was watching the old address is now watching nothing. Monitoring is the thing that tells you the migration went wrong at 4am, so it should be the first thing working, not the last.

RCON. Different address, possibly different firewall rules. Check it before you need it, not during an incident. RCON explained covers why an exposed RCON port with a weak password is worse than no RCON at all, and a fresh machine is exactly where a default password gets left in place.

Your listing. If you moved from an IP to a domain, or to a different IP, the listing has to be updated or it queries an address that no longer answers. It will show offline, it will stop receiving visitors, and the uptime history will record a gap that was actually a successful migration. Update it the same day. If you do not currently control the listing, claiming it is a prerequisite.

Search and links. Anything pointing at a raw IP; forum posts, your website, video descriptions — now points at nothing. This is unfixable in retrospect and it is the strongest argument for the domain.

Choosing where to go

If you are moving because of a problem, be specific about which problem, because the answers differ.

Moving for performance. Establish first that the bottleneck is the machine. Servers are frequently limited by single-thread performance rather than core count, and by tick rate issues that are caused by plugins rather than hardware. Moving a badly-behaved plugin stack to a faster machine buys you a smaller version of the same problem. Hardware specs covers what matters.

Moving for latency. Check where your players are before choosing a region. Owners routinely host near themselves and then discover from their own stats that the community's peak is in a different timezone entirely. Choosing a region and why routing beats distance are both relevant, and the second one explains why the geographically nearest datacentre is sometimes not the fastest.

Moving for cost. Compare the whole cost, including DDoS protection and backup storage, which are frequently included in one price and billed separately in another. Dedicated versus VPS and what a server costs cover the real numbers.

Moving because the host is unreliable. The most legitimate reason, and worth acting on quickly. An unreliable host produces gaps in your uptime that strangers read as an unreliable community.

Telling players, without losing them

The technical move is a couple of hours. The communication around it decides whether anyone notices.

Announce twice and mean it. Once a few days out, once about an hour before. People miss the first one, and the second one catches everybody who is currently online, which is the group most likely to be affected.

Say what will not change. This is the part owners leave out and it is the part players want. "The address is the same, your builds are the same, your permissions are the same" removes the three questions everyone is about to ask. If something is changing: a new address, a lost world, reset permissions, say that plainly and early, because discovering it on the day is what produces the angry message.

Give a duration, and overestimate it. "Down for up to two hours" that takes forty minutes is a good outcome. "Down for twenty minutes" that takes two hours is an incident, even though the second server was up faster in absolute terms.

Post when it is done. Absence of a completion message leaves everyone assuming it is ongoing, and some of them do not check again that evening.

Watch your peak, not the clock. Do the move in the trough on your stats page, not at the hour that suits you. An owner who migrates at 8pm because that is after work has chosen the most expensive two hours of the week — every arrival during the window sees a dead server, and arrivals do not come back to check.

Expect a quiet first evening. Even a flawless migration produces a slightly thin night, because some people tried during the window. It recovers within a day or two. If it has not recovered inside a week, something is still pointing at the old address.

The migration nobody plans

Sometimes the move is not planned. The host goes down, the account is suspended, the hardware dies.

The things that make an emergency move survivable are all things you do in advance:

• A domain, so the address can be repointed rather than re-announced.
• A recent backup you have restored from once.
• A written list of your plugins and versions.
• A copy of your configs somewhere that is not the server.

None of these take long. All of them are useless if you start them after the incident.

Afterwards

Tell people it is done. The same channel as the announcement, and be explicit that the address is unchanged if it is. The absence of a "done" message leaves people assuming it is still ongoing.

Watch the numbers for a fortnight. A migration that lost people shows up as a step in the population that does not recover. If it appears, the cause is almost always someone still resolving the old address or a bookmark that broke.

Check the listing shows online. Not from your own machine; look at the page.

Then leave it alone. A migration is not an occasion to also change the ruleset, update the plugins and add a new mode. One variable at a time, for the same reason it applies to updates: when something is wrong next week, you want a single candidate rather than five.