Your players do not care that you switched hosts. They care that their builds load, their inventories are intact, and the server opens at the promised time. That is why a Minecraft hosting migration checklist matters: the risky part is rarely copying files. It is moving the right files, preserving version compatibility, and testing before your community finds the problem first.

A good migration should feel boring. Your world comes online, TPS stays healthy, plugins or mods behave normally, and nobody loses a week of progress. Here is how to make that happen without turning server transfer day into an emergency.

Start with a clean migration window

Do not begin by dragging folders into a new control panel. Start by deciding when the old server stops accepting changes. Any player activity after your final backup can create missing inventory data, rolled-back claims, or a world that no longer matches its database.

Announce a maintenance window, then stop the server cleanly from the panel. Avoid force-killing it unless it is frozen. A normal shutdown gives Paper, Purpur, Forge, Fabric, and plugins time to write player data and save chunks.

Before the shutdown, record the basics of your current setup: Minecraft version, server software and build, Java version, allocated RAM, startup command, port, and active plugins or mods. This takes five minutes and saves a lot of guesswork later. A Paper server on 1.21.x is not automatically compatible with a random newer Paper build, and modpacks can be even less forgiving.

Write the setup down in one line

Before you stop the old server, save something like 1.21.4 · Paper · Java 21 · Xmx 6G · port 25565 · 38 plugins · LuckPerms on MySQL next to your backup. When the new server behaves differently, that line tells you in seconds whether the versions still match — instead of an evening of guessing.

What to back up

Your full server directory is the safest starting point. Download it as an archive if your current host allows it, or use SFTP to copy it locally before uploading to the new server. Keep a second copy somewhere outside both hosting accounts until the migration has been stable for several days.

For most servers, the files that matter are not limited to the main world folder. You need the world and its dimensions, configuration files, permissions, player data, plugin data, and any external databases your setup uses. If you run BungeeCord or Velocity, proxy configuration and backend server settings need their own review.

At minimum, confirm that your backup includes these distinct pieces:

  • Your main world folder, plus the Nether and End folders if they are stored separately
  • plugins, mods, config, defaultconfigs, and any custom datapack folders
  • server.properties, eula.txt, ops.json, whitelist.json, banned-players.json, and banned-ips.json
  • Player data, including inventories, ender chests, advancements, stats, and plugin-specific data
  • Databases such as MySQL or SQLite files used by claims, economy, permissions, shops, or web maps

Do not assume that every plugin keeps data inside its own folder. LuckPerms may use MySQL. CoreProtect often uses a database. A claims plugin can store land ownership in SQLite or MySQL. If you migrate only the visible plugin JARs, the server may start normally while your ranks, logs, homes, or claims appear to vanish.

Match software before you upload anything

The new host should run the same Minecraft version and the same software family first. Move from Paper to Paper, Forge to the same Forge version, or Fabric to the same Fabric loader and Minecraft version. You can upgrade later, after the move is verified. Combining a host migration with a major game update is how simple troubleshooting turns into a dozen possible causes.

Java is part of that compatibility check. Modern Minecraft versions commonly require newer Java releases, while older Forge packs may depend on a specific version. If your old server starts with custom JVM flags, save them. Some flags improve garbage collection behavior, but blindly carrying every old flag forward is not always smart. Good Ryzen or EPYC CPU performance and fast NVMe storage help chunk generation and TPS, but incorrect Java or a broken mod dependency can still stop a server cold.

Check your plan resources honestly. If the old server regularly ran at 85 to 95 percent RAM usage, moving it to the same amount of memory leaves no room for growth — the RAM calculator helps you pick a size with headroom. On the other hand, buying a huge RAM allocation will not fix a plugin that runs an expensive task every tick. For SMPs, CPU single-core speed, clean configs, view distance, simulation distance, and plugin quality all affect the experience.

Upload, then check the file structure

Deploy the correct server type from your new host's panel before uploading files. Once the initial installation is complete, stop it. Then upload your backup through the file manager or SFTP.

Be careful not to create an extra folder level. A common mistake looks like this: the panel's server root contains a folder named my-server-backup, and the actual server.jar, world, and plugins folders are trapped inside it. The server will either generate a fresh empty world or fail because it cannot find the expected files. Also check that level-name in server.properties matches the name of your world folder.

If your host provides automatic backups, enable them before the first production launch. This is not overkill. It gives you a recovery point after the upload and before anyone joins. Elysium is built around that kind of low-friction setup: fast NVMe storage, managed Minecraft deployments, and automatic backups remove a lot of the boring infrastructure work, but you still need to verify the data you bring over.

Test privately before opening the doors

Start the server with the whitelist enabled. Join with an admin account and test the parts of the server players will notice immediately. Check your spawn, a few far-out bases, Nether portals, the End, player inventories, ranks, homes, claims, shops, and any resource pack prompt.

Watch the console during startup. Warnings are not always fatal, but repeated errors deserve attention. Missing dependency errors, failed database connections, incompatible plugin APIs, or mod registry mismatches should be fixed before the public launch. Do not ignore a red console simply because the server lets you connect.

Then check performance under realistic settings. Run around new terrain, teleport between worlds, trigger commonly used commands, and watch TPS and memory usage. If TPS drops right after the move, compare server.properties, Paper or Purpur configs, Java version, and view-distance settings with the old environment. It may be a configuration difference rather than a hosting issue.

For modded servers, have at least one player test with the exact modpack used by your community. A server can boot while a missing client-required mod prevents players from joining. For public servers, test proxy routing, forced hosts, forwarding secrets, and backend IP settings before changing DNS or advertising a new address.

Cut over without confusing players

Once testing passes, decide whether you need a final sync. If players were allowed back onto the old server during testing, shut it down again and copy any changed world and player data from the old server. If it stayed offline, your original transfer remains the source of truth.

Update your domain or server address only when the new server is ready. If your DNS record changes, remember that some players may reach the old address briefly due to caching. Keep the old server offline during this period. Two live copies of the same world invite split progress and support headaches — our guide to switching hosts without downtime covers the cutover in more detail.

Leave the whitelist on for the first few minutes of public access if you expect a rush. Watch the console, TPS, RAM, and connection errors. Then open the server and stay available. A quick response to one missing rank or failed claim builds more trust than pretending migrations never have edge cases.

Keep the rollback plan until the server proves itself

Do not delete the old host account or local backup the moment players log in. Keep the original files and your final pre-migration backup through at least several normal play sessions. Give people time to visit distant bases, use less common commands, and notice data tied to plugins they only use occasionally.

If something is wrong, resist the urge to overwrite files while players are online. Stop the server, make a fresh backup of its current state, identify the missing component, and restore only what is needed — the backup restore guide walks through a safe partial restore. A clean rollback plan turns a migration issue into maintenance. No plan turns it into lost progress.

The goal is not a dramatic move to a new host. It is a server that feels exactly like home when your players join — just faster, more stable, and much easier to run.

Rather not run the checklist yourself?

Elysium can move your server for you — worlds, plugins, mods, configs, and player data — onto Ryzen and EPYC hardware with NVMe Gen4 and automatic backups. Leave a request on the migration page, read how our migration works, or pick a plan on the order page.