Independent server guide
Server migration checklist for Minecraft
Move a Minecraft server with an inventory, verified backups, staged testing, a controlled cutover, and a practical rollback plan.
Reviewed
A safe migration is a restore rehearsal followed by a controlled cutover. Keep the original server unchanged until the copied world, software, players, and backups work in the new environment.
1. Inventory the current server
Record the edition, game version, server software, loader, and startup settings. List plugins, mods, add-ons, dependencies, configuration files, world directories, allowlists, operators, bans, and scheduled tasks. Note the current hostname and port, but do not place credentials or private player information in a public planning form.
Use the server sizing calculator with realistic concurrent players and the migration option selected. Review CPU, storage, backup, and headroom guidance along with the RAM range.
2. Make a restorable backup
Schedule a quiet period. Ask the server to save pending world data, then stop it cleanly before making the final archive when the software supports that workflow. Copy the world and required configuration files, record archive sizes and checksums, and keep a separate copy outside both hosting environments.
A successful archive is not enough. Extract it into a temporary location and confirm that the expected world and configuration files are present.
3. Stage the destination
Install the required edition, server software, loader, and exact component versions. Restore a copy of the data to a non-public hostname or port. Do not overwrite the only source copy.
Check startup logs for missing files, version mismatches, failed plugins, or conversion warnings. Join with a test account and inspect spawn, representative builds, player data, inventories, dimensions, permissions, and commands. Trigger a backup on the destination and verify that its restore instructions are documented.
4. Define cutover and rollback
Choose a maintenance window and tell players when writes will stop. Define a rollback condition before the cutover, such as a world that will not load, missing player data, or a required plugin that cannot start.
At cutover:
- Stop new joins and save the source world.
- Stop the source server cleanly.
- Create and verify the final backup.
- Transfer only the intended server data.
- Start the destination and repeat the critical checks.
- Update the public hostname or connection instructions.
- Keep the source stopped but recoverable until the new server is accepted.
If a rollback condition occurs, stop the destination before more world changes accumulate. Restore the previous connection path and restart the unchanged source copy.
5. Watch the first busy session
Monitor tick behavior, CPU, memory pressure, disk space, saves, and backup completion during normal play. Confirm that operators can reach the administrative tools they need. Rotate any credentials or tokens that were exposed to the old environment.
The provider comparison lists reviewed factual features and source dates. The methodology explains how HostForge handles estimates and stale provider facts. Verify migration details with the destination provider before the maintenance window.