Migrating a world between hosts, a checklist

Server host migrations sound simple. They aren't always. The world file copies fine. The plugins copy fine. Then the server boots and three things you didn't think about are broken.

This article is the comprehensive checklist for moving a game server between hosts without losing data or breaking trust.

Step 0: be sure you actually want to migrate

Migrations cost time and risk progress. Before committing:

• Have you tried fixing whatever drove you to migrate?
• Is the new host genuinely better, or just different?
• Have you read the new host's terms (limits, restart policies)?

Sometimes the right answer is "stay and tune." Other times migration is correct. Don't migrate impulsively.

A two-week migration timeline

Step 1: pick your migration window

Migration goes faster than people expect (usually 30 to 90 minutes for the actual move), but the planning is critical.

Pick a low-activity window:

• Off-peak hours for your community.
• Weekday for groups that play weekends, or vice versa.
• Give 7 to 14 days notice to players.

Communicate clearly:

"We're moving to a new host on Saturday 14th at 10 PM EST. The server will be offline for approximately 1 hour. After the move, the connection address will be the same (we're using a custom domain), so you won't need to update anything. New host has [whatever the benefit is]."

Step 2: provision the new host

Don't migrate to a fresh host blind. Set up the new host days in advance:

• Provision the plan.
• Install the same server software (Minecraft Paper / Forge / Valheim / etc.).
• Install the same plugins / mods, matched versions.
• Test it boots with a fresh world.

This phase shakes out installation problems before you're racing the clock.

Step 3: full pre-migration backup

Before any data movement:

• Take a complete backup of the live world.
• Confirm the backup is good (extract test, peek inside).
• Store the backup off-host (cloud, local, anywhere not the source).

If the migration goes wrong, this backup is your rollback.

Step 4: world file transfer

Three methods, in increasing speed:

Method	Speed	Use when
Browser upload via panel	Slow	Small worlds, no SFTP available
SFTP	Fast	Standard for most paid hosting
Server-to-server rsync	Fastest	Both hosts have SSH access

For most paid hosting, SFTP is the realistic option. Plan for transfer time:

World size	Approximate SFTP transfer
1 GB	1 to 5 min
10 GB	10 to 30 min
50 GB	1 to 3 hr
100+ GB	Several hours, consider compressing first

Step 5: configuration files

Most "broken after migration" issues are config files, not world files.

Bring over:

server.properties (Minecraft)
ops.json, whitelist.json, banned-*.json
plugins/[plugin]/config.yml for every plugin
config/ (Forge / NeoForge mod configs; formats vary: .toml, .json, .cfg)
spigot.yml, paper-world-defaults.yml, bukkit.yml
EssentialsX user files (plugins/Essentials/userdata/)
WorldGuard regions (plugins/WorldGuard/worlds/[world]/regions.yml)
LuckPerms config or database export
CoreProtect database (or use the SQLite file if applicable)

For VS:

serverconfig.json
worldconfig.json (per save)
Mods/ folder

For Valheim:

worlds/
adminlist.txt, bannedlist.txt, permittedlist.txt

For Eco:

Storage/
Configs/
Mods/

Check each file for host-specific paths that might need updating:

• Database connection strings.
• Webhook URLs that included the old host's IP.
• Anything referencing the old hostname.

Step 6: secrets and tokens

Some configs contain secrets:

• Discord bot tokens.
• API keys for plugins.
• Database passwords.

Treat the migration as a chance to rotate these. The old host might still have copies on disk. Rotate to reduce risk.

Step 7: test on the new host

Before announcing the migration is done:

1. Boot the new host's server.
2. Watch the console for errors.
3. Connect from a client (the same address you'll give players).
4. Spawn in. Check known locations.
5. Test plugins (try /sethome, /spawn, /tpa for Essentials, etc.).
6. Verify CoreProtect or your audit log works.
7. Have one player join (a staff member). Confirm they connect and play.

This is where pre-migration test pays off. You catch problems in private rather than during the public cutover.

Step 8: DNS cutover

If you have a custom domain (and you should), update DNS:

• Update A record to point to the new host's IP.
• Update SRV record if the port changed.
• Set TTL low (300 seconds) for the cutover.

DNS propagation can take minutes to hours. Plan for some players to still hit the old host briefly.

Step 9: take old server offline

After DNS is updated and the new server is up:

• Stop the old server.
• Confirm players are connecting to the new one.
• Wait at least 24 hours before deleting old data.

Don't delete the old server immediately. Keep it as a safety net. If the new host has problems in the first 24 hours, you might need to fail back.

Step 10: post-migration communication

Once stable:

"Migration complete. New host is up. Same connection address as before. If you notice anything off, ping us. We'll keep the old host running for 24 hours as a backup, then decommission."

Watch for issues in the first 24 hours. Player reports of "I can't connect" or "this feature doesn't work" should get immediate attention.

Step 11: decommission

After 24 to 48 hours of stable operation:

• Confirm all players are on the new host.
• Confirm no critical issues.
• Archive a final backup of the old host's state (just in case).
• Cancel the old hosting plan.

Common mistakes

Migrating during peak hours.

The friction is real. Communicate the off-peak time and stick to it.

Forgetting plugin databases.

Many plugins use SQLite or external databases. CoreProtect, Essentials, LuckPerms, economy plugins. Each needs its data brought over.

Not testing the new host before cutover.

Test on the new host with a fresh world first, then with the real world. Don't cutover blind.

Deleting the old host too soon.

24-hour overlap is cheap insurance. Take it.

Custom domains pointing to the old IP after migration.

Update DNS. Set low TTL beforehand.

Forgetting non-game services.

If you run a status page, Discord bot, web admin, etc., they may also need migration or reconfiguration.

A simpler migration: same host, new server

Sometimes "migration" is just switching from one server to another on the same host (e.g., creating a fresh server with bigger RAM and moving content over).

Same checklist applies, simplified. The DNS step is usually unnecessary.

Conclusion

Migrations are mechanical processes with clear steps. The risk comes from skipping steps, not from the migration itself. Prepare the new host in advance, test thoroughly, communicate clearly, keep the old host around for a safety net.

Done well, a migration is invisible to players. Done badly, it's a multi-day disruption. The difference is the checklist. Use it.