Moving a live FiveM server requires careful preparation. Rushing the process can lead to corrupted player data, broken script states, or an offline server with a mismatched IP address. Proper planning ensures your community experiences only a brief maintenance window. Here is the exact method for transitioning a city to new infrastructure.
Pre-Migration Audit
Before making any changes, review your current setup thoroughly. Access txAdmin, open the Live Console, and record your exact FXServer artifacts build number to replicate it on the new machine. Inspect your server.cfg file to note every ensure line and confirm the precise load order. If your community utilizes items from a FiveM script store, document the active versions so you can maintain consistency rather than attempting upgrades during the move.
- Artifacts version: Record the build hash directly from the FXServer binary or inside txAdmin under System and Info.
- Active resources: Export your complete resource startup sequence from the main configuration file.
- Database credentials: Note the username, password, and database title from your oxmysql connection string.
- txAdmin setup: Export or save your deployment recipe if you used one, ready for re-importing on the destination host.
Securing a Reliable Backup
Perform these steps on your live server during low-traffic periods prior to provisioning the destination machine. Never rely on a backup generated midway through a transfer.
Database Export
Dump your complete oxmysql database using the appropriate command structure:
mysqldump -u DB_USER -p DB_NAME --single-transaction --routines --triggers > fivem_$(date +%Y%m%d).sql
The single-transaction flag is vital for InnoDB tables because it prevents table locks during the dump, allowing your server to remain online. Transfer the resulting file off-box immediately via SFTP or object storage.
Resources and Server Data
Transfer your resources and server-data folders to the new machine using rsync from the source box:
rsync -avz --progress /path/to/resources/ newserver:/path/to/resources/ rsync -avz --progress /path/to/server-data/ newserver:/path/to/server-data/
Run a secondary rsync synchronization right before the final cutover to catch any files modified since the initial transfer.
Configuring the New Host
Install the identical FXServer artifacts build you recorded during your initial audit. Avoid defaulting to the newest build unless your previous environment already used it, as silent compatibility changes can break standalone FiveM resources or complex frameworks like QBCore and ESX.
- MariaDB or MySQL: Set up the database environment, create the user, and assign permissions to match your connection string.
- Import the database: Run the import command using your saved SQL dump file.
- txAdmin installation: Install txAdmin and point it toward your server-data directory, importing your recipe or placing your verified server.cfg into position.
- License key: Your server license key from the Cfx.re keymaster is tied to your account profile rather than specific hardware. Paste your existing key into the configuration file on the new machine without generating a replacement.
Performing a Staged Dry Run
Launch the new server independently on a non-standard port while keeping it detached from your public DNS records. Monitor the txAdmin live console closely for errors. Common issues at this stage include incorrect resource startup sequences, missing console variables, or database connection refusals caused by permission errors.
Test a complete boot cycle, join with a test profile, and verify complex systems like housing, inventories, and phones load properly from the database. Testing resource performance using monitoring scripts helps catch regressions before players log in.
Maintenance Window and Player Communication
Select a time when your player concurrency is lowest, such as late night or early morning depending on your region. Provide at least twenty-four hours of notice within your community Discord, followed by a thirty-minute warning. Leverage txAdmin scheduled announcements to broadcast in-game countdowns to ensure everyone stays informed.
DNS and IP Cutover
If players connect via direct IP addresses, announce the replacement address clearly after the move. Communities using domain-based A records should update their DNS settings during the cutover window, reducing Time-To-Live values beforehand for faster propagation.
Your Cfx.re server listing is tied directly to your license key, meaning the public hub listing will automatically reclaim its place once the new machine connects. Manual re-registration is unnecessary.
Establishing a Rollback Plan
Leave the original server instance intact and stopped for at least forty-eight hours following the cutover. Avoid wiping or decommissioning the old host immediately. If unexpected issues emerge on the new hardware, such as kernel-related bugs or database anomalies, you can revert your DNS records instantly and restore service in minutes. Decommission the old machine only after confirming long-term stability under full player loads.
