Moving a game server to a new host without losing the world

Migrating a game server is not technically hard. It is a file copy, a config edit and a DNS change. What goes wrong is almost always process: someone copies the wrong save, nobody tells the players, or the old host is cancelled before the new one is proven.

Here is the order that avoids all of that.

1. Do not cancel anything yet

Run both servers in parallel. The overlap costs you a few pounds and buys you the ability to go back if something is wrong. Cancelling the old server before the new one has run a full evening with real players on it is the single most common way this goes badly.

Most hosts, us included, will not charge you twice for the overlap if you tell them what you are doing — ask before you order.

2. Find out what your data actually is

This is the step people skip. "The world" is rarely one folder:

• Minecraft — the world directory, plus server.properties, ops.json, whitelist.json, plugin/mod config directories, and any MySQL database a plugin uses.
• Rust — the server/<identity> directory containing the map, player data and blueprints, plus Oxide or Carbon config and data folders.
• ARK — the Saved directory, which holds the world, player profiles and tribe data. Cluster servers also need the cluster directory or transfers break.
• Valheim — the .db and .fwl pair. Both, not just the .db.
• Project Zomboid — the Saves and Server directories, and the sandbox config.

If a plugin or mod stores anything in a database rather than a file, that database is part of your world too. Export it.

3. Take a backup you have actually verified

Download it. Open the archive. Confirm the world file is in there and is roughly the size you expect. A backup you have not opened is a hypothesis.

4. Stop the old server before the final copy

A running server holds the world in memory and writes periodically. Copying a live save gets you a snapshot from somewhere between the last two writes, which for most games is recoverable and for some is a corrupt chunk.

Stop it cleanly — not kill, stop — wait for the save-on-shutdown to finish, then copy.

5. Match the versions

The new server must run the same game version and the same mod versions as the old one. Newer usually works; older often does not, because save formats move forward and rarely back.

For modded servers this is the step that eats an evening if you get it wrong. Copy the mod list with version numbers, not just names.

6. Upload, start, and look at the console

Upload over SFTP or through the file manager, then start the server and read the console output. Missing mods, a bad config value or a permissions problem will all announce themselves in the first thirty seconds. Do not skip this and log in blind.

7. Update the address before you announce

If your community connects by IP, they need the new one. If they connect by a domain, update the DNS record — and remember that DNS caches, so change the TTL to something short a day or two beforehand if you can.

An SRV record is worth setting up while you are here: it lets players use play.yourclan.gg without a port, and it means your next migration is a DNS change rather than an announcement.

8. Then cancel the old one

After a full evening with real players. Not before.

Where we come in

We do this for free, including the parts above that are tedious. Open a ticket before you order and tell us what you are running; for anything more complicated than a single small world — clusters, large modpacks, database-backed plugins — we will do the migration ourselves and schedule the cutover for a time your community is asleep.

There is no charge for the migration and no double billing during the overlap. It is not generosity: a migration that goes badly is a refund request, and we would rather spend an hour getting it right.

If you are moving several servers at once, our community packages are built for exactly that and the same applies.