This is the shortest migration in the entire cybersecurity category, and it is worth saying why up front. Corelight sells sensors built on Zeek, the open network-monitoring framework, with Suricata alongside it. The log formats are Zeek’s, the scripting language is Zeek’s, and the analytical model is Zeek’s. Everything downstream, your SIEM parsers, your detections, your dashboards, your analysts’ habits, is already built against open technology.
That makes the technical migration unusually low-risk and puts the entire decision on one question: is Corelight’s packaging worth its subscription in your environment? This guide is mostly about answering that honestly rather than about migration mechanics, because the mechanics are genuinely straightforward.
Start with a log diff, because it is your entire scope
Before any planning, run open Zeek on a copy of the same traffic a Corelight sensor is watching, for a full day, and diff the output.
You will find three categories. Log types and fields that are identical, which is the majority and the reason this works. Corelight additions that are not in open Zeek, extra collections, inference logs, enrichment fields added at the sensor. And normalisation differences where Corelight has cleaned up or standardised something.
For each item in the second and third categories, ask one question: does any detection, dashboard, or investigation workflow depend on it? Most will not. The ones that do are your migration work, and they are usually addressable with a custom Zeek script or by moving the enrichment downstream into your SIEM pipeline, where arguably it belonged anyway.
That diff is the scope. Everything else in this project is deployment engineering.
What the subscription actually buys
Be fair to the product here, because underestimating this is how the migration goes wrong.
Capture engineering. Running Zeek at high packet rates without loss is the hard part of network monitoring, and it is not obvious work. NIC choice, driver and ring-buffer configuration, AF_PACKET fanout or PF_RING, CPU pinning, worker counts, and cluster topology all matter, and getting them wrong produces a sensor that looks healthy and silently misses traffic. Corelight has done this engineering and validated it on specific hardware.
Suricata content management. Corelight curates and updates rulesets. Open Zeek does not include Suricata at all, so you are deploying and managing it separately, choosing rule sources (ET Open or a paid feed), and handling updates.
Enrichment and integrations. Additional context on logs, and packaged export paths into common SIEMs.
Fleet management. A control plane for many sensors, versus configuration management and your own tooling.
Support. Someone to call when a sensor misbehaves at 2am.
If your monitored links are modest, your team runs Linux confidently, and your detections come from your SIEM rather than from Corelight’s additions, most of that is replaceable with effort you already have. If you are watching multi-gigabit links with no capture-tuning experience on the team, the subscription is buying you a genuine capability.
The mapping
- Corelight sensor → Zeek on commodity hardware, standalone or in cluster mode depending on rate.
- Corelight’s bundled Suricata → Suricata deployed separately, with a chosen ruleset and update mechanism.
- Corelight Fleet manager → configuration management (Ansible or equivalent) plus your monitoring.
- Sensor-side enrichment → SIEM-side enrichment in your ingest pipeline.
- Corelight-specific log types → custom Zeek scripts, or an accepted gap, per the diff.
- Export integrations → Filebeat, Kafka, or direct log shipping from the sensor.
- Support contract → your on-call rota, plus the Zeek community and optional third-party support.
Sizing and the packet-loss discipline
The one thing that must not be casual is capture loss instrumentation.
A Zeek deployment dropping packets does not fail loudly. It produces logs that look complete and confident and are quietly missing sessions, which corrupts every conclusion drawn from them. Instrument capture statistics from the first day, alert on drop rate crossing a threshold, and review it weekly rather than treating it as a deployment-time check.
For sizing, a rough approach: start with a standalone Zeek on a modern server for links up to around a gigabit of real traffic, and move to cluster mode with load balancing across workers above that. Measure rather than trust the estimate, because packet rate and protocol mix matter more than headline bandwidth, and a link full of small packets is far harder than one full of bulk transfers.
Run the new sensor alongside the Corelight sensor on duplicated traffic and compare connection counts. If open Zeek is logging materially fewer connections than Corelight on identical input, you have a capture problem, not a configuration difference, and that comparison is the cleanest test you will get.
Order of operations
- Diff a day of Corelight logs against open Zeek on the same traffic, and classify every difference.
- Check every custom script for Corelight-specific events, fields, or packages.
- Decide what happens to Suricata: deploy separately, with a chosen ruleset and update path.
- Size and build the sensor, standalone or cluster, with capture-loss instrumentation from day one.
- Run in parallel on duplicated traffic, comparing connection counts and log volumes.
- Close the diff: write scripts or move enrichment into the SIEM for the differences that matter.
- Re-point log shipping to the new sensor while keeping Corelight active.
- Soak for a full month, including a peak traffic period, watching drop rates.
- Retire the sensor subscription at its renewal boundary, once the parallel period is clean.
Clearing the bar before you cut over
Connection counts match Corelight’s on identical traffic within a small margin. Capture loss is instrumented, alerting, and near zero at peak. Every custom script runs and produces output. Suricata is deployed with a maintained ruleset and a working update mechanism. Every log field a detection or dashboard depends on is present, either natively or via a replacement script. And someone owns the sensor operationally, by name.
The short version
Corelight to Zeek is the least locked-in migration in this category, because the product is the open engine plus packaging. Diff the logs first, since that diff is the entire scope. Be honest that the subscription buys real capture engineering, curated Suricata content, and support, and that your traffic rate largely determines whether replacing those is trivial or genuinely hard. Instrument packet loss from day one, because a silently dropping sensor is worse than none. Use the calculator above for illustrative economics, and count the hardware, the Suricata management, and the on-call ownership as the price of dropping the subscription.