Mitigations Apr 22, 2026 10 min read

How to migrate from FastNetMon
to Flowtriq in a few hours

FastNetMon works well in the right environment — but if you've hit its hardware requirements, cloud limitations, or BGP dependencies, this guide walks you through a clean, low-risk migration to Flowtriq. You'll install Flowtriq, validate its detection independently, then cut over.

We offer migration support

If you'd like help migrating from FastNetMon, reach out to the Flowtriq team. We offer guided migration support, and migration credits may be available for FastNetMon users making the switch — contact us to find out what we can offer your team.

Before you start

FastNetMon and Flowtriq take different architectural approaches to DDoS detection. FastNetMon uses centralized flow collection (sFlow/NetFlow) from network devices, while Flowtriq uses per-server agents that monitor traffic at the kernel level. Teams typically consider switching when their requirements have shifted toward one model or the other.

Common reasons teams evaluate a move include differences in deployment model (centralized vs. distributed), cloud compatibility, dashboard and alerting preferences, or budget considerations. If you have already decided to make the switch, this guide walks you through a clean, low-risk migration. The migration is straightforward: you evaluate Flowtriq independently for a few days, validate that alerts and detections are working correctly, then decommission FastNetMon when you're confident.

Migration overview

The full migration is six steps and typically takes a few hours of active work spread over a couple of days. The longest part is the parallel validation period — not configuration.

Step	Task	Time
1	Create Flowtriq account, get API key	5 min
2	Install agent on your servers	5-15 min
3	Configure alert channels	10-20 min
4	Validate Flowtriq detection independently (optional: 2-7 days)	Passive
5	Configure BGP integration (if used)	30-60 min
6	Decommission FastNetMon	15 min

Step-by-step migration

~5 minutes

Create your Flowtriq account and get your API key

Sign up at flowtriq.com/signup — no credit card required for the 14-day trial. Once inside the dashboard, navigate to Settings → API Keys and create a new agent key. Copy it somewhere handy; you'll use it in step 2.

If you're migrating a team deployment, you can create a single organization and invite your teammates before installing any agents.

~5 min per server

Install the Flowtriq agent on your servers

Install the ftagent package from PyPI on each Linux server you want to monitor. Then run the interactive setup wizard, which prompts for your API key and Node UUID. No reboot required.

# Install the Flowtriq agent
curl -sSL https://flowtriq.com/install.sh | sudo bash

# Verify it's running
sudo systemctl status ftagent

For mass deployments across many servers, see our mass deployment guide — it covers Ansible, Chef, Puppet, and cloud-init patterns.

The Flowtriq agent monitors traffic at the kernel level on the server itself, rather than receiving sFlow or NetFlow from your switches. This means you don't need to reconfigure your routers or switches for this step.

~10-20 minutes

Configure your alert channels

In the Flowtriq dashboard, go to Alerts and connect the channels your team uses. Flowtriq provides built-in integrations for common notification channels.

Slack / Discord — Paste your webhook URL and test it. Attack alerts arrive as rich formatted messages with attack type, PPS, source country, and a link to the PCAP.
PagerDuty / OpsGenie — Connect via integration key for on-call escalation.
Email — Add recipients directly in the dashboard. No shell scripting required.
Webhook — POST JSON payloads to any endpoint for custom integrations.
SMS — Add phone numbers for critical attack threshold alerts.

You can configure different alert thresholds for different servers or server groups for per-server sensitivity.

2-7 days (passive)

Validate Flowtriq detection before cutover

This is the most important step and also the most hands-off. Keep FastNetMon running exactly as it is. Let Flowtriq build its per-server traffic baselines — this takes 24-48 hours of observation — and watch for the first attack alerts to come through both systems.

Things to watch for during parallel operation:

Does Flowtriq detect the same events FastNetMon catches?
Are Flowtriq alerts arriving on the right channels with the right severity?
Is the Flowtriq dashboard showing accurate per-server traffic baselines?
If you use BGP mitigation via FastNetMon, hold off on configuring that in Flowtriq until step 5

You don't need to wait for a real attack — you can use the Flowtriq Attack Simulator or the Detection Terminal to trigger a simulated detection and verify your alert routing end-to-end.

Tip: FastNetMon detects at the network flow level (sFlow/NetFlow from your switches). Flowtriq detects at the individual server level. The two approaches have different detection characteristics, so comparing them side by side during the evaluation period is valuable.

30-60 min (if needed)

