How to Back Up and Transfer a Minecraft Server World Safely

The world folder is the centre of the move, but it may not be the whole server. Player permissions, allowlists, properties, datapacks, plugins, mods, and their configuration can all affect whether the destination behaves like the source.

The low-risk migration sequence

Use this order whether you are moving between hosting companies, leaving Realms, or transferring from a home machine:

1. Record the source edition, exact Minecraft version, server software, mod loader, and installed content.
2. Put the source into maintenance mode or tell players the cutoff time.
3. Stop the server through its console or control panel and wait until it reports a complete shutdown.
4. Export the world and the server files you intend to keep.
5. Store an untouched copy somewhere outside the source host.
6. Check the archive size and, where possible, calculate a checksum.
7. Restore into a separate destination instance using compatible software.
8. Join and test the overworld, Nether, End, player inventory, permissions, and custom content.
9. Stop the destination cleanly, copy any final changes made after the first export, and repeat the verification.
10. Change the public address only after the destination passes.
11. Keep the old host and the untouched archive until the rollback window ends.

That staged approach takes longer than copying a folder while the server is live. It is still faster than discovering after cancellation that the Nether never arrived or that the only backup is corrupted.

Step 1: Inventory the source before touching files

Write a short migration manifest. It should contain:

• Java Edition or Bedrock Edition;
• exact Minecraft version;
• Vanilla, Paper, Spigot, Purpur, Fabric, Forge, NeoForge, Bedrock Dedicated Server, or Realms;
• Java version and startup flags, if self-managed;
• level-name from server.properties;
• plugin, mod, datapack, resource-pack, and Bedrock add-on names and versions;
• online-mode, allowlist, operators, permissions system, and port settings;
• current archive or world-folder size;
• the source address and destination address;
• the time at which player changes will stop.

Match the destination to the source before the first boot. A modded world may contain blocks, items, entities, dimensions, or saved data that Vanilla or Paper cannot understand. Paper’s official migration guide specifically warns that Paper cannot load content created by Fabric or Forge mods and does not support those mods. If you are changing server software as well as hosts, make those two changes separately so one failed test has one likely cause. Our Paper, Spigot, and Purpur comparison and Fabric, Forge, and NeoForge guide explain those software boundaries.

Avoid downgrading the Minecraft version during a transfer. World upgrades can rewrite saved data, while backwards compatibility is not promised. Paper exposes an option to ignore an incompatible world data version but labels it as not recommended and likely to cause problems in its system-properties reference. If you must experiment with a downgrade, do it only on a disposable copy.

Step 2: create a consistent backup

Ask players to log out, then stop the server normally. For a Java console you can run save-all flush before stop, but the backup should still be taken only after the process has fully exited. Paper’s troubleshooting guidance warns that modifying files while the server is running can corrupt them and says only a full shutdown prevents that class of problem.

Do not copy from a directory while the server is still saving chunks. A ZIP that opens successfully can still contain files captured at different moments.

For a managed host, prefer its documented full-server backup or file export over a world-only snapshot when moving like-for-like. Paper’s update guide identifies the core backup set as world folders, server configuration, and plugin configuration plus JARs. Add these where applicable:

• server.properties, allowlist/whitelist, ban lists, operators, and permissions files;
• all world folders, including every dimension;
• plugins/ or mods/, their configuration, and any dependency libraries the host expects you to supply;
• datapacks inside each world’s datapacks/ directory;
• Bedrock behavior and resource packs and their world associations;
• scripts, scheduled tasks, startup settings, and a copy of relevant logs.

Keep credentials out of any archive you will share. API keys, panel tokens, database passwords, and proxy secrets should be recreated at the destination rather than posted to support or stored in a public transfer link.

What a complete Java world looks like

For a Vanilla Java server with level-name=world, the main world/ directory holds the overworld and its level.dat, regions, entities, points of interest, player data, advancements, statistics, datapacks, and other saved state. Vanilla traditionally stores the Nether under world/DIM-1/ and the End under world/DIM1/.

Bukkit-family layouts need extra attention. Older Paper, Spigot, and CraftBukkit setups commonly split those dimensions into sibling folders such as world_nether/ and world_the_end/. Aternos documents the corresponding legacy layout as world_nether/DIM-1 and world_the_end/DIM1 in its dimension-merging instructions. Modern Paper 26.1 changed its storage migration behaviour, so follow the instructions for the exact Paper version rather than blindly applying an old folder diagram; Paper’s current migration page marks its pre-26.1 steps as historical.

The practical rule is simple: export every world entry that shares the configured level name, inspect all three dimensions at the destination, and never assume a single folder contains everything. If the destination generates a new Nether or End, stop immediately. Do not keep playing; correct the folder mapping and restore the test copy.

playerdata/ is part of the world and normally preserves Java inventories, positions, and ender chests by player UUID. Keep the same authentication mode. Changing online-mode can change how identities resolve, making a returning person appear to be a new player even though the old data remains on disk.

