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.
Confirm Bedrock and its supported version
Use Bedrock Dedicated Server and record the exact server and client versions. Java and Bedrock worlds, plugins and permissions are not interchangeable. A conversion or proxy is a separate compatibility project; this guide does not promise that a Java world will load on Bedrock.
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.
- Bedrock Dedicated Server
- server / client versions
- Java ≠ Bedrock
Locate the selected world
Read level-name in the actual server.properties and locate that world under worlds. Include all its database files and required resource or behaviour packs. Do not copy a live world database and assume it is consistent; stop writes and keep the complete original before preparing a restore.
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
- worlds/
- world database
- resource_packs/ / behavior_packs/
Preserve permissions and access settings
Keep allowlist.json, permissions.json, the relevant server.properties settings and pack dependencies. Check default player permissions and allow-list behaviour. Keep any external tooling, proxy configuration or database separately; Java whitelist.json and ops.json are not Bedrock replacements.
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.
- allowlist.json
- permissions.json
- allow-list
- default-player-permission-level
Restore a complete, stable copy
Back up after a clean stop, preserve the original, and restore on a matching server version. Check file sizes and archive checksums and validate the world in a private test. Changing the version while moving may transform save data, so keep a version-matched recovery copy.
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 stop
- stable archive
- matching server version
- private restore
Test packs and the UDP game path
Join with a compatible client and check world state, permissions, behaviour/resource packs and saved progress after restarting. Verify the assigned UDP ports. Bedrock defaults are 19132 for IPv4 and 19133 for IPv6, but the provider’s allocation and configuration take precedence; a TCP check does not validate UDP.
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.
- UDP · server-port
- UDP · server-portv6
- client / pack compatibility
- save + restart
Publish the new address and monitor
Give players the assigned Bedrock address and UDP port, account for client and platform connection restrictions and review DNS if used. Do not assume Java SRV handling works for every Bedrock client. Monitor joins and persistence, retain the old backup and reconcile new writes before a rollback.
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 address + UDP port
- client platform restrictions
- persistence
- rollback
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.