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.
Roby Einstein
FairShieldAC Security Team

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 step | Why it matters | What breaks if you skip it |
|---|---|---|
| Audit every resource that can kick, ban or defer | You cannot export an asset you cannot locate, and the server binary ships no ban command | A second resource was also banning people, and half your enforcement leaves with it |
| Export bans and the evidence behind them | Automatic backups lag; txAdmin's own fallback expects a five minute rollback | Appeals arrive with no ban record, no reason string and no author to ask |
| Ask where bans live and how you get them out | Identifier-keyed rows travel; server-specific token keys do not | You arrive with a list the new system cannot match, and learn your exit cost on the way out |
| Check identifier availability in the new environment | Steam identifiers require a Steam Web API key to be returned at all | Rows 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 key | Parity makes the test predictive, and game build cannot be changed at runtime | You validated behaviour on a server that does not resemble yours |
| Run log-only before enforcement | Detection output is your tuning data; enforcement is the irreversible part | You tune on live players and reverse real bans |
| Re-tune sensitivity from the new defaults | Thresholds encode a detection model and do not port between products | A false-positive wave, or a quiet gap nobody notices for weeks |
| Re-point alerts and brief staff | Webhooks and listeners are bound to the old stack's events | Detections fire into a channel nobody reads, on a ticket format that no longer maps |
| Cut over off-peak: stop old, refresh, ensure new | Both systems can own the connect gate and refuse a player | Double detections, contradictory kicks and two sets of logs to reconcile |
| Keep the old system's records | Rows carry author, reason and timestamp, and revocation is a field rather than a deletion | Six 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.