OpenSearch + Security Analytics → Elastic Security
OpenSearch ↔ Elastic Security: integration to migration path.
Elastic Security is your live detection and incident plane, so we never re-deploy your stack on a single day. OpenSearch with Security Analytics stands up alongside Elastic first, receives the same ECS event stream through a Logstash fan-out, and only then takes over detections rule by rule. No flag day, no mass endpoint re-deployment, and every phase rolls back in minutes.
The honest exception: Elastic Defend EDR, the signed rule update channel, EQL sequences and SIEM-tuned ML have no clean OpenSearch parity. We give each a written disposition before Phase 1 — ported, redesigned, descoped, or kept on Elastic.
The idea
Fan out the same stream. Port detections last.
The topology that makes this zero-blackout is a Logstash fan-out: because a Filebeat or Fleet-managed agent honours only one output, dual-write happens at the Logstash tier, which tees every event to both clusters with disk-buffered, dead-lettered pipelines so one cluster failing never back-pressures the other. Both sides index ECS natively, so no field rename is needed and both panes show identical data from day one. Elastic keeps owning the Detection Engine, Cases, Timeline and Defend until its OpenSearch replacement is proven per rule — then notifications, history and finally the endpoint move across, each layer reversible.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We document every data source by ECS coverage and EPS, every enabled detection rule by type and last-fired, every ML job, every Defend host, and your Cases volume and dashboards. Read-only against the Elastic APIs, cross-referencing rule fires with Cases to find dead rules.
Stand up OpenSearch in shadow
An OpenSearch HA cluster goes live with Security Analytics and Alerting installed, configured against the same SAML or OIDC IdP as Elastic. Only a synthetic canary stream flows; no production data yet. Elastic is untouched.
Dual-ship production data
The Logstash fan-out tier tees every Beats and Elastic Agent producer to both clusters, so both hold identical ECS-shaped documents from time T. Per-output dead-letter queues keep the legs independent — Elastic going down cannot back-pressure OpenSearch.
Port detections in shadow mode
Every portable Elastic rule gets a Security Analytics detector or Alerting monitor writing to a quarantine index with notifications disabled. Sigma-portable rules import natively; EQL sequence rules become chained monitors; SIEM-tuned ML jobs are reimplemented, descoped, or kept on Elastic.
Cut analyst workflow to OpenSearch
OpenSearch Alerting destinations point at the production channels and Elastic notifications are suppressed to an SRE-only dead-letter. Analysts move to OpenSearch Dashboards, and TheHive (or equivalent) stands up as the Cases replacement since OpenSearch has none.
Migrate history; freeze Elastic ingest
Data older than the dual-shipping window is reindexed from Elastic into OpenSearch, throttled to under 30% of Elastic's search quota. The Logstash output to Elastic is frozen, and Elastic stays read-only for a 30-day evidence window.
Retire Elastic Security
Elastic Defend is uninstalled or replaced wave by wave with a real EDR — OpenSearch is not one — validating coverage on the new stack before pulling Defend. The Elastic cluster snapshots to Object-Locked S3 for the retention floor, then decommissions.
Feature parity
Where OpenSearch matches Elastic, and where it doesn't.
| Capability | OpenSearch + Security Analytics | Elastic Security | Parity |
|---|---|---|---|
| Detection authoring | Security Analytics detectors (Sigma-native plus custom DSL) | Elastic Detection Engine (EQL, KQL, ES|QL, Threshold, indicator-match) | Partial |
| Sequence / join detections | Alerting chained monitors (multi-stage plus chain condition) | Detection Engine EQL sequence / join | SaaS only |
| Alerting | Alerting plugin (per-index, bucket-level, document-level, cluster metrics) | Detection Engine rules plus Watcher (deprecating) | At parity |
| Anomaly detection | Anomaly Detection plugin (Random Cut Forest, multi-feature) | Elastic ML jobs (Platinum) plus prebuilt SIEM-tuned jobs | Partial |
| Behavioural EDR | None (log-only posture) | Elastic Defend endpoint (process-tree, ransomware scoring) | SaaS only |
| Entity / risk engine | None (approximate via bucket-level monitors into a side index) | Entity Analytics risk engine | SaaS only |
| Index lifecycle | ISM (Index State Management) JSON policies | ILM (Index Lifecycle Management) | At parity |
| Agent / data collection | Beats / Filebeat plus Logstash fan-out | Elastic Agent under Fleet (managed policies) plus Beats | Partial |
| Authn / authz and RBAC | OpenSearch Security plugin (LDAP/OIDC/SAML, DLS/FLS, audit) plus tenants | Built-in platform security plus Spaces (feature-level RBAC) | Partial |
| Case management | None first-party (pair TheHive plus Cortex) | Elastic Security Cases (Timeline, attachments, Jira/ServiceNow) | SaaS only |
| Curated rule update channel | None (DIY detection-as-code: pinned SigmaHQ plus CI) | Versioned / signed prebuilt-rules Fleet package | SaaS only |
| Retention immutability | Object-locked S3 snapshots (PCI 10.5.1 WORM) | Object-locked S3 snapshots (PCI 10.5.1 WORM) | At parity |
| Engine licence | Apache 2.0 | Elastic License v2 (source-available) | OSS only |
| Cost model | Self-hosted compute and ops | Elastic Cloud per-resource or self-hosted under Elastic License v2 | Partial |
What we're honest about
The caveats most vendors leave out.
Elastic Defend has no OpenSearch parity
OpenSearch is log-only — it has no behavioural EDR endpoint, no process-tree analysis or ransomware scoring. Retiring Defend means picking a real replacement first: CrowdStrike or SentinelOne for behavioural parity, or Wazuh plus osquery for log-level visibility. Wazuh on its own is not an EDR. The endpoint workstream is often longer than the SIEM migration itself.
No curated, signed rule update channel
Elastic ships prebuilt rules through a versioned, signed Fleet package; OpenSearch SA has no equivalent vendor feed. You take ownership: pin a SigmaHQ commit, run weekly CI pull-and-test, deploy through a gate. It is the single highest ongoing cost of the migration — budget 0.25 to 0.5 FTE and a named owner, or it does not work.
EQL sequences and SIEM-tuned ML do not port
EQL sequence and join semantics have no clean Sigma analogue and become hand-built chained monitors. Elastic's prebuilt SIEM ML jobs map poorly to OpenSearch's Random Cut Forest — plan to lose 30 to 40% of ML content or rebuild it as custom monitors. Each non-portable rule gets a written disposition; nothing goes silently missing.
No first-party Cases, risk engine, or Timeline
Entity Analytics risk scoring and Elastic Security Cases have no OpenSearch equivalent, and there is no Timeline — investigation runs through Discover, saved searches and TheHive observables. We approximate risk via bucket-level monitors into a side index and stand up case management as a parallel workstream, honestly coarser than Elastic's.
Why this beats a flag day
Reversible per rule, soaked before you cancel.
Every workflow and detection cut rolls back in under 15 minutes — a Logstash reload or a one-line runbook change re-enables Elastic notifications, so a bad migration is a config flip, not an incident. And we never cancel the Elastic contract on a hunch: each ported rule runs at least 30 consecutive days at a fire-rate within tolerance of the Elastic baseline before notifications cut over, and the Elastic cluster holds a read-only evidence window before any snapshot is final. You are never betting the SOC on one big cutover.
See whether your Elastic content migrates cleanly.
A call with a senior detection engineer. We inventory your rules by type, ML jobs and Defend host count, separate the Sigma-portable detections from the EQL, ML and Defend tail that needs a real plan, and tell you honestly what the path looks like for your environment.
Map my migration →