How to Move a Minecraft Server to a New Host

Plan the move before you copy anything

Moving a Minecraft server is a controlled state transfer, not a download of the folder named world. The destination needs the same worlds, configuration, plugins or mods, access-control files, startup settings and external data that make the source behave correctly. Start by writing down the source host, destination host, Minecraft and server-software versions, Java runtime, working directory, public address, ports and the maintenance window. That inventory becomes the acceptance checklist and gives you a clear rollback point.

Decide whether the destination will keep the same software stack or change it at the same time. A host migration is easiest when Paper, plugins, Java and configuration stay fixed; an upgrade belongs in a separate staged change. Paper's migration and updating guidance both put a full backup first and warn against replacing JARs while a server is running. Keep the first destination boot as a reproduction of the known-good source, then schedule upgrades after players are stable.

Tell players when writes will stop and how the address will change. If the server uses a hostname, lower its DNS TTL ahead of the window only if you control the record and understand the provider's behavior. Do not promise an exact propagation time: resolvers can retain an earlier answer. If the host assigns a new port or address, prepare the complete value and a short status message before shutdown.

Record versions, Java, paths, ports, plugins or mods and external services.
Choose a destination that can run the same stack before changing software.
Announce the freeze, expected downtime and new connection details.
Keep the source online but untouched as the rollback copy until acceptance passes.

Create one consistent final backup

Ask players to leave, stop automated jobs and shut the source server down cleanly from its console or service manager. Wait until the Java process has exited; a panel that says stopping is not proof that region files and plugin queues are quiet. Paper's current backup guidance names world folders, server configuration, plugin configuration and plugin JARs as the essential set. For a move, archive the complete server directory when storage permits so startup scripts and less-obvious data do not get left behind.

Include every dimension and additional world, server.properties, Paper/Bukkit/Spigot settings, whitelist, operators, bans, permissions, plugin or mod data, generated configuration and the exact server JAR. Inventory anything outside the directory: an economy database, map tiles, object-storage bucket, proxy configuration or scheduled backup repository. Snapshot those systems at the same maintenance point or record their identifiers. A world copied at 21:00 paired with a database from 21:15 is not one restorable server state.

Open the archive or restore it into a temporary empty directory before transferring it. Check that it contains recent region files, player data, configuration and the expected byte size. Keep at least one untouched copy on the source side and, when possible, another protected copy elsewhere. The automatic backup guide at /blog/automatic-paper-minecraft-server-backups explains why a backup is only useful when its restore path has been tested.

Stop fully, then capture worlds, configuration, runtime files and plugin or mod data together.
Snapshot external databases or services at the same maintenance point.
Inspect the archive and preserve the source copy before starting the transfer.
Never delete the old host because the first destination boot looks healthy.

Transfer files over a private, verifiable path

Use the destination provider's documented file manager, SFTP account or a private server-to-server path. OpenSSH's scp and sftp tools encrypt the transfer through SSH; rsync can efficiently resume a large directory when SSH is its transport. Follow the host's account and port instructions rather than pasting a command meant for a different panel. Do not put panel passwords, API tokens or private keys in a script, chat message or public repository.

Transfer into a new destination directory, not directly over a half-created live installation. Preserve file names, permissions where the host supports them and symbolic links only when you understand how the destination handles them. If the panel accepts an archive, upload the archive and extract it server-side; if it accepts only individual files, use a resumable tool and keep a transfer log. Keep the source read-only while copying so a second, different state cannot be mistaken for the final backup.

Calculate a SHA-256 digest for the archive before upload and after download. GNU's sha256sum can print and verify a digest; on Windows, PowerShell's Get-FileHash provides the same check. Matching one archive proves the bytes arrived intact, but it does not prove that you archived the right directory. Compare the manifest, archive listing and checksum together, then record the destination path and timestamp.

Prefer SFTP, scp or rsync over SSH and use a least-privilege transfer account.
Upload into a new directory and keep the source frozen during the copy.
Verify a SHA-256 checksum and inspect the archive contents on both hosts.
Treat a successful upload as a byte check, not as proof of a working server.

Recreate the runtime on the destination

Install the Java version and server software required by the recorded source stack. Paper's getting-started table varies by Minecraft release, so run java -version through the same service, container or panel command that will launch the server—not only in an interactive shell. Place the transferred files in the working directory that the startup command actually uses, and confirm that level-name still points at the intended world folder. A correct archive in the wrong directory looks like a brand-new world.

