Ticket
Back to Blog
GuideOctober 2, 2026

Switching FiveM Anticheat Without Losing Your Bans

Switching FiveM anticheat? Here's the migration order: back up bans, stage on a test server, run log-only, cut over off-peak, and re-tune from scratch.

FairShieldAC

Roby Einstein

FairShieldAC Security Team

Updated: Oct 2, 2026
Featured image for Switching FiveM Anticheat Without Losing Your Bans

Your ban list moves with you only if you can reach the file or table it lives in, and the safe order is audit, export, stage, log-only, re-tune, cut over off-peak, keep the old records. Switching FiveM anticheat is a migration, and the expensive part is rarely the install. It is the ban history and the staff habits around it.

Not sure yet whether the problem is the product or your config? Start with why cheaters still get through. If the decision is made, this is the order that keeps a live server intact.

  • 1. Audit. Every resource that can kick, ban or refuse a connection, and where it stores records.
  • 2. Export. Your own copy of the ban rows, and ask any vendor how you get the list out before you pay.
  • 3. Stage on a test server. Matched game build, matched OneSync mode, its own license key.
  • 4. Log-only. Detect without enforcing for a full traffic cycle, including your busiest event.
  • 5. Re-tune from the new defaults. Thresholds do not port between products.
  • 6. Re-point alerts and brief staff. Webhooks are bound to the old stack.
  • 7. Cut over off-peak, keep the old records. Appeals arrive late, and the reason string settles them.

One rule sits above all seven: never run two anticheats in production at once. Briefly on a test server for comparison, fine. Live, you get double detections, contradictory kicks and logs nobody can reconcile.

This guide does not pick your replacement. Choosing the best FiveM anticheat and migrating to one are separate jobs, and compressing them into a single weekend is how ban lists get lost.

Do your bans transfer when you switch FiveM anticheat?

It depends on where they live and what they are keyed on. The documented FXServer command set gives you clientkick and status, and contains no ban command. Every ban you have issued was written by a resource, a panel or a vendor backend, which makes portability a supplier question.

The split that matters is identifier-keyed rows versus token-keyed rows. Identifiers such as license, license2, steam, discord, fivem and ip are strings the server reports, so a row keyed on one can be matched elsewhere. Hardware-flavoured keys differ: Cfx documentation for the server-side player token API states that tokens can be used to enhance banning logic but are specific to a server. Which your list keys on is a fair question for any vendor, FairShieldAC included. HWID bans explained has more.

Step 1: audit every resource that can kick, ban or defer

A FiveM anti cheat is a resource like any other, so read your server.cfg as an enforcement inventory. If the detection model is new to you, what a FiveM anti cheat is and how detection works is the background; here only one question matters - which resources can refuse a player. Anything hooking the connect gate qualifies: the documented deferral flow lets a resource defer a connection and finalise it with a failure reason. Two or three resources commonly hold that power.

Where the records sit depends on your stack. txAdmin ships preinstalled with FXServer and keeps a self-contained player database with a backup tool, no MySQL required. QBCore and Qbox both ship a bans table carrying name, license, discord, ip, reason, expire and bannedby. The official ESX core SQL defines no bans table, so ESX bans live in txAdmin or a third-party resource. Anticheat vs txAdmin covers that split.

Step 2: export the ban list and the evidence behind it

txAdmin writes its player database to playersDB.json in the profile data folder and keeps a rolling backup beside it. That backup runs on the five minute standby interval, and its own recovery path warns a five minute rollback is expected. Fine for a crash. For a migration, take a copy you made yourself.

Take the evidence with the rows. txAdmin's docs note that warn, ban and whitelist actions are stored in the admin logs as well as the players database. Admin logs rotate on a seven-day interval with no file-count or size cap, while the server and FXServer console logs rotate daily and are pruned. A ban row carries identifiers, optional hardware ids, a reason, an author, a timestamp and a revocation field, so an unban does not erase history.

Step 3: stage the new anticheat on a test server

Parity makes staging predictive. Match the game build, since sv_enforceGameBuild can only be specified at startup and cannot be changed at runtime, match your OneSync mode, and carry the same hardening convars across. Check identifiers too: steam_webApiKey is documented as required for Steam identifiers to be returned, so confirm coverage before you rely on the imported list.

Give the staging server its own license key from the Cfx portal. Community guidance on the Cfx forums, not documentation, is consistent that a key should not be shared across servers. Whatever you arrange with any vendor, us included, evaluate on a server with no players first, and let how to test your FiveM anticheat safely own the method.

Step 4: run log-only before you let it enforce

Log-only means detections are written to your logs while nobody is kicked or banned. Run it that way long enough to cover a full traffic cycle, including your busiest event. Tune on live players instead and every mis-set dial becomes a ban you must reverse.

Why you should not run two FiveM anticheats in production

Stacking anticheats is install-time advice and it does not survive a migration. Both systems register handlers on the same events, and each gets its own deferral on the connect gate.

The result, architectural reasoning rather than measured data, is one incident producing two records in two stores, a kick arriving from whichever gate closed first, and a reason string that may not match the detection your staff are investigating. The drop record names the resource that dispatched it, which is how you untangle things. Stage both if you like. Enforce with one.

Step 5: re-tune thresholds from the new defaults

