Moving a game server without losing your players

A migration is not technically difficult. It goes wrong through timing: the world copied while it was still being written, or an address changed before anybody was told. The order that works is: lower the DNS TTL a day early, build the new server completely and start it once with nobody connecting, stop the old server, copy the data only after it has fully stopped, verify with your own client, change DNS, and leave the old server stopped but present for a week. Everything else in this post is the detail behind those seven steps, and the detail is where the worlds get lost.

Budget an hour, most of which is waiting. The actual player-facing downtime should be five to fifteen minutes.

What actually goes wrong#

Three failures cover nearly every migration that ends badly, and they are all avoidable.

The copy was taken from a running server. A world file or database that is being written to is not a file, it is a file mid-write. The copy usually loads, which is the cruel part, and then fails days later as one chunk that crashes every client who walks into it, or a player who lost three days of progress. There is no way to check this at the time. Stop first.

The address changed before the players did. A domain with a 24-hour TTL does not change in 24 hours, it changes over 24 hours, and during that window half your players reach the old machine and half reach the new one. If the old machine is still running, they are playing on two worlds that will never be reconciled.

The versions do not match. The new host installed the latest build while your world and your mods are two versions behind. Nobody can connect, or worse, the world is opened by a newer version and quietly upgraded, which is not reversible without the backup you did take.

The order that works#

1. A day or two before, lower the TTL on the DNS record players use, from whatever it is to 300 seconds. Do not change anything else yet.
2. Build the new server completely. Same game version, same mod or plugin versions, same configuration, same ports. Start it once on a throwaway world to prove it starts, then stop it.
3. Announce the window. A day's notice and an in-game message an hour before is enough for a friend group; a public server wants three days and a pinned post.
4. Take a backup of the old server and download it. This is the rollback, and it is not optional.
5. Stop the old server. Cleanly, through the panel's Stop rather than Kill, and wait for the save confirmation in the console.
6. Copy the data to the new server. Archive it first, move one file, unpack it there.
7. Start the new server and connect yourself. Walk to the base, check a chest, check permissions, check that your admin rights work.
8. Change DNS to the new address, or announce the new address if there is no domain.
9. Leave the old server stopped but present for at least a week. Delete it when nobody has complained for seven days.

Step 5 is the one people try to skip, because it is the only step that costs downtime. Copying a live world to save five minutes is the single most expensive shortcut in server administration. The five minutes is the cheapest part of the whole move.

What to copy, by game#

"Copy the world" is shorthand for three separate things: the world data, the configuration, and the identity files that say who is an admin and who is banned. Miss the third and your first evening on the new host is spent explaining to people why they are not opped.

Two notes that apply to all of them. First, the world name and the folder name are usually the same string, and the new server will silently generate a fresh world if that string does not match exactly, including capitals. Watch the start-up log for a line saying it loaded your world rather than created one. Second, anything backed by a database - a permissions plugin, an economy, a logging plugin such as CoreProtect, a FiveM framework - keeps its real state in the database, not in the world folder. Export it separately.

For a PostgreSQL or MongoDB instance that is pg_dump or mongodump with the server idle:

$ pg_dump -h old.example.net -U appuser -Fc appdb > appdb.dump$ pg_restore -h new.example.net -U appuser -d appdb --no-owner appdb.dump$ mongodump --uri "mongodb://user:pass@old.example.net:27017/appdb" --out dump/

For the small database slot that sits beside a game server, the export is a .sql file out of phpMyAdmin and an import on the other side. Keep an eye on the character set: a database exported without it and imported with a different default is how accented player names turn into question marks. Database backups and restores covers the formats and the traps in more detail.

Copying the files without it taking all night#

SFTP is fine for a world and painful for a mod folder, because every file costs a round trip and a modpack is 4,000 small files. Archive first, always:

$ tar -czf world-2026-09-21.tar.gz world world_nether world_the_end$ sha256sum world-2026-09-21.tar.gz

Then move the one archive and unpack it on the far side. On RE:NODE the file manager unpacks archives in place, so the whole transfer is two drag-and-drop operations rather than an SFTP session that stalls at 62 per cent. Check the hash on arrival if the transfer was large or the connection was unreliable; five seconds now against a corrupt world later is a good trade. SFTP and the file manager has the connection details and the case for each.

If both ends are machines you have shell on, rsync is better than anything else, and the --dry-run first is worth the extra minute:

$ rsync -avz --dry-run /home/mc/world/ user@new.example.net:/home/mc/world/$ rsync -avz --delete /home/mc/world/ user@new.example.net:/home/mc/world/

The fastest legitimate shortcut is to skip the copy entirely: take a backup on the old host, download it, upload it to the new one, restore. That is the same bytes with one fewer chance to get the file list wrong, and it has the pleasant side effect of proving your backup restores. If you have never done that, do it before you need it - testing a restore before you need it is the whole argument.

DNS, TTL and the address players actually typed#

If players connect to a name rather than a number, the move is a record change. If they connect to a number, the move is an announcement, repeated, for weeks. This is why a subdomain in front of the address is worth setting up long before you need it, and why subdomains for servers is a post about migrations as much as about DNS.

The mechanics:

• Lower the TTL a day or two in advance, not on the day. A record with a 3,600-second TTL takes up to an hour to leave caches after you lower it, and only then does the new short TTL apply. Lowering it at cutover time buys you nothing.
• 300 seconds is a sensible floor. Some resolvers clamp anything shorter, and a few ignore your value entirely and use their own minimum. Plan for the change to take two or three times your TTL in the worst case.
• Raise it back to 3,600 or more a week after the move. A permanently short TTL means every player's client does a lookup constantly, for no benefit.
• Check propagation from outside your own network, because your own resolver is the least representative one available:

