What a 2.4 to 3 migration involves
Security Onion 2.4 reached end of life on October 1, 2026, so any grid still running 2.4 needs a dated move off it. The clock matters for a second reason: Security Onion 3.0.0, released March 31, 2026, supports only Oracle Linux 9. A migration plan therefore has to settle the operating system question before it settles anything else, because that choice decides whether the existing installation can be upgraded in place or must be rebuilt.
There are two paths the supported facts allow. The first is an in-place upgrade, which applies only to 2.4 installations already running on Oracle Linux 9. Before that upgrade, full packet capture must move from Stenographer to Suricata, because 3.0.0 replaced Stenographer. The second is a fresh install on any other distribution, which means new nodes, a rebuilt configuration and a re-validated detection set. Confirm the current operating system on every node, including managers, search nodes and sensors, since a mixed estate can force different paths on different machines.
The short answer on in-house versus partner work: teams with a tested build process and a spare grid to rehearse on often keep most of the migration internal. Teams without a test grid or prior packet capture experience often bring in a partner for the cutover, where capture changes, detection continuity and rollback carry the most risk. Either way, decide early whether you will rehearse on matching hardware and data, because that decision drives the work more than the upgrade command does.
What the migration includes
Each card is a deliverable you receive, so your team can review it, keep it, and check the migration against it. Scope is agreed in writing before work starts.
Current grid inventory
We document every node in your 2.4 grid with its role, distribution, sensors, retention settings, custom Suricata, Sigma and YARA detections, integrations and airgap status. You receive the inventory as a working document, which becomes the checklist for the OS decision, the capture plan and the cutover. Items marked unknown are listed so you can confirm them before the test build.
OS and platform decision
Security Onion 3 supports only Oracle Linux 9, so distributions other than Oracle Linux 9 need a fresh install rather than an in-place upgrade. We record the decision, the reasons and the hardware check against the published minimums for each node role. You receive a short decision record that names the upgrade or rebuild path for each node.
Packet capture mapping plan
Stenographer is replaced by Suricata for full packet capture in Security Onion 3, so existing capture habits and retention expectations need a new mapping. We list each Stenographer use your analysts rely on and show how Suricata covers it, along with the gaps to resolve. You receive the mapping table and the capture retention settings to validate.
Tested upgrade or rebuild
We run the chosen path on a test grid that matches production node roles, sensor placement and integrations before anything changes in production. Detections, log sources and dashboards are checked against the inventory. You receive the test build record, the list of defects found and how each was resolved.
Cutover and rollback steps
The cutover runbook sets the order of node changes, sensor reattachment, DNS and integration updates, and the point at which the old grid stops receiving traffic. A rollback path is written for each step, with the condition that triggers it. You receive the runbook and rollback procedure, reviewed by your operations and security leads before the change window.
Handover document and validation results
The handover records the final architecture, configuration, access accounts, retention settings and open items, together with the validation results from the test and cutover checks. It gives your team what it needs to run and upgrade the grid without us. You receive the handover document and a signed validation summary that lists what was tested and what remains open.
What drives effort and duration
This table lists the factors that most change the work of moving a Security Onion 2.4 grid to version 3, why each one matters, and how to keep it contained.
| Driver | Why it matters | How to keep it contained |
|---|---|---|
| Node count and roles | A distributed grid has manager, sensor and search nodes, each patched and validated separately. Search nodes stop indexing if they cannot reach the manager. | Document a node inventory with roles and receiver nodes before any change. Confirm the sequence with the vendor. |
| Current operating system | Version 3 supports only Oracle Linux 9. Nodes on other distributions need a fresh install, which means rebuilding them. | Check each node's OS first. Group nodes by OS so rebuilds and upgrades run in known batches. |
| Custom Suricata, Sigma and YARA content | Local rules, thresholds and suppressions must be reviewed and retuned against the new platform before they carry over. | Export detection content into version control. Inventory suppressions and thresholds with owners before migration starts. |
| Stenographer captures in use | Full packet capture moves from Stenographer to Suricata, so analyst workflows and retention windows must be rebuilt. | Confirm which captures analysts use and how long they must be kept. Size storage before cutover. |
| Log sources and Elastic agent integrations | Each source and Fleet integration must be mapped, tested and validated on the new grid before it is retired from the old one. | Keep a source register with owners. Migrate in batches and retire unused integrations first. |
| Airgapped operation | Airgapped grids update from newer ISO media, so packages, rules and transfer approvals must be staged in advance. | Agree the media transfer and approval steps with your change board before the maintenance window opens. |
| SSO and Pro features in use | OIDC single sign-on, FIPS, LUKS, STIG and API integrations each need reconfiguration and retesting after the move. | List every Pro feature enabled today. Confirm entitlements and reconfiguration steps with the vendor. |
| Environments needing a matching test grid | Each production-like environment needs a test grid that mirrors its topology, OS and content to rehearse the migration. | Limit test grids to representative topologies. Document every difference from production and retest those gaps. |
Migration phases and outputs
The seven phases move a Security Onion 2.4 grid to version 3 in a controlled order, and each phase ends with a written output that the next phase depends on.
Discover and inventory the current grid
Your team or a partner records each node's role, operating system, hardware, network interfaces, sensor placement, Stenographer configuration and stored capture retention, along with the detections, custom rules and integrations in use. Output: a written inventory signed off by the platform owner that marks which installs run Oracle Linux 9 and which will need a fresh install.
Validate platform and hardware against current documentation
Confirm that each node runs Oracle Linux 9, the only distribution Security Onion 3 supports, and that its processor, cores, memory, storage and NIC count meet the current hardware requirements for its role. Output: a validation record for every node that lists each gap to close before upgrade work starts.
Design the packet capture transition to Suricata
Map every Stenographer dependency, including stored captures, retention settings, search habits and analyst workflows, to the Suricata full packet capture approach in version 3. Decide how existing captures are handled and who keeps access to them. Output: an approved design that covers retained data, analyst workflow changes and the sensor cutover order.
Build the test grid to match production
Build a non-production grid with the same deployment type, node roles and operating system as production, and bring it to the same version path. Load the rule sets, integrations and Elastic Fleet agent settings used in production, and connect it to representative traffic where your network allows. Output: a documented test grid that matches the production inventory.
Rehearse the upgrade or rebuild with functional checks
Run the in-place upgrade on Oracle Linux 9 installs and the fresh rebuild on the rest, then test each function: sensor capture, Suricata alerts, Zeek logs, console login, Detections, search node indexing and Fleet agent check-in. Record every failure and its fix. Output: a signed rehearsal report with a go or no-go recommendation for production.
Execute production cutover in a planned window
Apply the rehearsed steps to production in the order set during design, which should account for the manager's role in indexing, with a rollback point kept for each change. Confirm each node reports healthy before moving to the next one. Output: a cutover log that shows each node's version, state and rollback point.
Validate after cutover and hand over
Repeat the rehearsal functional checks against production, compare alert and log volumes with the pre-migration baseline, and confirm that detections, console access and retention behave as designed. Then transfer runbooks, configuration records and support contacts to your team. Output: a handover pack and written acceptance from the platform owner.
What teams keep and what they outsource
This table compares each Security Onion 2.4 to 3 migration activity by what your in-house team should keep and what a partner can take on, with the skills each one needs.
| Activity | Keep in-house | Outsource to a partner |
|---|---|---|
| Inventory and risk review | Owners who know sensor placement, custom Suricata and Sigma content, and which downtime the business will accept | Inventory of nodes, rules, log sources and risks, drafted for your change board to approve |
| OS and hardware validation | Linux administration on Oracle Linux 9 and sign-off on each node's hardware for its role | Oracle Linux 9 build checks, driver and NIC validation, and comparison against the published minimums |
| Packet capture redesign | Network traffic analysis to confirm what Suricata full packet capture must see after Stenographer is removed | Redesign of capture settings, storage and sensor sizing, with traffic analysis run by partner engineers |
| Test grid rehearsal | Ability to build a matching test grid and judge whether its results can be trusted for production | Rehearsal of the 2.4 to 3 path on a test grid, with a written record of each step and failure |
| Cutover | Change control experience and an analyst on hand to accept production traffic after the switch | Cutover runbook, go or no-go checks, rollback steps and a supervised cutover window |
| Detection and dashboard verification | Elastic administration and the analyst knowledge to confirm that alerts and dashboards still match expectations | Checks that Suricata, Sigma and YARA detections load, fire and display correctly after the move |
| Analyst training | Team members who will own the console, detections and queries after handover | Training sessions and written guides for the 3.x console, detection workflows and daily operations |
What usually goes wrong
Most failed Security Onion 2.4 to 3 migrations trace back to a few predictable decisions made before cutover. Each risk below includes the check or step that prevents it.
Upgrading an unsupported operating system
Security Onion 3.0.0 supports only Oracle Linux 9, and an in-place upgrade from 2.4 applies only to installations already running Oracle Linux 9. Other distributions need a fresh install, so starting an upgrade on them can leave a broken grid. Before any change, confirm the operating system and version on every manager, search, receiver and sensor node, and plan a rebuild for any node that does not qualify.
Assuming Stenographer retention carries over
Full packet capture moved from Stenographer to Suricata in 3.0.0, so retention behavior, disk layout and how analysts retrieve packets can differ from what the team knows on 2.4. Teams often assume their old retention expectations still hold. Record current capture retention and disk usage on each sensor, then test in a lab how long packets remain available under Suricata before cutover.
Detections and dashboards tied to old components
Saved searches, dashboards, hunts and playbooks may reference Stenographer pivots or fields produced by 2.4 components. After the switch, these can return empty results without raising an error, which can look like a quiet network. Inventory every custom query, dashboard and detection, flag those that touch packet capture or older component output, and retest each one on a test grid before cutover.
Losing ingestion during a manager outage
Search nodes stop indexing when they cannot reach Redis on the manager, so a manager outage during cutover can halt event ingestion without an obvious alert. Schedule the window with a defined reachability check from every search node before and after each change, and monitor indexing lag throughout. Confirm whether your design includes receiver nodes, since they add pipeline redundancy while the manager is unavailable.
Relying on an untested rollback
A rollback plan that has never been run is only a hypothesis. Returning a node to 2.4 may depend on backups, exported configuration and the state of stored data, and each of these can fail in ways the team has not seen. Rehearse the rollback on a matching test grid, time each step, name the person who authorizes it, and keep a restorable copy of the 2.4 configuration and detections.
Ignoring the 2.4 end-of-life date
Security Onion 2.4 reached end of life on October 1, 2026. Once a release is past end of life, the EOL documentation sets out what support and updates remain, so a delayed migration can turn into an emergency project. Set the cutover target against that date, confirm current support terms with Security Onion Solutions, and decide early whether a new 3 grid will run beside the existing one.
How the path changes by starting point
Your 2.4 grid already runs on Oracle Linux 9, so an in-place upgrade to 3 is a candidate once full packet capture moves from Stenographer to Suricata. The main decisions are whether the hardware still meets the 3.x requirements and whether your captured data and retention settings survive the change.
- Capture cutover: Plan how Stenographer retention ends and how Suricata full packet capture is enabled and validated before the upgrade.
- Hardware check: Confirm each node against the current hardware docs, including the manager, search and sensor minimums.
- Rule and tuning review: Inventory custom NIDS, Sigma and YARA rules and suppressions so you know what must be re-tested after the move.
- Rollback point: Decide how you will restore the grid if the upgrade fails, and confirm the backup approach with your team.
- Test first: Run the same steps on a matching test grid before touching production.
A 2.4 grid on any distribution other than Oracle Linux 9 cannot take the in-place path, so the work becomes a fresh 3 install with data and rule carry-over. The decisions focus on what you keep, what you rebuild and how you reconnect your sensors and analysts.
- Carry-over scope: Decide which custom Suricata, Sigma and YARA rules, tuning and dashboards move to the new grid and which are retired.
- Data retention: Confirm whether historical events must be kept, exported or accepted as lost, and how long the old grid stays online for reference.
- Node rebuild: Plan new manager, search and sensor nodes on Oracle Linux 9 with new network addressing and taps.
- Cutover sequencing: Decide when sensors switch to the new grid and how analysts are told which console to use.
- Access and identity: Recreate console accounts or SSO settings and verify role assignments before cutover.
A distributed grid with receiver nodes and search nodes has more moving parts, so the migration is sequenced by node role rather than as one upgrade. The architecture docs note that search nodes stop indexing when they cannot reach the manager's Redis, which makes the manager the first thing to get right.
- Upgrade order: Plan the sequence across manager, receiver, search and sensor nodes and confirm it against the upgrade documentation.
- Manager availability: Schedule a window where the manager can be upgraded without losing indexing, and confirm your receiver node behavior during that window.
- Search node capacity: Recheck storage and replica settings on each search node against retention goals.
- Sensor reconnection: Confirm every sensor reports to the right grid after the change.
- Per-node verification: Check each node's health and ingest rates before moving to the next.
On an airgapped network the ISO and update media must be obtained, verified and carried in before any work starts. The airgap docs state that the ISO carries packages and NIDS, YARA and Sigma rules, and that the soup update tool can update from newer ISO media in airgap mode.
- Media staging: Confirm which 3.x ISO and update media you need, how they are approved for transfer and where they are stored.
- Rule currency: Decide how detection content will be refreshed from new media, since rules do not update over the internet.
- Capture change: Plan the Suricata full packet capture transition on hosts with no outside access to vendor resources.
- Fresh install or upgrade: Confirm the distribution in use, because only Oracle Linux 9 can take the in-place path.
- Documented procedure: Write the offline steps and validation checks so the change can be repeated during audits.
A team moving from another network security monitoring or SIEM tool should treat this as a rebuild, not a direct upgrade. The work is to map your existing sources, detections and retention onto a new Security Onion grid and then prove coverage matches what you had.
- Source mapping: List every log source and sensor feed, then decide which Zeek, Suricata or Elastic Fleet input replaces it.
- Detection translation: Convert existing rules into Suricata NIDS, Sigma or YARA content and test each one against known traffic.
- Retention design: Set retention per data type to match your investigation and compliance needs before the grid goes live.
- Parallel run: Run both tools for a period so analysts can compare alerts and find gaps.
- Analyst training: Plan how the Security Onion Console workflow differs from your current tool before cutover.
What you need to provide
Before a migration from Security Onion 2.4 to 3 can be scoped, the client needs to supply a set of inputs that the migration team cannot infer from the product. Start with a current node inventory: every manager, search, sensor and receiver node, its role, its operating system, its hardware and its network placement, plus the deployment type you run today. Security Onion lists Import, Evaluation, Standalone and Distributed as its deployment types, and a Distributed grid with separate manager, sensor and search nodes changes the upgrade and test plan substantially. Confirm the latest tagged release and its supported upgrade paths in the release notes before scoping, because the path you need depends on that answer.
Provide administrative access to the 2.4 manager and the Security Onion Console, along with a matching test environment. The test grid should run Oracle Linux 9 on x86-64 hardware that meets the current minimums in the hardware documentation, since 2.4 installations on other distributions need a fresh install rather than an upgrade. Include a record of sensor placement, the interfaces each sensor monitors, and expected traffic volumes per link, so the team can confirm that Suricata full packet capture will fit the storage you already have.
Export the list of custom Suricata NIDS rules, Sigma rules and YARA rules, along with any tuning, suppressions and thresholds configured in the Detections interface. Document every log source, Elastic agent integration, dashboard, playbook and external connection that depends on the grid. Retention periods and compliance obligations also belong in this list, because they determine what data must survive the cutover and how long old evidence must remain searchable.
Name the people who approve changes and the analysts who accept the migrated detections. Change approval should sit with a named owner who can sign off the cutover plan, and analyst acceptance should sit with the team that will work the alerts after go-live. Finally, agree on a maintenance window with enough room for rollback. Confirm the window length and any change freeze dates with your own change board, since the team cannot set them for you.
Common questions about the migration
Can our own team perform the Security Onion 2.4 to 3 migration without a partner?
Yes, if your engineers have the time and skills to work through the upgrade path and test it before production. The work is mostly planning and verification: confirming that your grid runs Oracle Linux 9, moving full packet capture from Stenographer to Suricata, checking each node against the version 3 hardware minimums, and validating detections and dashboards after cutover. Your team must provide an inventory of nodes, sensors and custom content, access to a matching test grid, and decision-makers who can approve retention and cutover choices. Teams that have run Security Onion upgrades before usually find the sequence familiar. Note that version 2.4 reaches end of life on October 1, 2026, which sets the deadline for the decision.
What drives the price of a Security Onion migration quote?
The written scope drives the quote. The main inputs are the number of manager, search and sensor nodes, whether the grid is standalone or distributed, whether it is on-premises or a cloud marketplace deployment, whether it is airgapped, how many custom Suricata, Sigma and YARA detections need porting, and how much testing on a matching grid you want before cutover. Whether Pro features are in scope also changes the work. Ask for fees split by discovery, build, cutover and verification, and ask which items are one-time and which recur. DeployOpen does not publish a price list, so a quote follows from the agreed scope.
How long does a Security Onion 2.4 to 3 migration take?
The supplied information does not support a fixed duration, so treat any timeline as something to confirm in writing. Duration depends on node count and role layout, the volume of custom detection content to port, the number of environments that need testing before production, change windows, and how quickly your team makes decisions about packet capture history. Ask for a plan that lists each phase, its dependencies and what your team must provide at each step. Fixed-scope engagements are agreed in writing before work starts, so the timeline should follow the signed scope and the decisions you commit to.
Is an in-place upgrade from Security Onion 2.4 to 3 always possible?
No. An in-place upgrade from 2.4 to 3 applies only to installations on Oracle Linux 9, and only after full packet capture moves from Stenographer to Suricata. Installations on other distributions need a fresh install of version 3. Airgapped grids add a media step, because the soup tool can update from newer ISO media in airgap mode, so confirm with the vendor documentation how that process applies to this path. Even when in-place is possible, check that hardware meets the version 3 minimums, and consider a rebuild on new nodes so you can test before cutover.
What happens to existing Stenographer packet captures after the migration?
Version 3 replaces Stenographer with Suricata for full packet capture, so Stenographer is no longer the capture path after the move. Confirm with the version 3 documentation whether existing Stenographer captures can still be accessed, searched or exported after cutover, because that answer determines your options. Plan retention early: decide how much historical packet data you need, whether to archive older captures outside the grid, and who approves that archive. Capture storage and sensor sizing also change with the new capture path, so check them against the version 3 hardware documentation before you commit to a design.
Does Security Onion Pro change the migration work?
It can. Security Onion Pro is a paid edition sold on 1 to 5 year terms and adds OIDC single sign-on, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, the Security Onion API, external notifications, Manager of Managers, an MCP server, the Onion AI assistant and professional support. If you use any of these, the migration must decide how each one is configured on the new grid, which settings carry forward, and how access and identity are tested after cutover. Ask the partner to list every Pro feature in scope, confirm the version 3 configuration for each, and include that work in the quote and the test plan.
How DeployOpen runs Security Onion migrations
DeployOpen plans the move from Security Onion 2.4 to 3 as a fixed-scope piece of work, starting with an inventory of your grid, your operating system and your packet capture setup. Each step is agreed in writing, built in a test environment first, and handed over with documentation your team can run.
How we scope
- Inventory each node role, operating system and Stenographer dependency before any change is proposed.
- Confirm whether an in-place upgrade is possible, since 2.4 installs on Oracle Linux 9 can upgrade while other distributions need a fresh install.
- Agree the written scope, deliverables and timeline with you before any migration work begins.
How we build
- Build a matching test grid so the Suricata full packet capture change and the upgrade path are proven before production.
- Move packet capture from Stenographer to Suricata and check retention, storage sizing and sensor interfaces on each node.
- Validate detections, rule loading and Console access on the test grid, then run the agreed cutover steps in your environment.
How we hand over
- Document the as-built grid, node roles, configuration changes and the rollback steps used during cutover.
- Walk your operations team through the new packet capture workflow, alert review and update procedures.
- Deliver written evidence of tests run and open items, so your team knows exactly what has been verified.
How we support
- Offer ongoing support and upgrade work as a retainer after handover, scoped separately from the migration.
- Plan how future Security Onion releases will be tested on a matching grid before production updates.
- Confirm with Security Onion Solutions which support tier, including Pro professional support, fits your team.
