How to move a Minecraft world to a new host

Record the working server before you move it

Write down the exact Minecraft version and edition, current server software or mod loader, required plugins or mods, world folder names, important configuration, permissions, whitelist and ban lists, and the approximate archive size.

Do not combine a host move with a Minecraft upgrade, loader change, and plugin replacement unless you have a specific compatibility plan. Keeping the first destination boot close to the known-working source makes failures much easier to diagnose.

Make a final source backup

Stop the old server cleanly before creating the final migration archive so files are not changing during the copy. Keep that archive outside the old host when practical, and do not delete the source just because the first upload completed.

Preserve the complete known-working server data rather than guessing which dimension folders matter. Different server software can arrange world and dimension data differently.

Match the software before first boot

Plugin and mod data need the environment that created them. Paper plugins are not Fabric, Forge, or NeoForge mods. A modded world may contain blocks, entities, dimensions, or registry data supplied by mods, so opening it without required content can remove or damage data.

For a modded server, reproduce the loader and required mod set first. For a plugin server, confirm the destination Minecraft and server-software versions support the required plugins before relying on them.

Changing server type? Paper documents migration from Vanilla, but moving between software families can change world layout or gameplay behavior. Always keep the pre-migration copy.

Transfer, boot, and validate

Upload the archive through the destination host's supported file-transfer path, extract it into a clean server directory, and confirm the configured world name points to the migrated world. Start the server and inspect its console before inviting players back.

• Visit a known location in the Overworld.
• Check Nether and End data when those dimensions are used.
• Confirm inventories, permissions, and recent builds.
• Exercise important plugin or mod features.
• Read startup warnings instead of treating a running process as proof of success.

Plan a clean cutover and rollback

For an active community, announce a short offline window, stop the source, make the final archive, transfer it, validate the destination, and only then direct players to the new address. This prevents progress from splitting across two copies of the same world.

If validation fails, stop the destination and return to the untouched source. Repeatedly modifying the only known-good copy turns a recoverable migration problem into a data-loss risk.

Migrating to Exaltry

Exaltry's automatic checkout is intentionally conservative. Standard Vanilla, Paper, Purpur, and compatible plugin setups can be provisioned automatically, while migrations and unusual modpacks remain assisted review items. Exaltry does not promise that every existing server can move unchanged.

Before checkout, gather the preflight details above and include the migration context in your setup notes. Keep an independent copy of any world you cannot afford to lose.