How to migrate your Minecraft server to a new host

Moving a Minecraft server sounds scary, but it's really just copying the right folders to a new machine and pointing your friends at the new address. By the end of this guide you'll have your full world, plugins, configs, and player data running on a fresh host with nothing lost. This is for anyone running a Java Edition server (Paper, Spigot, Vanilla, or similar) who wants to switch hosts without rolling back progress or annoying their players.

Before you touch anything, make a full backup

The single most important rule of any migration is this: never delete the old copy until the new one is proven to work. As long as the original server files still exist somewhere, you can always start over. So step one is a complete backup of the current server.

If you have shell access on the old host, the cleanest way is to compress the entire server directory into one archive. From the folder that contains your server (usually one level up), run something like this:

cd /home/container
tar -czvf minecraft-backup-2026-06-27.tar.gz server/

That produces a single .tar.gz file holding everything. The date in the name helps you keep track if you make more than one. If you're on Windows, right click the server folder and choose "Send to" then "Compressed (zipped) folder" instead.

If your old host uses a panel (the Pterodactyl style panel that Bytte.cloud and many others run), there's usually a Backups tab. Click "Create backup", wait for it to finish, and download the file. Either way, the goal is the same: one safe copy you can restore from if anything goes wrong.

Stop the old server cleanly so the world actually saves

Minecraft keeps a lot of world data in memory while it runs. If you kill the process or yank the files out from under a live server, you can copy a half written region file and end up with corrupted chunks. So always shut the server down properly first.

From the in game console or your panel console, run:

save-all
stop

The save-all command flushes everything to disk. The stop command shuts the server down in an orderly way. Wait until you see a line like this in the console before you do anything else:

[Server thread/INFO]: Saving worlds
[Server thread/INFO]: Saving chunks for level 'ServerLevel[world]'
[Server thread/INFO]: ThreadedAnvilChunkStorage (world): All chunks are saved

Once the process has fully exited, the files on disk are safe to copy. Don't restart it. You want it stopped for the whole move so nothing changes mid transfer.

Know exactly which files to copy

You don't need to copy the server jar or the libraries folder. You'll get a clean jar on the new host. What you do need is your data and your configuration. Here's the list that matters for a typical Paper or Spigot server.

A note on world folder names. Those three names (world, world_nether, world_the_end) are the defaults. If you set a custom level-name in server.properties, your folders will be named differently, so check that file and copy whatever folders actually exist. The Nether and End folders are usually named after the main world with a suffix.

If you run a network or have separate world folders per game mode, copy all of them. When in doubt, copy more rather than less. Extra files won't hurt anything.

Step 1: Set up the new host first

Before you upload, get the new server ready to receive the files. Create the server on the new host, whether that's a fresh panel install or a directory on a VPS. Let it generate its default files once, then stop it. Now you have a clean target with the correct folder structure, and you're about to overwrite the parts that matter with your own data.

This is also the moment to match versions, which we'll cover in detail below. Get that right now and you'll save yourself a headache later.

Step 2: Transfer the files with SFTP or the panel

There are two common ways to get your files onto the new machine. Pick whichever fits your setup.

Option A: SFTP

Most hosts give you SFTP details: a host address, a port, a username, and a password. A free client like FileZilla works well. Connect, then drag your backed up folders from the left (your computer) to the right (the server). If you downloaded a single archive, upload that one file and unpack it on the server instead, which is much faster than transferring thousands of small region files one by one.

If you have shell access, command line SFTP or scp is even quicker. To push your archive up:

scp -P 2022 minecraft-backup-2026-06-27.tar.gz user@new-host-ip:/home/container/

Then SSH in and extract it in place:

tar -xzvf minecraft-backup-2026-06-27.tar.gz

Option B: The host panel

If your new host runs a panel, the File Manager often has an upload button and can pull from a URL or accept a dropped archive. Some panels even let you upload a backup file directly and restore it. Upload your .tar.gz or .zip, then use the panel's "unarchive" option to expand it. This avoids slow SFTP transfers entirely.

However you do it, make sure the folders land in the right place. The world folder and server.properties should sit in the server's root directory, right next to the server jar, not nested inside an extra folder. A common mistake is extracting an archive and ending up with server/world/ when you needed world/. We'll come back to that in troubleshooting.

Step 3: Match the server version and Java version

This step trips people up more than any other. Two things must line up.

First, the server software and Minecraft version need to match what your world was created and last opened with. A world saved on Paper 1.20.4 should be opened on Paper 1.20.4 on the new host. You can usually go up a version safely, but you can almost never go down. If the old server ran 1.21.1, don't put a 1.20 jar on the new host. To check the exact version your old server ran, look at the console log on startup or run /version in game before you shut it down. The startup banner looks like this:

