Moving from Aternos to dedicated hosting without losing your world

You started on Aternos because it was free. The server worked. Friends joined. Then you started feeling the friction: cold-start delays, the queue when their hardware is busy, the cap on player count, the missing features. You're ready to move to dedicated hosting.

This guide walks you through the migration without losing your world, your players, or your sanity.

The migration at a glance

Step 0: decide that you're actually moving

Migrations are mostly painless but never zero-effort. Confirm the move is worth it. Common signals you've outgrown Aternos:

• Cold starts annoy your players.
• You want 24/7 uptime.
• You need more RAM than the free tier provides.
• You want a custom domain.
• You're hitting plugin or mod slot limits.

If those are real for you, migrate. If they're not, save the money and stay.

Step 1: take a clean backup of the Aternos world

Aternos provides a world download in its panel. Use it.

1. Stop the server in Aternos.
2. Go to Files → Worlds.
3. Download the world as a zip.
4. Also download:
   • server.properties
   • ops.json
   • whitelist.json
   • banned-players.json
   • Plugin folder (if you used plugins).
   • Plugin configs (in the plugins/ folder).

Save them all to a folder on your local machine, named something obvious.

Step 2: note your current server software and version

In Aternos, your server type might be:

• Vanilla
• Paper
• Spigot
• Forge
• Fabric

Note the Minecraft version too (e.g., 1.20.6). You'll need to match this on the new host to avoid world version mismatches.

Step 3: pick and set up the new host

This article assumes you've already chosen a host. If not, see our hosting decision guide.

When provisioning your new server:

• Pick the same software (Paper, Forge, etc.).
• Pick the same Minecraft version.
• Pick a RAM tier appropriate for your modpack / player count.

Boot the server once with default settings to confirm it works. Then stop it.

Step 4: upload your world

Method depends on your new host:

• Most Pterodactyl-based panels offer a file manager with drag-and-drop upload.
• For SFTP, use FileZilla or Cyberduck.
• For larger worlds (multi-GB), SFTP is faster than browser upload.

Upload structure:

your-server-root/
├── world/
├── world_nether/
├── world_the_end/
├── server.properties
├── ops.json
├── whitelist.json
├── banned-players.json
└── plugins/   (if applicable)

Critical: stop the new server before uploading the world. Uploading while the server is running can corrupt the in-flight world file.

Step 5: reconcile server.properties

server.properties from Aternos contains things you'll want to keep:

• Game mode, difficulty, gamerule defaults.
• World seed (if you care for /seed purposes).
• Spawn protection, view-distance, simulation-distance.

And things you'll want to change for the new host:

• server-ip= should be blank (let the host's networking handle it).
• server-port= will likely change to whatever your new host assigned.
• online-mode=true (leave on unless you specifically need offline mode).

Compare side-by-side. Take only the gameplay-relevant lines.

Step 6: plugins, the careful part

Aternos uses a sandboxed plugin model. The plugin files themselves should be portable to any Paper / Spigot server of the same MC version. Their configs in the plugins/ folder should also come over cleanly.

Test:

1. Boot the new server with the world but without plugins.
2. Confirm the world loads and looks right.
3. Stop the server.
4. Add plugins back. Boot.
5. Check the console log for plugin errors.

Common issues:

• A plugin that depended on Aternos-specific features (rare).
• A plugin with a license tied to Aternos (very rare, but possible for paid premium plugins).
• A plugin whose config references file paths that differ between hosts. Update the paths.

Step 7: test the world thoroughly before announcing

Before telling players, do a careful play test:

• Spawn in, walk around, place a block, break a block. (Tests basic write.)
• Open a chest. (Tests inventory and block entity.)
• Teleport to a few known locations. (Tests far-away chunks loaded correctly.)
• Sleep in a bed. (Tests time progression.)
• If you have a redstone build, fire it up. (Tests block updates.)
• If you have plugins, exercise each one's main feature.

If any of those misbehave, you have time to diagnose. Discovering issues during the player rollout is much worse.

Step 8: announce the move and update DNS

Tell your players:

• The new server address.
• The exact time of the cutover.
• That the old Aternos server is permanently shutting down (so they don't accidentally play on the wrong one and waste time).

If you have a custom domain:

• Update the DNS A record (or SRV record) to point at the new host's IP.
• DNS propagation can take a few hours. Plan around this.

The simplest pattern:

• Friday evening: announce cutover for Sunday afternoon.
• Sunday afternoon: stop Aternos, do final world snapshot, upload, boot new host, open to players.

Step 9: keep the Aternos backup forever

Don't delete the downloaded backup. Keep it indefinitely. If anything goes wrong on the new host in the first few weeks, you can re-restore from a known-good snapshot.

After a month of confident operation on the new host, archive the Aternos backup to cold storage. Don't delete.

Common mistakes

Migrating during a major version upgrade.

Don't. Migrate first, get stable, then upgrade Minecraft version. Two changes at once make debugging impossible.

Forgetting the nether and end worlds.

The Overworld is in world/. The Nether is world_nether/. The End is world_the_end/. They are separate folders. Take all three.

Not testing plugins before the rollout.

Test on a private session before going live.

Not communicating with players about the cutover.

The player who plays on the old server for two hours after the cutover and then can't get their progress over is unhappy. Communicate.

Forgetting to disable the old server.

If both servers stay reachable, someone will accidentally play on the wrong one. Take the Aternos one offline permanently after the migration window.

A pre-migration checklist

[ ] World downloaded as zip
[ ] server.properties saved
[ ] ops.json, whitelist.json, banned-*.json saved
[ ] Plugin folder saved
[ ] Minecraft version noted
[ ] Server software noted
[ ] New host provisioned with matching MC version and software
[ ] World uploaded with server stopped
[ ] server.properties reconciled
[ ] Test play completed
[ ] DNS updated (if applicable)
[ ] Players informed of cutover time
[ ] Final snapshot from Aternos
[ ] Old server stopped
[ ] New server announced live
[ ] Aternos backup archived

A word about player UUIDs

Player identities in Minecraft are tied to UUIDs, which are tied to Mojang accounts, not to your server. Players who were on the Aternos whitelist will appear on the new server's whitelist (you copied whitelist.json). They keep their inventories, their builds, their data.

This is one of Minecraft's nicer design decisions. Migration doesn't lose player identity.

Conclusion

The migration itself is straightforward. The biggest risks are: testing too little before rollout, communicating too little to players, and skipping the backups. Take your time on the test play. Communicate the cutover clearly. Keep both the old and new backups. After a month, the move is done and you have a real server that works the way you want.