Migrating a live FiveM server is one of those jobs where preparation is everything. Rush it and you lose player data, break script state, or come back online with a different IP and an empty server list. Do it right and your players experience a one-hour maintenance window, nothing more. Here is the exact process I use when moving a city to new hardware.
Pre-Migration Audit
Before you touch anything, get a clear picture of what you are actually running. Log into txAdmin, go to Live Console, and note the FXServer artifacts build number — you need to match this exactly on the new box. Check your server.cfg for every ensure line and confirm the load order. If you are running scripts from a store like scripts-tebex.io, verify which versions are installed so you can replicate the exact state rather than accidentally upgrading mid-migration.
- Artifacts version: note the build hash from the FXServer binary or from txAdmin > System > Info.
- Active resources: export the full resource list with their start order from server.cfg.
- Database name and user: confirm credentials in your server.cfg oxmysql connection string.
- txAdmin recipe: if you deployed via recipe, export or note it — you will re-import it on the new host.
Taking a Known-Good Backup
Do this on the live server, during low-traffic hours, before you provision the new machine. A backup taken mid-migration is not a real backup.
Database
Dump the full oxmysql database. Replace the placeholders with your actual values:
mysqldump -u DB_USER -p DB_NAME --single-transaction --routines --triggers > fivem_$(date +%Y%m%d).sql
The --single-transaction flag is important for InnoDB tables — it avoids table locks while the dump runs, so you can keep the server live. Store the dump somewhere off-box immediately: SFTP to your workstation, upload to object storage, whatever you have available.
Resources and Server Data
Rsync the entire resources folder and your server-data directory to the new host. Run this from the old box:
rsync -avz --progress /path/to/resources/ newserver:/path/to/resources/ rsync -avz --progress /path/to/server-data/ newserver:/path/to/server-data/
Do a second rsync pass immediately before cutover to catch any files that changed since the first pass.
Setting Up the New Host
Download the exact same FXServer artifacts build you documented in the audit. Do not use the latest build unless your old server was already on it — artifact updates can break script compatibility silently.
- MariaDB / MySQL: install and create the database, user, and grant permissions matching your connection string exactly.
- Import the dump: mysql -u DB_USER -p DB_NAME < fivem_YYYYMMDD.sql
- txAdmin: install and point it at your server-data. If you used a recipe, import it; otherwise drop your backed-up server.cfg in place and verify every path is correct for the new host's directory structure.
- Cfx.re license key: your server license key from keymaster.fivem.net is tied to your account, not to hardware. Copy the same key into server.cfg on the new machine. You do not need to generate a new one.
Staging Dry Run
Bring the new server online on its own IP on a non-standard port (e.g., 30120 is fine, but keep it off DNS for now). Boot to live console in txAdmin and watch for errors. Common issues at this stage:
- Resource start order mismatches — a script trying to load before its dependency is ensured.
- Missing convars or environment variables that were set on the old host but not transferred.
- Database connection failures if the new DB user permissions are wrong.
Walk through a full server boot, connect with a test account, check your most complex scripts — phone systems, housing, banking — and confirm data loads from the database correctly. If you use a performance monitoring script to watch resource tick times, tools from 0resmon-tebex.io make it easy to catch regressions before you expose players to them.
Maintenance Window and Player Communication
Pick a time when your player count is lowest — usually early morning for EU servers, late night for US. Give at least 24 hours notice in your Discord with the exact window, and post a 30-minute reminder. Use txAdmin's scheduled restart message to push an in-game countdown. Be specific: "Server will be down from 03:00 to 04:00 UTC for hardware migration." Vague maintenance messages create more support tickets than clear ones.
DNS and IP Cutover
If your players connect via a direct IP, you will need to announce the new IP after migration. If you are using a domain (A record pointing to the server IP), update the DNS record as part of the cutover window. Set your TTL low (300 seconds) at least an hour before the window so the change propagates fast.
Update your Cfx.re server listing entry — the listing is tied to your license key, so once the new server is running the same key it will reclaim the listing automatically when it first connects to the infrastructure. You do not need to re-register.
Rollback Plan
Keep the old server in a stopped-but-intact state for at least 48 hours after the cutover. Do not wipe it, do not decommission it immediately. If something surfaces on the new host — data corruption, a script that behaves differently on the new kernel version, unexpected load spikes — you can point DNS back to the old IP and be live again in under five minutes. Only decommission the old host once you are satisfied the new one is stable under real player load.
A well-executed migration is invisible to players. The work goes into the preparation: the audit, the staged dry run, and having a rollback path ready. If you are building out or expanding your server's script stack around a migration, checking the catalog at febex.io is a good way to find vetted resources before you commit to what goes on the new box.
