Migrate from IBM QRadar to OpenSearch

Plan on rebuilding most of the detection content and treating AQL as a translation exercise, not a copy job. OpenSearch is Apache 2.0 software forked from Elasticsearch 7.10.2 and Kibana 7.10.2, so the index, document and REST concepts your engineers already know carry over, and the search API is wire-compatible with Elasticsearch 7.10. AQL is a different query language. Each saved search, AQL filter and aggregation has to be rewritten as OpenSearch query DSL or as a PPL or SQL query that your team has tested against the same events. Where a conversion step is used, the team should run the original and converted searches side by side on a known event sample and sign off on matching results before any dashboard or alert depends on them.

QRadar's built-in content does not transfer as a package. Custom rules, building blocks, offenses, reports and dashboards will not arrive as importable objects, and the packaged correlation logic that ships with QRadar has no direct equivalent in OpenSearch. In the Security Analytics plugin, detectors are built from log types and rules, and Sigma rules are a practical source of detection logic, but each one needs field mapping to your actual event schema and a review of its false-positive rate in your environment. Inventory every QRadar rule and report first, mark each as rebuild, retire or accept as a gap, and assign an owner. Dashboards in OpenSearch Dashboards, which derives from Kibana 7.10.2, are built again from those queries.

Flow data needs its own decisions and should not be assumed to fit the event index. NetFlow, sFlow and similar records have a different shape and volume from log events, so the team must choose a separate index pattern or data stream, define the field mapping for source and destination addresses, ports, byte and packet counts and timestamps, and set retention separately. Confirm with the network team exactly which flow exporters feed QRadar today, their version and sampling settings, because those settings change what a flow query can prove. If full packet capture or deep network analysis is part of the current use, OpenSearch alone will not replace it, and that gap should be assigned to a separate tool before cutover.

The parallel run is where you prove OpenSearch can carry detection before QRadar stops receiving events. Dual-feed each log source so it reaches QRadar and the OpenSearch cluster at the same time, typically by adding a second output in the collector (for example, a Fluent Bit or Logstash pipeline) rather than re-pointing devices. Start with the sources that matter most for your detections, such as identity, endpoint and perimeter logs, and record the parser or field mapping differences for each one, because QRadar's normalized fields (such as sourceip and username) will not match OpenSearch field names by default. Keep the dual feed for long enough to cover your weekly and monthly reporting cycles, and confirm the time window with your own detection owners.

Compare outputs, not just volumes. For each source group, measure events received per source in both platforms, then compare the offenses QRadar raises against the alerts your OpenSearch Security Analytics detectors produce for the same activity window. Use the Sigma rules you have converted as the test set, and log every case where one platform fires and the other does not, with a reason and a disposition. Define cutover criteria per source group in writing before the run starts: for example, parser coverage for required fields, agreed detection hit parity for named use cases, and a documented on-call owner. A group moves only when its criteria are met and signed off, so sources cut over in stages rather than all at once. Keep QRadar in read-only mode for historical search after cutover. Do not decommission the appliance or delete its data until your retention obligations are settled with legal, compliance and records owners, since QRadar's stored events and saved searches may be the only copy for some periods. Plan the rollback path now: keep the QRadar dual feed active until the last group has run cleanly, and document how to restore the QRadar-only route for a group if detections or ingest fail. Confirm the OpenSearch version you deploy against the OpenSearch releases page at the time of work, and follow the rolling upgrade procedure in the project's migration documentation for any later version change.

The OpenSearch Security plugin is where access control for a migrated QRadar store is rebuilt, and it should be designed before any data is loaded. The plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token authentication backends. Confirm which backend matches your identity provider, whether that is Active Directory with LDAP, a SAML or OpenID Connect provider, or something else, and test a login path with a real analyst account before cutover. Also confirm how group membership reaches the cluster, because role mappings depend on it.

QRadar user roles, security profiles and any tenancy or log source restrictions do not transfer automatically. Map each QRadar role to OpenSearch roles, then to backend role mappings, by hand, and write down which analysts can see which indices, documents and fields. The Security plugin provides role-based access control, document-level and field-level security, field masking and user impersonation, which can express many of these restrictions. Test each role with negative cases, such as confirming that a tier-one analyst cannot read a restricted field. Treat this mapping as a reviewable artifact so auditors and your own security team can check it.

Audit logs and TLS are the controls most often left until late. Enable the Security plugin audit logging, decide which categories to record, and confirm where audit events are stored and who can read them, since audit data should not be readable by the analysts it tracks. Enable TLS for node-to-node and client traffic, and plan certificate issuance, rotation and trust distribution to forwarders and dashboards before go-live. Document these settings as evidence for your access control and logging requirements, but remember that DeployOpen prepares these controls and evidence without issuing an audit opinion.