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 run both in parallel, validate, 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.

Why teams migrate

FastNetMon is a capable tool for ISPs with dedicated hardware and BGP router infrastructure. But teams consistently run into the same friction points that make it the wrong fit for modern, cloud-mixed, or resource-constrained environments:

Cloud deployments don't work well. AWS, GCP, and Azure don't expose SPAN/port mirroring, and VPC Flow Logs have a 10-15 minute delay — useless for real-time DDoS response. FastNetMon's license is also tied to a hardware fingerprint and IP, which breaks on cloud instances when IPs change.
You need a dedicated server just for the monitor. FastNetMon requires its own machine — at minimum 8 GB RAM and 250 GB storage — separate from the servers you're protecting. That's $80-$200/month before your license starts.
Automated mitigation needs a BGP router. Without BGP peering, FastNetMon can only alert — it can't block. Setting up BGP peers, FlowSpec-capable routers, and upstream RTBH communities requires router expertise most teams don't want to maintain.
FastNetMon Community isn't production-ready. FastNetMon's own docs say Community is "best for labs and tests." No built-in UI, no email alerts without custom scripting, no per-host thresholds, no FlowSpec.

If any of those resonate, this guide is for you. The migration is low-risk: you run Flowtriq alongside FastNetMon 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	Run both tools in parallel (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 7-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

Run the one-line installer on each Linux server you want to monitor. The agent installs as a systemd service and starts sending data to your dashboard within 30 seconds. No reboot required.

# Download and install the Flowtriq agent
curl -sL https://flowtriq.com/install | bash

# Configure with your API key
flowtriq configure --key YOUR_API_KEY

# Enable and start the service
systemctl enable --now flowtriq

# Verify it's running
systemctl status flowtriq

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

Unlike FastNetMon, the Flowtriq agent does not need to receive sFlow or NetFlow from your switches. It monitors traffic at the kernel level on the server itself, so you don't need to reconfigure your routers or switches at all for this step.

~10-20 minutes

Configure your alert channels

In the Flowtriq dashboard, go to Alerts and connect the channels your team uses. This is where Flowtriq replaces FastNetMon's custom notify.sh shell script with built-in integrations.

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, replacing FastNetMon Community's single global threshold with per-server sensitivity.

2-7 days (passive)

Run FastNetMon and Flowtriq in parallel

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? (It should — and often catches more at the per-server level)
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 sampling from your switches). Flowtriq detects at the individual server level. You may see Flowtriq alert slightly faster because it sees the actual packet rate hitting the server rather than a sampled aggregate from the network.

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 is now free. You can repurpose or decommission it — it's no longer needed because Flowtriq agents run on your existing infrastructure.

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 keep FastNetMon for network-wide flow monitoring alongside Flowtriq?

Yes, absolutely. Flowtriq and FastNetMon can coexist. Some teams use FastNetMon for network-wide aggregate flow monitoring (sFlow from their core switches) and Flowtriq agents on individual servers for per-host PCAP forensics and faster per-server alerting. The tools operate at different layers and don't conflict.

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 FastNetMon's 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 — you'd continue using FastNetMon or another flow collector for that, alongside Flowtriq agents on your servers.

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 FastNetMon users switching to Flowtriq. If you're on FastNetMon Advanced and have remaining license time, reach out to us and we'll discuss what we can offer to make the switch easier on your budget. We want the decision to be about the right tool, not about sunk costs.

Ready to make the switch?

Start your 7-day free trial and have Flowtriq running alongside FastNetMon today. Or reach out to us about migration support — we'll help you plan the cutover.

Start Free Trial → Talk to us about migration

Back to Blog

How to migrate from FastNetMonto Flowtriq in a few hours