Back to Blog

This guide applies to migrating from any CLI-based DDoS detection tool (FastNetMon Community Edition, FastNetMon Advanced, custom solutions) to any dashboard-based alternative. We use Flowtriq as the example target because we know the migration path, but the principles apply regardless of which tool you choose.

The migration fear: detection gaps

The biggest concern when switching detection tools is the gap between "old tool turned off" and "new tool tuned and trusted." During that gap, attacks go undetected or unmitigated. This concern is valid, and the solution is to eliminate the gap entirely by running both tools in parallel.

The 5-step migration plan

Step 1: Week 1

Deploy the new tool alongside the existing one

Install the new detection tool without disabling the old one. Agent-based tools (like Flowtriq) can run on the same servers that your flow-based tool monitors, because they use different data sources. The agent reads network interfaces directly; the flow tool consumes NetFlow/sFlow from routers. Both observe the same traffic without interference.

  • Set the new tool to detection-only mode (alerts but no automated mitigation)
  • Keep the old tool as your active mitigation system
  • Configure alerts from the new tool to a separate channel so you can compare
Step 2: Week 1-2

Map your thresholds and whitelist

Document every threshold, whitelist, and mitigation rule in your current CLI tool. Then configure equivalent rules in the new tool.

  • Export your current thresholds: PPS, BPS, flow limits per host
  • Export whitelists: IPs, prefixes, or ASNs that should never trigger detection
  • Document callback scripts: what they do, what external systems they call
  • Note any custom tuning that has accumulated over months of operation
Step 3: Week 2-3

Compare detection quality

With both tools running, wait for real traffic events (or generate controlled test traffic) and compare:

  • Does the new tool detect the same events as the old one?
  • Does it detect events the old tool missed (sub-threshold attacks, multi-vector)?
  • Does it generate false positives the old tool did not?
  • How do the alert details compare (classification depth, timing, accuracy)?
Step 4: Week 3

Migrate alerting and integrations

Point your operational alert channels (PagerDuty, Slack, email) at the new tool. If the new tool has an API, connect it to your SIEM, ticketing system, and any other integrations that previously relied on CLI output parsing or log scraping.

  • Migrate webhook destinations
  • Update PagerDuty/OpsGenie integration endpoints
  • Connect SIEM ingest to the new tool's API or webhook output
  • Update any internal dashboards or status pages
Step 5: Week 3-4

Enable mitigation and cut over

Once you trust the new tool's detection accuracy:

  • Enable automated mitigation on the new tool
  • Disable automated mitigation on the old tool (keep it running for detection comparison)
  • Monitor for 1 week with the new tool handling mitigation
  • When confident, decommission the old tool

What to migrate from specific tools

From FastNetMon Community Edition

  • Thresholds: PPS, BPS, and flows thresholds from /etc/fastnetmon.conf
  • Whitelist: IP/prefix whitelist from the whitelist configuration
  • Callback scripts: Document what notify_about_attack.sh does (BGP announcement, email, Slack webhook)
  • BGP configuration: If using ExaBGP or GoBGP for RTBH, the new tool will need the same BGP peer configuration

From FastNetMon Advanced

  • Everything above, plus per-hostgroup thresholds and FlowSpec rule templates
  • If you have LiveView, note which users have access and what roles they use (map to the new tool's RBAC)
  • API integrations that use fcli or the gRPC interface need to be rewritten for the new tool's API

From Andrisoft Wanguard

  • Sensor configuration: Flow exporter mappings and threshold profiles
  • Filter rules: Active mitigation rule sets from the Wanguard Filter component
  • Console users: Map Wanguard console users and roles to the new tool's RBAC
  • Anomaly profiles: Custom anomaly detection profiles that define what constitutes an attack

Common migration mistakes

  • Migrating during an active attack. Do not start a migration when you are under attack. Wait for a quiet period.
  • Disabling the old tool before trusting the new one. Run in parallel until you have seen the new tool handle at least one real detection event.
  • Forgetting to migrate whitelists. The first false positive after migration is often a whitelisted IP that was not carried over.
  • Not testing mitigation before going live. Verify that BGP FlowSpec and RTBH rules from the new tool are accepted by your routers before relying on them during an incident.

Migration support included with every Flowtriq plan

We help you migrate thresholds, configure BGP peers, and validate detection accuracy during parallel operation. 14-day free trial, and we extend it if you need more time for migration testing.

Start Free Trial →

Frequently asked questions

How do I migrate from CLI-based DDoS detection?
Run both systems in parallel: install the new tool alongside your existing detection, compare alert quality for 1-2 weeks, migrate thresholds and mitigation rules, then cut over when confident. The parallel operation period eliminates any detection gap.
Can I run two DDoS detection systems at the same time?
Yes. Agent-based tools can run alongside flow-based tools because they use different data sources. The agent monitors interfaces directly while flow tools consume NetFlow/sFlow from routers. Only run automated mitigation on one tool at a time to avoid conflicting rules.

The bottom line

Migration does not require a detection gap. The parallel deployment model lets you validate the new tool with real traffic before trusting it with mitigation. Budget 2-4 weeks for the full migration, with the first week focused on deployment and threshold mapping, the second on detection comparison, and the third on alert migration and cutover. The worst way to migrate is under pressure during an incident. Plan it during a quiet period, execute it methodically, and keep the old tool running until you are confident.