Moving a Minecraft Server: DNS Cutover and Reopening
To move a Minecraft server while keeping its familiar address, prepare the new destination first, stop writes on the old server, transfer a final coherent data set, and then change the connection route. Keep the old world closed to players. A DNS update changes where a name points; it does not keep two running copies of a world synchronized.
This guide is for established communities planning a host change for a Java server. It assumes you control the public hostname and can arrange a maintenance window. The sequence below is a proposed operating procedure, not a migration we have tested on your infrastructure. Bedrock access, crossplay and additional services need their own connection checks.
Map the address players actually use
Start with a saved server entry from a regular participant. Record the hostname, any explicit port, the public entry point and the machine that stores the world. If a proxy is involved, distinguish its public address from its private backend destinations. Moving a backend while retaining the proxy may require no public DNS change.
Inspect the complete DNS path. A and AAAA records provide IPv4 and IPv6 addresses; a CNAME introduces another hostname. Review both address families so that an old IPv6 route does not remain unnoticed when you update IPv4. The DNS record reference explains these record types.
If your current entry uses an SRV record, record its target and port as well as the target's address records. SRV has its own service record, and its target must have address records rather than be an alias, as specified in RFC 2782. Preserve the established routing design unless changing it is part of the tested scope.
Assign one person to change DNS and another to confirm which server receives the test connection. Keep the previous record values in the change document. Do not combine this move with a registrar transfer, authentication change or Minecraft upgrade.
Prepare caches before the maintenance window
TTL controls how long a DNS answer can be cached. Lowering it at the moment of the move does not replace answers already stored with the previous TTL. RFC 1034 describes this caching model.
For an illustrative schedule, suppose the records you will change have a TTL of 3,600 seconds. Lower the applicable TTLs to 300 seconds at least an hour before changing their destinations, with additional operational margin. Include any changing SRV target or alias in the review. These are example planning values, not a promise that every player will reach the new server within five minutes. Cloudflare's TTL documentation also notes that local caches can delay visible changes.
Create any new target hostname early and check it before the window. A newly added name and an edited existing record are different cases; a previous negative answer may also be cached. Do not use a countdown alone as the reopening criterion.
If Cloudflare hosts your DNS, verify that an ordinary game endpoint uses the appropriate DNS-only setup. Its standard HTTP proxy is not a general Minecraft transport; a deliberately provisioned transport service is a separate configuration. Check the documented proxy limitations.
Rehearse the destination without creating a second live world
Build the destination with the same software and identity settings. Use an isolated copy for the rehearsal, separate copied databases from production, and disable production integrations there. The backup restore rehearsal covers coherent recovery sets and representative player-state checks.
Test through a controlled route that exercises the intended entry point. A direct IP test may miss proxy routing or hostname-dependent behaviour. Record how you will repeat the check after the final transfer, including evidence from destination logs. If your network uses Velocity, retain the access boundaries described in the backend access checks.
Discard rehearsal changes before the final data transfer. A tester's successful login to a week-old copy does not establish that the final migration preserved current inventories.
Use one clear handover of writes
During the agreed maintenance window:
- Close player access and end existing game sessions. Pause bots, scheduled jobs and other systems that modify related state.
- Stop the source game server cleanly. Capture worlds, required configuration and external data through their supported backup methods as one documented recovery set.
- Transfer that final set to the destination. Confirm that it replaced the rehearsal data and uses the intended production dependencies.
- Keep both environments restricted while staff check dimensions, inventories, permissions and representative plugin data. Record the destination log evidence for each connection.
- Change the prepared connection route and verify it from the networks used for acceptance. Open public play only after the named operator accepts the result.
This is a conservative proposal for a planned move. Database-specific synchronization and existing proxy architectures may require a different runbook. Never assume that copying the world folder alone includes balances, claims or data owned by an integration.
Leave the old game process stopped or otherwise unable to accept gameplay. A maintenance endpoint must not mount a writable copy of the old world. Some players may still reach the former address during the transition; letting them build there would create competing histories.
Decide when rollback stops being a DNS operation
Before public play resumes, the source remains the last accepted production state. If destination checks fail, keep the destination closed, revert routing if necessary, and reopen the source only after confirming its state and dependencies. Allow for caching during that return too.
After players or integrations write to the destination, the old source is stale. Switching DNS back cannot copy new buildings, inventories or database transactions into it. Stop writes and decide whether to repair the destination, transfer its current state back, or restore an agreed recovery point. Record any expected loss before reopening. Do not advertise instant rollback without a proven data procedure.
Use this small acceptance table in the handover:
| Check | Evidence required |
|---|---|
| Familiar address | A real login reaches the intended entry point and appears in destination logs |
| Player state | Selected inventories, locations and plugin records match the final transfer |
| Old endpoint | No gameplay writes can occur on the source |
| Failure decision | Named owner, reopening criteria and treatment of destination writes are recorded |
Keep the old recovery set until the agreed retention point, monitor failed joins and startup errors, and restore normal TTLs after the transition is accepted. A successful DNS lookup alone is not acceptance.
Mineando's managed Minecraft infrastructure can include architecture, deployment and recovery procedures within an individually scoped paid project. Share the entry routes, dependencies and maintenance constraints; support schedules and responsibilities are agreed separately.
