How to Migrate Your Minecraft Server to a New Host

Why Migrate?

There are plenty of reasons to move a Minecraft server from one host to another. Maybe your current provider keeps overselling nodes and your TPS tanks every evening. Maybe you found a host with better hardware, lower latency, or a panel you actually enjoy using. Maybe your server outgrew a shared plan and needs dedicated resources. Whatever the motivation, migration sounds scary but is entirely manageable if you approach it methodically.

The biggest risk during migration is data loss, and the second biggest risk is extended downtime that frustrates your community. Both are avoidable with planning. This guide walks through every step from initial preparation to the moment you open the doors on the new machine.

Planning the Migration

Choose Your Window

Schedule the migration during your server's lowest-activity period. Check your player count analytics, most servers see a dip between 02:00 and 08:00 in their primary timezone. Announce the maintenance window at least 48 hours in advance through Discord, your website, and in-game broadcasts. Give players a concrete time estimate: "The server will be offline from 03:00 to 06:00 CET on Saturday."

Inventory What You Have

Before you touch anything, make a list of everything running on the old server:

• Server software and version, Paper 1.21.4 build 127, for example
• Java version, Java 21.0.2, flags you use in the startup command
• Plugins, every jar in plugins/ plus its version number
• Worlds, world/, world_nether/, world_the_end/, plus any Multiverse worlds
• Databases, MySQL or MariaDB databases used by plugins (LuckPerms, economy plugins, CoreProtect, etc.)
• Custom configurations, server.properties, spigot.yml, paper-global.yml, paper-world-defaults.yml, bukkit.yml
• External integrations, Discord bots, Votifier listeners, Dynmap, website connections

Write this down somewhere. You will use it as a checklist when verifying the new server.

Backing Up the Old Server

Stop the server cleanly with /stop, never kill the process. Once the server is fully stopped, create a complete backup of the entire server directory. If you are on a Pterodactyl panel, use the built-in backup feature or download via the file manager. On a VPS or dedicated box, use SFTP or run:

tar -czf server-backup-$(date +%Y%m%d).tar.gz /path/to/server/

Download this archive to your local machine as a safety net. Even if the upload to the new host fails catastrophically, you can always restore the old server from this copy. For a more detailed look at backup strategies, see our backup and restore guide.

Exporting MySQL Databases

If any of your plugins use MySQL or MariaDB (which is common for LuckPerms, CoreProtect, and economy plugins), you need to export those databases separately. World files and plugin configs live on disk, but database records live in the MySQL server, which is a different system entirely.

Use mysqldump from the command line:

mysqldump -u username -p database_name > database_backup.sql

If you only have phpMyAdmin access, log in, select the database, click Export, choose "Quick" with SQL format, and download the file. Do this for every database your server uses. Label the files clearly so you know which plugin each database belongs to.

Setting Up the New Host

Uploading Files

Create the new server on your new hosting provider. Before uploading your files, delete the default world and configuration files that the new host generated, you are replacing everything with your own data.

Upload your server files using SFTP (FileZilla, WinSCP, or the panel's built-in file manager). For large servers with many gigabytes of world data, SFTP can be slow. A faster approach is to upload the compressed archive and extract it on the server:

# Upload server-backup.tar.gz via SFTP first, then in the console or SSH:
tar -xzf server-backup.tar.gz

Make sure the server jar, all plugin jars, world folders, and config files are in the correct paths. The directory structure on the new host should mirror the old one exactly.

Importing MySQL Databases

Create new MySQL databases on the new host, most panels have a database management section for this. Then import your SQL dumps:

mysql -u new_username -p new_database_name < database_backup.sql

Or use phpMyAdmin: select the empty database, click Import, upload the SQL file. After importing, update every plugin config that references database credentials. Search through your plugin configs for the old hostname, port, database name, username, and password, then replace them with the new values. Common files to check:

• plugins/LuckPerms/config.yml
• plugins/CoreProtect/config.yml
• plugins/Essentials/config.yml (if using MySQL storage)
• plugins/Plan/config.yml (if installed)

Reconfiguring server.properties

Open server.properties and update any host-specific settings:

Setting	Action
server-ip	Leave blank or set to the new server's IP if required by the host
server-port	Set to the port assigned by your new host (usually 25565)
query.port	Match the server port or the port your host specifies for query

If you use a BungeeCord or Velocity proxy, update the proxy config to point to the new backend server IP and port as well.

DNS and Custom Addresses

If your server uses a custom domain like play.yourserver.com, you need to update the DNS records. Go to your domain registrar and change the SRV record (or A record, depending on your setup) to point to the new host's IP address. DNS propagation can take anywhere from a few minutes to 48 hours, though most players will see the change within an hour or two. During propagation, some players will connect to the old IP and some to the new one, so keep the old server offline to avoid split-brain scenarios.

Testing Before Going Live

Start the new server and join yourself before announcing anything. Run through this checklist:

• All worlds load correctly, walk around, check builds, verify the Nether and End
• Plugins are all green in /plugins, no red names
• Player data loads correctly, check your inventory, ender chest, balance
• Permissions work, test commands as different rank levels
• Economy is intact, check Vault balances, try a transaction
• CoreProtect logs are present, run a lookup on a recent edit
• Chat formatting, tab completion, and scoreboard displays render correctly
• Server performance is acceptable, monitor TPS with /tps or Spark

Have a few trusted staff members join and test as well. They will catch things you miss.

Rollback Plan

Keep the old server's files intact for at least two weeks after migration. If something goes catastrophically wrong on the new host, a corrupted database import you did not notice, a plugin that silently ate player data, you can spin the old server back up and retry the migration. Only delete the old server once you are confident everything on the new host is stable and your players have confirmed their data is intact.

Announcing to Players

Once testing is complete, announce the migration in all your communication channels. If the IP address changed and you do not use a custom domain, make sure the new IP is prominently displayed. Pin it in Discord, update your server listing on Minecraft server lists, and use an in-game broadcast plugin to remind players who connect using the old IP (if it still resolves anywhere) to update their server list entry.

Migrations are stressful, but if you follow these steps and keep backups at every stage, the worst-case scenario is just re-doing the import. Take your time, test thoroughly, and your players will barely notice the switch.

Looking for reliable hosting? Astroworld Hosting runs NVMe SSD, Pterodactyl panel, daily backups, and DDoS protection. See features , plans from €6.39/mo.