How to Migrate Your Minecraft Server Without Losing Progress

Moving a Minecraft server to new hosting — or just to a fresh machine — is one of those tasks that feels risky because it kind of is: get one folder wrong and you can corrupt a world you’ve spent months building. The good news is that migrating cleanly is mechanical once you know exactly which files matter and in what order to move them. This guide covers a full migration with zero progress loss, including the mistakes that actually cause corruption.

What You’re Actually Moving

A “server” isn’t one file — it’s five separate categories of data, and each behaves differently during a migration:

• World data — the actual terrain, builds, and entities (the world folder(s): usually world, world_nether, world_the_end).
• Player data — inventories, stats, advancements (world/playerdata, world/stats, world/advancements).
• Plugins and their configs — the plugins/ folder, which often stores its own databases (economy balances, land claims, permissions).
• Server-level configuration — server.properties, bukkit.yml, spigot.yml, paper-global.yml, whitelist and ops files.
• The server jar itself — usually the one thing you should not copy over; download a fresh build instead (more on why below).

Step 1: Take the Server Fully Offline Before Copying

This is the single most common cause of corrupted migrations: copying world files while the server is still running. Minecraft writes region files (.mca) continuously, and copying a file mid-write produces a truncated, unreadable chunk. Always run /stop (or your panel’s stop button) and confirm the process has fully exited — not just “saving” — before you touch a single file.

Step 2: Back Up Before You Move Anything

Compress the entire server folder into a single archive (zip or tar.gz) on the source machine before transferring anything. This gives you a rollback point if something goes wrong mid-migration, and it’s dramatically faster to transfer one large archive over FTP/SFTP than thousands of small region and plugin files individually.

Step 3: Match Your Minecraft and Paper/Spigot Version Exactly

This is where most “my world got corrupted after migrating” reports actually originate — not from the transfer itself, but from opening an old world on a newer or older Minecraft version than it was created on. Chunk data formats change between major versions. Downgrading (loading a 1.21 world on a 1.20 jar) will silently break chunks. Upgrading is generally safe, but you should let the new server fully load and re-save each chunk once before making further changes, and back up first regardless.

Check your old version_history.json file inside the world folder to confirm exactly which version last touched the world, and download that same version’s server jar for the new host before doing anything else.

Step 4: Transfer the Right Folders — Not the Whole Directory

Don’t copy logs, cache, or old crash-report folders — they’re dead weight and can occasionally confuse a fresh install. Move only:

• The world folder(s) — world, world_nether, world_the_end (or your custom-named equivalents)
• plugins/ in full, including any subfolders it created for its own data
• server.properties, whitelist.json, ops.json, banned-players.json, banned-ips.json
• bukkit.yml, spigot.yml, and the config/ folder if you’re on Paper

Download a fresh copy of the server jar on the new host rather than copying the old one — this avoids accidentally carrying over a corrupted or outdated jar, and confirms the new host’s Java version is actually compatible before you commit your world data to it.

Step 5: Watch Out for Plugins With External Databases

Economy plugins (Vault-based), land claim plugins (GriefPrevention, WorldGuard), and some permission managers (LuckPerms) can store their data in an external MySQL database rather than a local file — check each plugin’s config for database connection settings before assuming a folder copy captured everything. If a plugin used an external database on the old host, you’ll need to export that database separately and either point the new server at the same database or import it into a new one on the destination host.

Common Mistakes That Corrupt Migrations

• Copying while the server is running — always stop it fully first (see Step 1).
• Loading a world on a different major Minecraft version without checking version_history.json first.
• Zip corruption on transfer — always verify the archive’s file count or checksum matches after upload, especially over unstable connections.
• Forgetting external plugin databases — a folder copy alone won’t capture economy or claims data stored in MySQL.
• Skipping the backup step because “it’ll probably be fine” — it’s the only safety net if something above goes wrong.

Frequently Asked Questions

Can I migrate between different hosting providers?

Yes — the process above is identical whether you’re moving between two different hosting companies or just to a new plan with the same host. The only host-specific detail is how you access files (FTP/SFTP vs. a panel’s file manager vs. SSH), not the migration steps themselves.

Will my players lose their inventories or builds?

No, as long as the world and playerdata folders transfer completely and the server was stopped cleanly before copying. Corruption almost always traces back to copying mid-write or a version mismatch, not the migration process itself.

How long should a migration take?

For a small-to-medium world (under a few GB), expect 15-30 minutes total including the backup, transfer, and first restart. Large worlds (10GB+) can take an hour or more depending on your upload/download speeds — this is another reason to compress into a single archive rather than transferring thousands of individual files.

Conclusion

A clean migration comes down to five things: stop the server fully, back up before touching anything, match your Minecraft version exactly, move only the folders that matter, and check for plugins with external databases. Follow that order and there’s no reason a server move should cost you a single block of progress.