Configure the destination port, bind address, memory limits, environment variables, scheduled jobs and external-service endpoints. Keep the destination private with a firewall rule, an unadvertised port or a temporary access control while testing. Do not copy production webhook credentials or database write credentials into a staging boot unless the endpoint is deliberately isolated. If the provider uses a container or panel template, compare its volume mount and startup command with the paths in your manifest.

Start once with no players and read the complete log from the beginning. Resolve missing Java classes, invalid configuration, absent dependencies, permission errors and a newly generated world before proceeding. The first boot may create files, but it should not silently replace the transferred world. Stop cleanly, inspect the generated configuration and start a second time; two clean boots catch path and persistence mistakes that a single green process can hide.

Match Java, Paper, plugins or mods and the startup command before inviting players.
Verify the working directory, volume mount, level-name and external endpoints.
Keep the destination private and credentials scoped during the rehearsal.
Complete two clean boots and resolve every serious log error.

Test the world and services before switching

Join the destination through its private test address with a normal, non-operator account. Visit the Overworld, Nether, End and any plugin-managed worlds; inspect inventories, ender chests, claims, homes, permissions, whitelist entries, maps and scheduled tasks. Generate one harmless new chunk, reconnect and restart. Confirm that the player UUIDs, advancements and plugin data match the source rather than only checking that the spawn area renders.

Exercise the integrations that can be forgotten in a file-only move: database reads and writes, map rendering, backups, webhooks, proxy forwarding, resource-pack delivery and any custom DNS name. Watch the destination console during each action. If the new host has different storage, network or memory characteristics, compare tick time and error rates with the source baseline; a migration should not become an unmeasured performance experiment. The lag checklist at /blog/minecraft-server-lag-fix-guide helps separate a real host bottleneck from a client or network symptom.

Keep a written acceptance record with the destination address, software versions, test account, checked worlds, external services, backup result and any accepted warnings. If a test changes valuable state, stop and restore the final backup into a fresh rehearsal directory. Do not invite the full community until the exact path players will use has passed the same checks from outside the host's private network.

Test every dimension, player data path and permission boundary.
Verify databases, maps, backups, webhooks, proxy behavior and resource-pack URLs.
Compare errors and tick behavior with the source baseline.
Record the acceptance result before changing public DNS or advertising the move.

Switch traffic with a rollback window

When acceptance passes, take the source offline and make one final short delta backup if anything changed during rehearsal. Apply the destination firewall and public listener, then update the hostname or send the new address to a small group first. Test from a genuinely external network and watch the destination log for the join. A DNS change can be correct while one resolver still serves its cached answer, so keep the old host stopped rather than running two writable worlds under one name.

Leave the source files, backup and old connection details preserved for a defined rollback window. Roll back when a required world fails to load, player data is wrong, a critical integration cannot write, repeated crashes appear or the destination cannot meet its measured health target. Stop the destination, preserve its logs and restore the coherent source state; do not copy only a newer world folder back over an older plugin database. The safe Paper update checklist at /blog/update-paper-minecraft-server-safely uses the same principle: restore a matching stack, not a mixture of versions.

After the window closes, rotate credentials that were used for the migration, remove temporary access rules and confirm the new host's automated backups and monitoring. Keep the old archive until the first destination backup has completed and a restore sample has been checked. More practical hosting guides are collected at /blog. If the new workload needs predictable storage, support or headroom, compare the documented options at /pricing after the migration has been measured rather than guessed.

Switch one public endpoint, then test an outside join while watching logs.
Keep the old host stopped but recoverable through a defined rollback window.
Restore complete matching state if rollback triggers fire; never mix old code with new data.
Confirm a fresh destination backup, monitoring and credential cleanup after cutover.

Frequently asked questions

Quick answers

What files do I need to move a Minecraft server to another host?

Move every world and dimension, server and Paper configuration, plugin or mod JARs and data, access-control files, startup settings and any external database or service data. Archive the complete server directory when possible.

Can I transfer a Minecraft world while the server is running?

A clean shutdown is the safest general method. Stop the Java process fully before copying so region files, player data, plugin queues and external snapshots represent one consistent recovery point.

How do I know a Minecraft server transfer worked?

Compare a SHA-256 checksum and archive manifest, then boot the destination privately twice. Test every dimension, player data, permissions, integrations, backups and an outside connection before switching traffic.

Will my Minecraft server IP change after moving hosts?

Usually the destination has a different address or port. A hostname can hide that change, but DNS caches may retain the old answer for a while, so keep the old host stopped and test the new endpoint directly.

How long should I keep the old Minecraft host after migrating?

Keep its untouched files and final backup through a defined rollback window and until the new host completes a verified backup and restore sample. Delete or cancel it only after acceptance and recovery evidence exist.