Before you start
Prepare a complete, dated backup and keep an independent copy. Stop writes or use an application-consistent backup method; copying a live directory is not proof of database consistency. Test restoration in an isolated destination. Keep the original untouched until validation.
Identify the server distribution
Record Minecraft and Java versions, Vanilla/Paper/Purpur or Forge/Fabric/NeoForge, the exact loader and modpack release, JVM options and custom startup settings. Read the runtime requirements of that release. Moving hosts and upgrading versions at the same time makes failures harder to diagnose.
Record the exact versions, startup settings, storage actually used and external dependencies. Inventory accounts, permissions, scheduled tasks, databases, licences, certificates and services outside the file directory. Check what the old provider permits you to export before cancelling anything.
- Minecraft version
- Java runtime
- Paper / Purpur
- Forge / Fabric / NeoForge
Find every world and dimension
Read level-name and the distribution’s actual world layout. Paper may keep Nether and End separately from Vanilla; modded dimensions may use other paths. Back up every actual world, player data, advancements and datapacks. Do not merge world_nether, world_the_end or DIM directories blindly. Follow the distribution’s conversion instructions and test on a copy.
Prepare a complete, dated backup and keep an independent copy. Stop writes or use an application-consistent backup method; copying a live directory is not proof of database consistency. Test restoration in an isolated destination. Keep the original untouched until validation.
- server.properties · level-name
- world / world_nether / world_the_end
- DIM-1 / DIM1 · distribution-dependent
- playerdata / advancements / datapacks
Keep access lists, plugins and mods
Preserve server.properties, configuration, whitelist.json, ops.json, bans, permissions and plugin data. A plugin JAR is not its data directory. Keep the same plugins or mods, dependencies and licences. If a plugin uses SQL, export that separate database and recreate only the required privileges at the destination.
Prepare a destination with compatible software, enough working space for both restored data and temporary archives, and the required ports and permissions. Match versions for the first restore; plan upgrades as a separate change. A matching amount of RAM or vCPU does not prove equivalent performance.
- whitelist.json / ops.json
- plugins/ + plugin data
- mods/ + config/
- external SQL
Make a consistent final backup
Notify players and stop the source cleanly before the final world copy. A running world can change during export. Keep a dated archive of all required directories and an independent original. Verify restoration and available space, including temporary archives; the download succeeding does not prove that all dimensions were included.
Plan a write freeze and take a final consistent export. Transfer files and database exports separately where required. Compare file counts, sizes and checksums of the same stable archive on both sides. A matching checksum proves transfer integrity, not application consistency or completeness.
- clean server stop
- complete archive
- independent original
- restore test
Restore privately and test persistence
Prepare the same distribution and runtime before restoring data; a later installer can replace files you just uploaded. Start privately, inspect logs, join with the matching client or modpack and test all dimensions, player inventory, permissions and plugin data. Save, stop cleanly and restart to check persistence. Keep account authentication enabled for a public server.
Test privately before opening access: startup logs, authentication, permissions, representative data, persistence after a clean restart and external dependencies. Check certificates and required TCP/UDP ports without exposing administration interfaces publicly. Keep a record of checks and unresolved differences.
- Overworld / Nether / End
- matching client and modpack
- permissions / inventories
- save + restart
Change the player address after validation
Check the assigned TCP game port rather than assuming it is 25565. If using a custom domain, review A/AAAA and Java SRV records; SRV is not a substitute for routing or opening the correct port. Announce the new address, monitor joins and saves and retain rollback data before cancelling the old service.
Switch the published address or DNS only after the private checks. Account for TTL and caches; an IP change is normally required when changing provider. Monitor errors, resource use and new writes. Set a rollback decision point. Rolling back after new writes requires data reconciliation, not simply switching DNS back.
- assigned TCP port
- A / AAAA / SRV
- player joins
- backup retention
For your situation
| Situation | Next check |
|---|---|
| Before moving | Do not start the cutover until a complete backup has been restored successfully in a private test. |
| During the move | A live copy can miss concurrent changes. Plan an application-specific replication and final synchronisation procedure with a qualified administrator; no uninterrupted move is promised. |
| After switching | Keep the old host and original backups until data, connections and persistence have been checked. Decide who can authorise the switch and how to handle writes created after cutover. |
Official sources
These documents describe the relevant protocols and software. Your service terms and configuration still need to be checked.