How to transfer a Minecraft server to a new host with minimal downtime
Build and test the destination first, freeze changes, take one final consistent backup, validate privately, then cut DNS over with the old server intact.
The safest Minecraft host migration is a staged cutover: inventory the current server, prepare a compatible destination, test an earlier copy, announce a short freeze, take one final clean backup, validate privately, and change the address only after the new server passes checks.
Do not cancel the old host until the new world and player data have been verified.
1. Inventory the current server
Record the facts needed to reproduce it:
- Minecraft implementation and exact build.
- Java version and startup flags.
- Allocated heap and total plan memory.
- World directory names and sizes.
- Plugins, versions, dependencies, and external databases.
- Ports used by Minecraft, voice chat, maps, or query services.
- DNS records and their current TTL values.
- Scheduled tasks, backups, allowlists, and firewall rules.
Save a copy of the current startup log. It provides a reference for plugin versions and warnings after migration.
2. Prepare the destination
Match the Java and server versions before uploading production data. Do not combine a host move, Minecraft upgrade, Java upgrade, and plugin refresh into one change. Fewer moving parts make rollback possible.
If DNS points at the current server, lower its TTL at least one existing TTL period before the cutover. That encourages resolvers to notice the later address change sooner.
3. Run a rehearsal
Copy a recent backup to the destination while the live server remains online. Start the copy on a private address or allowlist and check:
- All dimensions load.
- Player inventories and ender chests are present.
- Permissions, claims, economy, and moderation plugins work.
- External databases accept connections from the new address.
- Console commands and scheduled tasks run.
- TPS and MSPT are reasonable after startup settles.
A rehearsal finds slow transfers and missing dependencies before the downtime window.
4. Freeze and capture the final copy
At cutover time, stop new player changes. Run a final save, stop cleanly, and copy the data changed since the rehearsal. If your transfer method cannot synchronize differences, take and upload a complete final archive.
Keep the old server stopped after the final copy. Allowing both copies to accept players creates two diverging versions of the world.
5. Validate before changing DNS
Connect directly to the destination IP and port. Repeat the critical checks from rehearsal, inspect the log, and compare representative files and database row counts where possible.
Only then update the A or SRV record. Keep the old instance and final archive untouched until the new address has propagated and players confirm normal operation.
6. Keep a rollback window
Define rollback before starting: the old server stays stopped but ready, the final archive is immutable, and DNS can point back if a blocking problem appears. Do not make new production changes on both sides.
After the rollback window, take a fresh destination backup before canceling the old service.
Moving to gummies.cloud
gummysnacks exposes full file management and SFTP for imports, then runs the migrated Paper server inside its own customer VM. The panel provides live console, settings, TPS, snapshots, and off-site backups after the move.
Managed migration is included for free. Email support with the subject generated below and include the current server type, version, compressed size, database use, and preferred maintenance window. We will not ask for your current host password if an archive or temporary transfer credential will do.
Sources and review
Reviewed July 15, 2026. The safe-save and complete-data recommendations follow PaperMC's backup guidance and the Minecraft Wiki server-maintenance procedure. Exact panel behavior was checked against the current gummysnacks file, SFTP, console, and provisioning implementation.