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.
Inventory FXServer and every configuration
Record the FXServer artifact, framework version (ESX or QBCore), SQL connector and startup arguments. Inventory server.cfg, every exec-loaded configuration, resources, scripts, maps, streamed assets and custom paths. A directory called resources alone is not a complete server backup.
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.
- server.cfg
- resources/
- exec
- ESX / QBCore
- oxmysql / MySQL / MariaDB
Preserve the entire txAdmin profile
server.cfg does not include txAdmin administration state. Locate the actual txData path and selected profile used at startup. Back up the entire txData directory, including profiles, configuration, administrators, permissions and moderation data. Record the txAdmin/FXServer versions. Do not create a new profile over the only copy of the old data.
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.
- txData/
- serverProfile
- txDataPath
- txAdmin administrators / moderation
Export ESX or QBCore data separately
Identify the real database endpoint without publishing its credentials. Export the framework and custom tables coherently: characters, inventories, vehicles and any resource-specific data. Record users, privileges, character set and collation. Restoring resources does not restore a remote MySQL or MariaDB database. Test a character save and reload after importing.
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.
- characters / inventories / vehicles
- custom SQL tables
- users / privileges / collation
Prepare compatible resources and private secrets
First restore the same artifact, framework and dependencies. Review platform bindings and asset licences rather than assuming ownership can be transferred. Configure Cfx.re keys, SQL credentials and webhooks privately at the destination; do not put them in this assistant, an exported checklist, a repository or screenshots.
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.
- FXServer artifacts
- Cfx.re licence key
- webhooks
- SQL connector
Run a private roleplay test
Check startup and resource console errors, txAdmin login and permissions, characters, inventory, vehicles and persistence after a clean restart. Test direct game connection and the FiveM list separately; an administration page responding does not validate the game’s TCP and UDP paths. Review the assigned endpoint and protection scope with the provider rather than running a flood test.
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.
- TCP + UDP game endpoint
- txAdmin access restrictions
- character save / reload
- FiveM server list
Switch address and retain a rollback
Schedule a write freeze for the final file and SQL export. Change the game address or applicable DNS and tell players the new endpoint. Monitor logs, saves and database writes. Keep the old host available privately; if the new database has accepted writes, decide how to reconcile them before rolling back. Do not cancel the source based only on a successful startup.
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.
- final files + SQL export
- private acceptance test
- address / DNS
- rollback decision
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.