Starting minecraft server version 1.21.1
This server is running Paper version 1.21.1-89-master

Second, the Java version matters. Modern Minecraft needs a recent Java. As a rough guide, 1.20.5 and newer want Java 21, while 1.17 through 1.20.4 run on Java 17. On a panel you usually pick the Java image from a dropdown. On a VPS you can check what's installed with:

java -version

You should see output like this:

openjdk version "21.0.3" 2024-04-16
OpenJDK Runtime Environment (build 21.0.3+9)

If the version is too old, install a newer one. On Debian or Ubuntu that might be sudo apt install openjdk-21-jre-headless. Get both the Minecraft version and the Java version right before you start the server, and most migration problems simply never happen.

Step 4: Start the new server and check the console

With your files in place and versions matched, start the server. Watch the console closely on this first launch. A healthy startup loads your world and your plugins without red error lines. You're looking for confirmation that it found your existing world rather than generating a new one. If you see "Preparing spawn area" running through your existing builds and your plugins reporting they enabled, you're in good shape.

If the server generated a brand new flat or random world, stop immediately. That usually means the world folder wasn't in the right place or level-name doesn't match your folder name. Don't let players join a new world, or you'll have two separate saves to reconcile later.

Step 5: Test privately before you announce the move

Resist the urge to tell everyone the new IP right away. Connect yourself first. Join the server, teleport to spawn and a few known builds, and confirm your inventory and progress are intact. Check that your plugins behave: economy balances, claims, ranks, and permissions all carry over in the plugin data you copied, so verify a couple of them.

If you use a whitelist, you can keep the old server's IP private during this window so only you can poke at the new one. Once you're happy, you're ready to flip the switch.

Step 6: Update the address you share, plus DNS and SRV records

Your new host gives you a new IP address and port. The simplest move is to just share the new ip:port with your players. But if you use a domain name, you'll update DNS so the same friendly address points at the new machine.

For a basic setup, edit the A record for your domain or subdomain so it points to the new server's IP. For example:

Type: A
Name: mc
Value: 203.0.113.45
TTL: 300

That makes mc.yourdomain.com resolve to the new IP. If your server runs on a non standard port (anything other than 25565), an SRV record lets players connect using just the domain without typing the port. It looks like this:

Type: SRV
Name: _minecraft._tcp.mc
Priority: 0
Weight: 5
Port: 25571
Target: mc.yourdomain.com
TTL: 300

With that in place, players type mc.yourdomain.com and Minecraft quietly finds port 25571 for them. Set a low TTL (300 seconds is fine) a day before you migrate so the change spreads quickly. DNS changes are not instant, so give them time to propagate, which can take anywhere from a few minutes to a few hours.

Troubleshooting common migration problems

Even careful moves hit a snag now and then. Here are the issues we see most often and how to fix them.

Chunk errors or "corrupted" world

If you see errors about region files or chunks failing to load, the most likely cause is a transfer that copied region files while the old server was still writing to them, or an interrupted upload. Go back to your backup and re-transfer the affected world folder, and double check the old server was fully stopped first. A single client like FileZilla can also silently fail on some files in a huge batch, which is why uploading one archive is more reliable than thousands of loose files.

Plugins missing or not loading

If a plugin doesn't show up, check that its jar actually made it into the plugins folder and that it supports your Minecraft version. A plugin built for 1.20 may refuse to enable on 1.21. The console will tell you which plugin failed and often why. Update those plugins to a build that matches your new server version.

The world generated fresh instead of loading yours

This is almost always a path or naming problem. Open server.properties and find level-name. The value there must match your world folder name exactly. If level-name=world but your folder is called survival, either rename the folder or change the property. Also confirm the folder sits in the server root and isn't buried one level too deep inside an extra directory from extracting an archive.

Wrong file paths after extracting

If unpacking an archive left you with a nested folder like server/world/, move the contents up one level so the world folders sit beside the server jar. From shell:

mv server/*.
rmdir server

Players still connect to the old server

If people land on the old host after you migrate, DNS hasn't fully propagated yet, or their game cached the old address. Wait for the TTL to expire, ask them to fully restart their client, and as a safety net, shut the old server down (don't delete it) so anyone on the stale address gets a clean "can't connect" instead of joining outdated data.

Wrapping up

A clean migration comes down to a few habits: back everything up first, stop the old server properly, copy the world and plugin data rather than the jar, match your versions, and test privately before you announce anything. Keep the old copy around for a week or so until you're sure the new host is solid, then archive it as a safety net. Do it in that order and your players will log in to find everything exactly where they left it, with no idea you moved the whole thing under their feet.