Move a Minecraft Java server to a new host without losing progress

Moving a Java server is more than uploading its terrain. A faithful migration may include world dimensions, player inventories, permissions, allowlists, datapacks, plugins, mods, configuration, and the server identity settings that connect those pieces. Treat the old host as the rollback source until the new host passes a private acceptance test.

Inventory the server before scheduling downtime

Record the exact Minecraft version, Java runtime, server software and build, loader, mods, plugins, datapacks, startup flags, port, online mode, difficulty, view distance, and any proxy arrangement. Export plugin lists and save screenshots or text copies of panel-only settings that do not live in the server folder.

Identify every active world folder. Vanilla commonly uses the configured level plus dimension data, while Paper documents a different folder arrangement for some migrations. Multiworld plugins and modded dimensions can add more. Do not assume that a folder named world contains the entire server state.

Also note where player-facing addresses are controlled: DNS, a host-provided subdomain, a proxy, or a non-default port. Lowering DNS time-to-live before the move can make a later cutover faster, but only change it if you control the record and understand the provider's propagation behavior.

Create one authoritative stopped backup

Announce a maintenance window and prevent new joins. Use the server console's save-all when appropriate, then issue stop and wait for the process to exit. The migration archive must be taken after the final write; copying a live server can combine world regions and player files from different moments.

Back up the complete server directory unless the destination explicitly requires a selective import. Keep the archive outside both hosts and record its size. If your tools support a checksum, compare it after download and upload. A checksum does not prove that the world is playable, but it does prove that the archive did not silently change in transit.

Do not cancel the old host or delete its files. The stopped old server is your fastest rollback until the new one has run safely.

Build a compatible destination first

Install a compatible Java runtime and the same Minecraft server version, software, loader, mods, and plugins. Paper's migration documentation highlights software-specific world layouts, so follow the destination software's current instructions when moving between vanilla, Spigot, Paper, Fabric, Forge, or another stack.

Start the empty destination once only when the host requires it to create folders or accept its license. Stop it before uploading the real data. Archive the generated test files rather than mixing them into the migration copy.

Check disk space, file ownership, memory limits, startup command, network port, and the location the panel treats as the server root. A successful upload to the wrong instance is indistinguishable from a missing upload until you inspect the process path and logs.

Transfer worlds, identities, and configuration

Upload and extract the stopped archive using the host's supported file manager, SFTP, or migration service. Verify that each world root is at the expected level and that server.properties points level-name to the intended folder. Preserve the main world, Nether, End, player data, advancements, stats, datapacks, and server-specific world folders together.

Move allowlists, bans, operator data, permissions, plugin databases, mod configuration, and secrets only when they are still required. Do not publish credentials in a migration ticket or leave database passwords in a public archive. Rotate a secret if it was exposed during the move.

Be especially careful with online-mode and proxies. Changing authentication mode can make returning players receive different identities, which may look like lost inventory or permissions even though their old player files still exist.

Test on a private address

Keep the new server off the public address at first. Restrict it with an allowlist, firewall rule, or temporary host address. Start it and capture the console from process launch through the ready message. Resolve missing dependencies, unsupported versions, duplicate plugins, world conversion warnings, or permissions errors before inviting more testers.

Join with an administrator and at least one ordinary account if possible. Check spawn, known builds, all important dimensions, inventories, ender chests, advancements, teams, scoreboards, claims, economy, homes, portals, scheduled tasks, and commands. What matters depends on the server; the pre-migration inventory tells you what to test.

Stop and restart the new server. Confirm that a small test change survives and the same world loads again. A one-time successful join does not prove that writes, shutdown, and startup are correct.

Cut over players without running two writable copies

Once acceptance passes, keep the old server stopped. Point DNS, the proxy, or the published address to the new host and communicate the new port if it changed. Do not allow both copies to accept regular players: progress would split immediately, and merging two independently changed worlds is not a normal server operation.

Watch connection errors and startup logs during the first public session. Some players may retain an old DNS answer temporarily. Give them the temporary direct address only if doing so fits your security plan and will not become a permanent undocumented route.

Keep the old backup and migration archive for a defined retention period. Cancel the old host only after recent builds, player identities, scheduled backups, and a real restart have been verified.

Roll back as one controlled decision

If the new host corrupts data, loses player state, or cannot run the required stack, stop it before any more writes. Decide whether the short test period created progress worth preserving. The cleanest rollback is to restore the final authoritative archive on the old host and return the address, not to copy a few files in both directions.

Document the failed check and its log evidence before trying again. A migration becomes risky when each retry introduces a different Minecraft version, folder layout, and partial set of files.

Complete the migration checklist

• Server version, software, Java, loader, mods, plugins, worlds, and panel settings were inventoried.
• The authoritative archive was created only after a clean stop and retained off-host.
• The new runtime matches the original or follows a documented migration path.
• World folders, player identity data, permissions, configuration, and dependencies were transferred together.
• The new server passed private log, world, player, dimension, save, stop, and restart checks.
• Only one writable public server was active during cutover.
• DNS or address changes were communicated and monitored.
• The old host and backup remain available until rollback risk is acceptably low.

The goal is not merely to make the new process say “Done.” It is to preserve the server's shared history and prove that the new host can keep writing that history safely.