Migrating from Another Anticheat

If you're running FiveGuard, Electron, Fini, or any other anticheat today, don't rip it out the day your Sculk build arrives. A migration that keeps your server protected the whole way through looks like this.

§11.1The golden rule: overlap, don't swap

Run Sculk alongside your current anticheat in observation mode — set sculk_observe "true" in server.cfg — for at least a week. The catalogue ships armed, so set this before players join. In observation mode every detection still runs and reports (OBSERVE would kick / would ban in the console, review events on the anticheat dashboard), but no automatic kick or ban lands, so the two systems can't fight — and you get to compare what each one sees on your real traffic before anything changes for players.

§11.2Step 1 · Export what you own

Before touching anything:

• Ban list. Export your current tool's ban/blacklist (most store licence identifiers, Discord IDs, and tokens in a database table or JSON file). Keep the raw export even if you don't reuse all of it — it's your community's memory.
• Detection history. If your current anticheat logs incidents, archive the logs. Old evidence settles future appeals.
• Whitelists and exemptions. The list of staff, streamers, and special cases that your current tool ignores is policy you already wrote — you'll want it again in Step 3.

Sculk imports ban identifiers at the licence level during rollout; open a ticket at /fivem/support with your export format and we'll map it.

§11.3Step 2 · Inventory before you configure

Work through the Event Policy Worksheet as if you had no anticheat. Don't port your old tool's config one-to-one: most client-scan-era configs are lists of menu signatures, which is not how a server-side policy model works. What carries over is your knowledge — which events were abused before, which resources are sensitive, who's allowed to do what.

§11.4Step 3 · Map your exemptions to policy

Old-style whitelists ("ignore this player entirely") become scoped exemptions in Sculk: staff get sculk.bypass.<detection> for the one detection their admin tool trips, rather than blanket invisibility, and a resource that legitimately teleports or heals a player says so first with the AddExcuse export. This closes the classic hole where a compromised staff account is invisible to the anticheat.

§11.5Step 4 · Observe side-by-side

With both systems running (yours enforcing, Sculk observing), compare for a week:

• What did Sculk surface that your current tool missed — especially event and economy abuse?
• What does your current tool flag that Sculk attributes to server bugs or sync artifacts?
• Where do both agree? That's your future block-list with confidence.

§11.6Step 5 · Cut over deliberately

Pick a quiet window. Set anything you do not trust yet to Log on the dashboard, run set sculk_observe false in the live console (no restart) and remove the line from server.cfg, downgrade your old anticheat to alerts-only for a few days if it supports that, then remove it. Announce the change to your community with the moderation model — server-side, staff-reviewed, appealable. It's a selling point for your server; use it.

§11.7Rollback plan

Keep the old resource and its config in a private repo for a month. If anything surprises you, re-enabling it is a five-minute job — and open a ticket with what happened, because "surprise during migration" is exactly the feedback the rollout period exists to catch.