Configure BGP integration (if you use FastNetMon's BGP mitigation)

This step only applies if you are using FastNetMon's BGP blackhole (RTBH) or FlowSpec mitigation. If you're running FastNetMon in detection-only mode, skip to step 6.

Flowtriq supports BGP blackhole mitigation via ExaBGP or GoBGP. To configure it:

# In your Flowtriq dashboard:
# Settings → BGP Mitigation → Add BGP Peer

neighbor: YOUR_ROUTER_IP
local-as: YOUR_ASN
remote-as: ROUTER_ASN
next-hop: YOUR_BLACKHOLE_NEXT_HOP
community: YOUR_BLACKHOLE_COMMUNITY

See the full BGP mitigation documentation for router-specific configuration examples (Juniper, Cisco, Arista, MikroTik). The BGP FlowSpec Rule Builder can generate ready-to-use FlowSpec rules if you want granular filtering rather than full-prefix blackholing.

Test the BGP peer connection, then run a controlled test using the attack simulator or a known-safe traffic spike to verify auto-mitigation is triggering correctly before you remove FastNetMon from your BGP peering.

~15 minutes

Decommission FastNetMon

Once you're satisfied that Flowtriq is detecting correctly and your alerts and BGP integration are validated, you can remove FastNetMon.

# Stop and disable the FastNetMon service
systemctl stop fastnetmon
systemctl disable fastnetmon

# Remove FastNetMon (if you want to clean up completely)
apt-get remove fastnetmon   # Debian/Ubuntu
yum remove fastnetmon       # CentOS/RHEL

If FastNetMon was running on a dedicated server just for monitoring, that server can be repurposed or decommissioned.

If FastNetMon had BGP peering with your routers, remove the FastNetMon peer from your router configuration after you've confirmed Flowtriq's BGP peer is active and healthy.

Common questions during migration

Do I need to reconfigure my routers or switches?

No, for detection. Flowtriq agents monitor traffic at the server level — they don't need sFlow or NetFlow exports from your switches. If you want to retain BGP mitigation, you'll add a new BGP peer (Flowtriq) and remove the old one (FastNetMon), but your switch configuration doesn't change.

What happens to my historical attack data from FastNetMon?

FastNetMon stores attack history in ClickHouse (if you've configured it) or in flat log files. That data stays where it is — Flowtriq maintains its own attack history going forward from the install date. If you need to preserve FastNetMon's historical data for compliance or forensics, export it before decommissioning.

Can I run both during my evaluation period?

Flowtriq installs independently and does not require changes to your existing setup during the evaluation period. Flowtriq agents monitor traffic at the server kernel level, while FastNetMon consumes sFlow/NetFlow from your switches — they operate at different layers, so there are no port conflicts or resource contention. This makes it straightforward to compare detection results before committing to the switch.

Does Flowtriq support the same protocols as FastNetMon?

For server-level monitoring, Flowtriq monitors traffic directly at the kernel level — no protocol configuration needed. For BGP mitigation, Flowtriq supports BGP blackhole (RTBH) compatible with ExaBGP and GoBGP. If you're migrating from a flow-based architecture (sFlow/NetFlow from switches to a central FastNetMon instance), Flowtriq's model is architecturally different: instead of a central collector, each server runs its own agent. This means you get per-server granularity rather than sampled aggregate visibility.

What about sFlow/NetFlow collection? Flowtriq's architecture is server-agent-based rather than flow-collector-based. If you have a requirement to aggregate NetFlow or sFlow from network devices (switches, routers) into a single monitoring point, that's a different use case that requires a dedicated flow collector. Flowtriq is designed to replace FastNetMon's per-server detection role, not to serve as a network-wide flow aggregator.

Migration support and credits

Migrations don't always go smoothly, and we want yours to. The Flowtriq team offers migration support to help you through the process — from BGP configuration to alert tuning to mass deployment automation.

Migration credits may also be available for teams switching to Flowtriq. If you have remaining license time on your current tool, reach out to us and we'll discuss what we can offer to make the transition easier on your budget.

Ready to evaluate Flowtriq?

Start your 14-day free trial and compare Flowtriq against your current setup. Or reach out to us about migration support.

Start Free Trial → Talk to us about migration

Back to Blog

FASTNETMON is a registered trademark of Fastnetmon Limited. Flowtriq Networks Inc. is not affiliated with, endorsed by, or sponsored by FastNetMon.

How to migrate from FastNetMonto Flowtriq in a few hours