Prepare your Minecraft world for a move to a new host

Moving hosts sounds scary because it is your world — months of builds, plugin config and player inventories. Exporting the right folders before deleting the old server protects that work, but a move is possible only when the destination accepts those files.

Here’s the order that keeps you safe.

Back up first, always

Before you touch anything, pull a full copy of your server down to your own machine. Even if the migration tools do the copying for you, a local backup means there is no single point of failure. On almost every host this is Files → Download or an SFTP grab.

The folders that actually matter:

• world/, world_nether/, world_the_end/ — your map, all dimensions. This is the one you cannot regenerate.
• plugins/ — the jars and the plugins/<name>/config.yml files. The config is often more painful to recreate than the plugin itself.
• mods/ — for Forge/Fabric/NeoForge servers. Match the loader version on the new host.
• server.properties, ops.json, whitelist.json, banned-players.json — your settings and permissions.

Skip logs/, cache/ and libraries/ — they’re regenerated automatically and just slow the transfer.

Getting the files onto ChunkyHost

Be aware of what this step looks like on our side today, because it decides your timing. ChunkyHost has no usable world-transfer workflow today. The panel cannot import a world, write server files or provide a usable export of the provider volume. There is no SFTP endpoint or auto-import from another host either.

So there is currently no way to bring an existing world onto ChunkyHost — not by hand, not by import. A server bought today starts with a fresh world. We would rather you read that here than discover it after paying, and it is the reason to keep the backup you just made somewhere safe: it is what you will restore from when import ships.

Everything else in this guide — what to back up, what to leave behind, and how to verify the result — applies exactly the same whichever host you land on.

Test on a whitelist before you flip anything

For a destination that does accept uploads, this is the step people skip and regret. Once the files are on that host, start the server but leave it on a different IP and turn the whitelist on (whitelist on in the console, then whitelist add <yourname>). Now log in yourself and check the things that actually break in a move:

• Does the world load at spawn, and do your builds look right?
• Are all your plugins/mods loading clean? Watch the console for red on startup.
• Are op/whitelist permissions intact?
• Right Minecraft version and loader (1.21.x Paper, Fabric, NeoForge — whatever you ran)?

If anything’s off, your old server is still untouched and still running. Fix it on the new box at your leisure. Nobody on your community has noticed a thing.

Re-point your DNS or IP, then flip

When the new server passes, it’s time to send players to it. If you connect with a raw ip:port, just give people the new address. If you use a domain (an A record or a SRV record pointing at your host), update that record to the new IP. DNS can take anywhere from a few minutes to a couple of hours to propagate, so do this when the server’s already healthy — not while you’re still debugging.

Then turn the whitelist back off, let your players in, and watch the new server for a day before you cancel the old one. There is no rush to delete anything.

Test it before you cut over

ChunkyHost is not a destination for an existing world today: there is no import or upload path. Keep the export, and choose another host with a verified transfer workflow if you must move now. Do not cancel the old server until the new destination has loaded and verified your world.

When you’re ready to size the new box, run your modpack and player count through the free RAM calculator so you don’t overpay, and check current pricing for ChunkyHost’s fixed-term Java plans and current product limits.