$ dig +short play.example.com$ dig +short @1.1.1.1 play.example.com$ dig +short SRV _minecraft._tcp.play.example.com

Minecraft Java is the one game where an SRV record genuinely earns its place, because it carries the port as well as the host and lets players type a bare domain. Bedrock clients do not follow SRV records at all. SRV records for Minecraft covers the format; DNS records explained covers everything else, including why the change you made is not visible yet.

For the Steam-family games - Valheim, Counter-Strike, Project Zomboid, Palworld and the rest - there is a second problem no DNS record solves. The in-game favourites list stores the address the player entered, and often the resolved IP, and the server browser finds servers by address rather than by name. A player who favourited 203.0.113.10:2456 a year ago will keep trying that number regardless of what you do to your zone. Plan to tell those players directly. Connecting a domain to a game server explains which games follow a name and which do not.

Moving between plans is not a migration#

Most of the above applies to changing host. Changing size, on the same host, usually should not involve any of it.

On RE:NODE, changing plan does not rebuild the server: the limits on the container you already have are adjusted, so the world, the config, the ports and the address all stay exactly where they were. That is not a migration and it needs no cutover, no DNS change, and no announcement. If you are running out of memory rather than running out of patience with your host, that is the operation you want. When to upgrade your plan covers how to tell which problem you have, and CPU vs RAM for game servers covers the diagnosis behind it.

The same logic applies in reverse: if the reason for the move is lag, establish first that the new place will actually be better. Distance and route quality are physical, and a server in one country will not be faster for players in another just because the panel is nicer. Measure before you move - latency, jitter and packet loss is the method, and choosing where your server lives is the reasoning.

Verify before you point anyone at it#

The checklist takes ten minutes and catches nearly everything:

1. The start-up log says it loaded your world, not that it generated a new one. Check the seed or the world size if you are unsure.
2. Connect yourself and go somewhere specific: your base, a spawn build, a chest you know the contents of.
3. Check your own permissions. Admin lists are the most commonly forgotten file, and the symptom is you discovering it in front of everyone.
4. Check the plugins or mods loaded, by count and by version, against the old start-up log. A plugin that failed to load will have said so once, near the top.
5. Check the ports, including the query port. A server that runs but never appears in a browser is nearly always one missing UDP port. Game server ports explained has the pairs.
6. Check whatever writes: place a block, save, restart, confirm the block is still there. This proves the save path works, which is the one failure a read-only test cannot find.
7. Take a backup of the new server before the first player joins, so you have a clean starting point on the new host.

When it goes wrong, roll back#

You have a rollback for exactly as long as the old server exists and has not been started again. That is the entire reason step 9 is to leave it stopped rather than to delete it.

If the new server fails within the first evening: stop it, start the old one, point DNS back, and post a short message saying the move is delayed. You will lose whatever was played on the new server, which is why you want to find the problem in the first hour rather than the third day.

If the problem appears later - a corrupted region, a missing database table, an economy that reset - you are restoring from a backup rather than rolling back, because the old server's data is now days stale. This is where the download you took at step 4 earns its keep. Keep it until the new server has run for a fortnight without incident.

Two practical warnings about relying on the host's own backups as your rollback. They live with the server, so cancelling the old plan takes them with it, locked or not. And a backup you have never restored is a hypothesis - backups that actually restore exists because that sentence is true far more often than people expect. Download one copy to your own machine before you cancel anything.

Troubleshooting a move that already went wrong#

The new server generated a fresh world. The world name in the config does not match the folder or file name. The original is still on disk, untouched. Fix the name, restart, and do not let anyone play on the new one in the meantime.

Players get "outdated server" or "incompatible version". The new install is a different build. Pin it to the exact version the world came from, then upgrade deliberately afterwards. For Minecraft specifically, Minecraft version upgrades covers doing that safely.

Everything works except one plugin. Its data lives in a database you did not export, or in a folder outside plugins/. Check its own config for a path or a connection string.

Half the players see the old server, half the new. The TTL has not expired everywhere. Stop the old server immediately - that is the two-worlds failure in progress - and wait it out.

Nobody can connect at all and the console looks fine. Ports. Then the firewall. Then whether the address you gave people is the one the server is actually bound to.

The world loads but is hours behind. The copy was taken from a running server, or from a backup older than you thought. Check the timestamp on the archive before assuming the transfer dropped something.

FAQ#

How much downtime does a server move need?

Five to fifteen minutes of actual outage if you prepare properly: the time to stop the old server, move one archive, and start the new one. The DNS change adds a tail of up to a few times your TTL during which some players still reach the old address, which is why the old server must be stopped rather than left running.

Can I copy the world while the server is running?

No. It will usually appear to work and will occasionally produce a world that corrupts days later, with no way to tell at the time which one you got. Stopping cleanly also forces a final save, so the copy you take is the current state rather than the state at the last autosave.

Do my players keep their characters and inventories?

In most games, yes, because that data lives in the world or in the server's player files, and you copied both. Valheim is the exception worth knowing: characters live on each player's own machine and travel with them, so a Valheim move never touches player inventories at all.

What if players connect by IP and I have no domain?

Then the move is an announcement rather than a record change, and you should plan three channels: in-game before the move, your Discord or forum, and the old server's name in the browser once you restart it as a signpost. Set up a subdomain afterwards so that the next move is a DNS record instead.

Should I move the backups too?

Download at least one full backup to your own machine before cancelling anything at the old host. Host backups are tied to the server they protect and disappear with it, so a copy that lives somewhere else is the only one that survives the cancellation.

How long should I keep the old server?

A week after the last complaint, minimum. It costs one more month of a small plan at worst, and it is the only rollback you have that does not involve a restore. Stopped servers are not doing any harm.