How to Move Your Game Server to a New Host Without Losing Progress

Step 1: Inventory what you're moving

Most of what makes a server yours isn't the world file. Before touching anything, write down:

• Game and exact version (and Java version, mod loader version or framework version where relevant).
• Every mod or plugin with its version, plus its config and data folders. Keep the original download links too.
• Launch parameters and startup settings: world name, server name, ports, max players, any custom flags.
• Config files and who edited them: server.properties on Minecraft, serverconfig.xml on 7 Days to Die, and so on.
• Admin, whitelist, ban and permission data, because those are usually separate files from the world.
• Anything tied to the old address: server-list entries, Discord bots, status pages, domain records, API allow-lists.

If you've lost track of some of this, open the old server's file manager and read it. The mod folder and the launch settings tell you most of the story.

Step 2: Match versions before you copy anything

Game saves generally move forward, not backward. If your old server is on an older version than what the new host installs by default, the new server may silently upgrade the world on first load, and you can't undo that. Rules that avoid trouble:

• Install the same game version on the new host first. Upgrade later, on purpose, after a backup.
• Match the mod loader and every mod version. A mod that was updated since your world was last loaded may change data formats.
• Check the runtime too. Recent Minecraft server builds need a new Java release, so make sure the new server's Java matches the server jar. PaperMC's install notes cover Java 25, and you can confirm the requirement for your exact version on their downloads page.
• Remember Minecraft's 26.1 world-layout change. Paper now stores dimensions under world/dimensions/minecraft/, and the upgrade is one-way, so your first load of an old world on a new version should happen on a copy.

Step 3: Copy the data

1. Back up the old server

   Take a full backup and keep it somewhere that isn't either server. If you're unsure which files matter, copy the entire server directory.

2. Do a trial run on the new host

   Upload the backup to the new server and start it with no announcement. Confirm the world loads, mods run, and admins and permissions work. This is the point where a trial or a money-back window is useful.

3. Fix anything that doesn't load

   Compare the console output with the old server's. Usual suspects are a world name that doesn't match the config, a missing mod, or a version difference.

4. Freeze the old server and do the final copy

   On cut-over day, announce the downtime, stop the old server, take a fresh backup and upload it to the new host, replacing the trial data. This guarantees that no one plays on a world you've already copied.

5. Start the new server and test

   Join yourself first. Then have one admin and one regular player connect before you announce that it's live.

Copy methods: your new host's file manager, if it has one, works for small files, and SFTP is faster for big worlds. Use the connection details shown in the control panel and set the client's protocol to SFTP.

Step 4: Handle the new IP address and ports

A new host almost always means a new IP address, and sometimes a new port. Players who saved the old address in their server list will see a dead server until they update it. Check your game's default ports, and use the exact IP and port shown in your new control panel:

On a hosted server the ports are normally assigned for you, so don't change them by hand unless your host's documentation says to.

Use a domain name if you can. A record like play.example.com pointing at your server lets you change the IP later without telling anyone. Two practical points: lower the record's TTL (for example to 300 seconds) a day or two before the move so the change spreads quickly, and remember that a plain A record has no port. Minecraft Java supports SRV records (_minecraft._tcp) so players can leave the port off; the SRV target must point at an A record, not at a CNAME. Many other games don't support SRV, so players there still need to enter the port.

Step 5: Plan the downtime and the announcement

For a small server, the real downtime is the time needed to stop, copy and restart, often well under an hour. The part that costs players is confusion, so plan communication as carefully as the copy.

• A week ahead: post the date, the expected downtime window and a short reason (better ping, more capacity). Pick an hour when the fewest people play.
• A day or two ahead: lower DNS TTLs if you're using a domain.
• On the day: post when the old server goes down, then when the new one is up, with the address in the same message.
• After: leave the old server running for a few days if you can, with its name or message of the day pointing to the new address. In Minecraft that is the motd line, and in Valheim it is the -name argument. Ask players to stop connecting to the old one so progress doesn't fork.
• Update the places that still list the old address: your Discord, website, server-list sites, bots and status pages.

After the move, watch the server for a day. Watch the new server's CPU, memory and player count at your peak hours to see whether it is keeping up.

A short checklist to print

1. Old server inventoried (version, mods, launch settings, ports, admin data).
2. Same version and mod set installed on the new host.
3. Full backup taken and stored off both servers.
4. Trial load of the world on the new host passed.
5. Downtime announced with date, window and new address.
6. Old server stopped, final backup taken, uploaded and verified.
7. Admin and one regular player joined successfully.
8. Address updated everywhere (DNS, Discord, server lists, bots).
9. Old server left up briefly with a pointer to the new address, then retired.

Frequently asked questions