Bedrock worlds are not Java worlds

Move a Bedrock world with the provider’s Bedrock export, a .mcworld package, or the complete Bedrock world directory. Do not copy only visible region-like files: Bedrock uses a different storage format and may depend on associated behavior and resource packs. Java and Bedrock world files are not interchangeable. Aternos’ upload guide rejects a world from the wrong edition and requires the upload to contain essential files such as level.dat and the world’s data directories.

For console or mobile worlds where direct file access is restricted, Realms can act as a transfer path. Mojang’s official Bedrock transfer steps require an active Realm and current game versions: upload or replace a Realm slot from the source device, then download that slot on the destination. A downloaded Bedrock Realm also appears in the local Worlds list according to the Realm download guide.

Treat .mcworld as an edition-specific export, not as proof that add-ons will work on a different server implementation. Start the matching Bedrock version and verify packs, experiments, gamerules, inventories, and custom dimensions on the test copy.

Step 3: prove the backup is usable

An untested backup is only a hopeful archive. Before uploading it, perform two inexpensive checks:

1. Compare the exported archive’s byte size with the provider’s reported world or backup size. A small difference can result from compression, but a 20 MB download for a world reported as 2 GB deserves investigation.
2. Create a cryptographic checksum and save it beside the archive. On macOS or Linux, shasum -a 256 backup.zip is commonly available; on Windows, Get-FileHash backup.zip -Algorithm SHA256 works in PowerShell. Recalculate after downloading or transferring. Matching hashes prove the bytes arrived unchanged, not that the world is logically healthy.

Keep at least two generations if storage permits: the final pre-migration backup and an earlier known-good backup. Name them with the edition, version, and UTC timestamp, for example oak-java-1.21.8-2026-08-10T1800Z.zip. Never overwrite the untouched source archive during testing.

Provider snapshots are useful but not independent. Aternos, for example, says its connected Google Drive backups include world data, player data, settings, plugins, mods, add-ons, and datapacks, while a restore completely replaces current server files. Its separate world download creates a ZIP and notes the Bukkit dimension-layout issue. Use the full backup for recovery and the downloadable export for portability where the provider supports both.

Realms also creates automatic saves, but retention is finite. Mojang publishes its current Realm backup schedule and retention in Minecraft Help. Download a copy you control before ending a subscription rather than relying on a cloud restore point remaining available.

Step 4: restore to an isolated destination

Create a new, empty server using the exact source edition and version. Stop it after the host creates its directories, then use the provider’s import function or upload the files to the documented location. Confirm that level-name points to the restored folder and that the panel did not place the archive one directory too deep, such as world/world/level.dat.

Start with the same loader, mods, plugins, and datapacks. Read the console from the beginning, looking for missing registries, failed plugins, incompatible data versions, pack errors, or a message that a new world was generated. A clean “server started” line is not enough.

Join with the destination’s temporary address and test:

• the expected spawn and a distant known build;
• your inventory, ender chest, experience, advancements, and position;
• Nether portals and a known Nether location;
• an End portal and an existing End build;
• operator, allowlist, ban, and permission behaviour with a non-admin account;
• representative farms, redstone, command blocks, plugins, mods, and add-ons;
• a normal save, clean restart, and second join.

Ask one trusted player to verify their own data. Before opening publicly, follow the private-server security checklist and make sure temporary test access has not left the destination open.

Step 5: cut over without trapping players between servers

Schedule a short final maintenance window. Stop the old server, take one last backup, and repeat the restore if anybody played after the first export. Then prevent new joins to the old host so progress cannot split across two copies.

If players use a hostname you control, lower its DNS TTL in advance when your DNS provider allows it. At cutover, update the A/AAAA record or SRV record required by the new host. DNS caches do not all refresh instantly, so keep the old server closed with a clear maintenance message rather than allowing some players to build on it.

If the provider supplies the address and it cannot move, send the new address only after the final test. Check both Java and Bedrock connection details because their ports and client behaviour differ.

Define rollback before launch: if chunks are missing, identities reset, or critical content fails, close the destination, point the hostname back if necessary, and restore service from the untouched source or known-good archive. Do not attempt emergency repairs on your only copy.

Final checklist

• Source edition, version, software, loader, and content recorded
• Server stopped cleanly before export
• Overworld, Nether, End, player data, settings, and custom content included
• Independent archive stored outside both hosts
• Size checked and SHA-256 recorded
• Destination restored without changing version or software at the same time
• All dimensions, player data, permissions, and content tested
• Destination survived a save and restart
• Final source changes copied during a maintenance window
• Address changed only after verification
• Old host and rollback archive retained temporarily

The key is not a particular ZIP tool or hosting panel. It is maintaining three distinct things until the move is proven: the stopped source, an untouched portable backup, and a disposable restore test. With those in place, a failed import is an inconvenience—not a lost world.