There is no mapping between one product's sensitivity settings and another's. Thresholds encode a specific detection model, so carrying numbers across means nothing. Start from the new defaults and re-tune by category, covering movement-derived checks, health and damage-derived checks and resource integrity, then rebuild your script allowlist.

Plan for a false-positive tail in the first tuning weeks. Stricter is not automatically better, and false positive causes and fair appeals covers the trade-off and appeals. Nobody has a zero false-positive rate, ourselves included.

Step 6: re-point alerts and brief staff

Alerting is plumbing bolted to the old stack. txAdmin broadcasts named events when a ban is issued or revoked, and its Discord channel setting starts empty until somebody fills it, so your automation listens for something specific from the product you are removing. Re-point every webhook and channel before cut-over, then push a test detection through and watch it land.

Staff need the same pass, because ban ids change shape and the workflow your admins learned no longer maps. Discord alerts and webhooks covers alerting, and the cheater report workflow covers triage and evidence.

Step 7: cut over off-peak and keep the old records

The cut-over is short. Stop the old resource, refresh so the server rescans the resources folder and reloads manifests, then ensure the new one, which restarts a resource if it was started and starts it if it was not. Do it at your quietest hour, with an admin on the console and a rollback step agreed first. The setup guide covers the install.

Check manifests first: a resource can declare that it provides another, so it can start in place of the resource it names. Afterwards, archive the old export where admins can read it and keep the old logs through a full appeal cycle.

Migration steps, and what breaks if you skip them

The same sequence, with the cost of skipping each step.

Migration stepWhy it mattersWhat breaks if you skip it
Audit every resource that can kick, ban or deferYou cannot export an asset you cannot locate, and the server binary ships no ban commandA second resource was also banning people, and half your enforcement leaves with it
Export bans and the evidence behind themAutomatic backups lag; txAdmin's own fallback expects a five minute rollbackAppeals arrive with no ban record, no reason string and no author to ask
Ask where bans live and how you get them outIdentifier-keyed rows travel; server-specific token keys do notYou arrive with a list the new system cannot match, and learn your exit cost on the way out
Check identifier availability in the new environmentSteam identifiers require a Steam Web API key to be returned at allRows keyed on an identifier your new environment does not collect will not match, so confirm identifier coverage before you rely on the imported list
Stage on a test server with matched build and its own keyParity makes the test predictive, and game build cannot be changed at runtimeYou validated behaviour on a server that does not resemble yours
Run log-only before enforcementDetection output is your tuning data; enforcement is the irreversible partYou tune on live players and reverse real bans
Re-tune sensitivity from the new defaultsThresholds encode a detection model and do not port between productsA false-positive wave, or a quiet gap nobody notices for weeks
Re-point alerts and brief staffWebhooks and listeners are bound to the old stack's eventsDetections fire into a channel nobody reads, on a ticket format that no longer maps
Cut over off-peak: stop old, refresh, ensure newBoth systems can own the connect gate and refuse a playerDouble detections, contradictory kicks and two sets of logs to reconcile
Keep the old system's recordsRows carry author, reason and timestamp, and revocation is a field rather than a deletionSix weeks later you cannot answer why somebody was banned

What to measure before and after the switch

Without a baseline you cannot say whether the new FiveM anticheat helped. Capture these before you move and again a month after.

  • Detections per 1,000 player-hours, so the figure survives a change in player count.
  • Bans per week and the share later reversed, your honest false-positive proxy.
  • Median time from first alert to a staff decision, where alerting changes show up.
  • Server thread time and hitch frequency at a comparable player count. txAdmin charts threads against players.
  • Client cost on a fixed route with the resource monitor. How to measure the real cost has the method.

Frequently asked questions

Do my existing bans transfer when I switch FiveM anticheat?

Only if you can export them and the new system matches the same identifiers. Rows keyed on license, discord or steam are portable strings; hardware-derived keys are documented as specific to a server. Ask where the list is stored, and how you get it out, before you buy.

Can I run two FiveM anticheats at the same time?

On a test server, briefly, for comparison, yes. In production, no. Both can own the connect gate, so one incident produces two records, the kick a player receives comes from whichever gate closed first, and staff reconcile two sets of logs during an appeal.

How do I back up my FiveM ban list before changing anticheat?

Take your own copy off the server: dump the framework bans table if your stack has one, copy the txAdmin player database file, and archive the admin logs. Keep the evidence too, because logs rotate on a schedule you did not choose.

Your next step

Pick a quiet week. Audit, export, stage, log-only, re-tune, re-point alerts, then cut over off-peak. Whichever product you settle on as the best FiveM anticheat for your server, the order above does not change. Still choosing? The ranked comparison is best FiveM anti cheat in 2026, and the criteria including exit cost sit in the 2026 scorecard, the neutral way to score any vendor including us. Our plans and dated changelog are the FairShieldAC specifics, and how to test your FiveM anticheat safely is the next read.

Related Articles

FairShieldAC

Roby Einstein

FairShieldAC Security Team

The FairShieldAC team is dedicated to keeping FiveM communities safe and fair. Our articles are written by server security professionals with years of experience in game anti-cheat development and network protection. We constantly test against the latest cheat menus to ensure our guidance stays current and actionable.

This article was researched and written by the FairShieldAC team based on our direct experience developing and operating anti-cheat protection for FiveM servers. Last reviewed: October 2, 2026.