Migrate from Google Security Operations to OpenSearch

Who moves from Google SecOps to OpenSearch, and how hard is it?

OpenSearch can replace the search and rule-based detection you use in Google Security Operations, but the move is mostly ingestion work, detection rebuild and retention design rather than a lift of the platform itself. Teams usually start this review because a renewal arrives, an ingestion-based price needs justifying, a data residency rule requires logs to stay in their own accounts, or they want to reduce dependence on one vendor's parsers and rule language. Those drivers are reasonable, and the first decision is whether the goal is to keep the same detections running on different infrastructure or to redesign how the SOC searches and alerts. The work is usually led by a SOC engineering lead, with a platform engineer who owns the OpenSearch cluster, Data Prepper or Fluent Bit pipelines, and TLS and authentication, plus the detection owners who know which rules matter and why. OpenSearch is licensed under Apache 2.0, and the supplied project information describes no paid edition, so the software itself carries no license fee. The recurring costs sit in the infrastructure, the storage needed for the retention you set, the engineering hours to keep pipelines and detections healthy, and the period when both platforms run in parallel. Confirm each of these with your own architects before you set a budget.

The effort is highest where SecOps has been doing the most work for you, such as parsing, normalization and rule content that your team has never inspected. Before you commit, list the log sources that feed your highest-value detections, check which ones your pipeline can reach, and count the rules that need rewriting for Security Analytics detectors and Sigma. Ask whoever runs the platform how many years of history you must keep, since that decision drives storage size and the export window. A short pilot with two or three critical sources, run alongside the current service, will show whether your team can match alert quality before you retire anything.

Which SecOps capabilities map to OpenSearch, and which need rework

This table maps each Google SecOps capability to its OpenSearch counterpart and marks whether the move is clean, needs rework or is a gap. Read the migration notes as the work each row adds to your plan, since rework rows carry the most engineering effort. Detection content and normalized parsers are the largest items, so test them in a cluster before committing.

SecOps capability	OpenSearch equivalent	Migration notes
Log search and query	OpenSearch Dashboards Discover and Query Workbench with PPL or SQL	Clean for raw event search. Rewrite saved searches from UDM field names to your own index field names.
Log ingestion and parsing	Fluent Bit or Data Prepper feeding OpenSearch indices	Needs rework. Bindplane collectors and SecOps parsers do not carry over, so rebuild field mapping in the pipeline.
Normalized UDM-style parsers	Ingest pipelines and index templates you define	Needs rework. Map each key log type to a field schema and test with sample events from your own sources.
Detection rules (YARA-L)	Security Analytics detectors and Sigma rules	Needs rework. Translate each YARA-L rule by hand or through Sigma, then confirm Security Analytics coverage against your own rule set in a test cluster.
Dashboards and reporting	OpenSearch Dashboards visualizations and saved objects	Needs rework. Rebuild dashboards from scratch, since saved objects are not exported from SecOps.
Role-based access control	OpenSearch Security roles, with document-level and field-level security and field masking	Clean for most roles. Map analyst groups to roles and test restricted field access before cutover.
Audit logs and TLS	OpenSearch Security audit logging and TLS for node and client traffic	Clean. Confirm audit categories and retention with your compliance owner, since they are set by your configuration.
SSO through SAML, OpenID Connect or LDAP	OpenSearch Security authentication backends for SAML, OpenID Connect, LDAP and Active Directory	Clean if your identity provider supports one of these backends. Confirm group claim mapping in a test environment.
SOAR playbooks	No direct equivalent in OpenSearch	Gap. Route playbooks to Shuffle, covered on the sibling SOAR page.
Historical data	Indices loaded from exported files	Needs rework. Export history while your Google SecOps Data Period still applies, then reload it into indices you size yourself.

What data, rules and integrations need to move, and through which export path

Four groups of material leave a SecOps tenant along different paths, and each one needs a different owner and a different check. Confirm every export path with Google for your tenant before the contract timeline is set, because the available methods depend on your package and configuration. Rebuilding the ingestion and search layer in OpenSearch is work you plan, not a file you copy.

Raw log sources and forwarders

Start with an inventory of every source that writes to SecOps, including the forwarders and Bindplane collectors that carry it. Raw logs are the material you can most often replay into OpenSearch, but the path to retrieve them from Google is a question for your tenant. Confirm with Google which raw log retrieval options apply to your package. On the OpenSearch side, plan to repoint each source to Fluent Bit or Data Prepper and record the parsing you need at that point. Note that BigQuery export is listed as an Enterprise Plus feature in the sibling export page.

Normalized and parsed events

Normalized events carry the field mappings Google applies through its parsers, and those mappings do not come across as-is. Treat them as a schema to reproduce, not a dataset to import. List the field names your detections and dashboards depend on, then map each one to the index fields you will create in OpenSearch. Ask Google for the export options that cover normalized events in your tenant, and test a sample of each log type before committing to a retention plan.

Detection rules and their logic

Detection content in SecOps is written in YARA-L and does not run in OpenSearch. Export the rule text and its alert history from your tenant, then rewrite each rule as a Security Analytics detector or a Sigma rule. Sort rules by the logic they encode, such as threshold counts, sequence matches or entity joins, because those patterns translate with different effort. Confirm with Google which rule export formats your tenant supports.

Integrations and dashboards

Ticketing, threat intelligence and identity connections are configured in SecOps and must be rebuilt against OpenSearch or its surrounding tools. Record each connector, its credentials and the alert fields it consumes. OpenSearch Dashboards saved objects are rebuilt, not imported, so plan to recreate every dashboard, visualization and saved search from the field list. Identity integrations should use the OpenSearch Security plugin backends your directory supports, such as LDAP, SAML or OpenID Connect.

How the migration runs, step by step, from inventory to decommission

The sequence moves SecOps log search and detection to OpenSearch in controlled stages, so every source and detection is proven on the new stack before the Google subscription ends and its data becomes unavailable to you.

Inventory sources, detections and retention needs
The SOC lead and the platform team list every log source feeding SecOps, the log types and parsers in use, each detection rule and its owner, the dashboards analysts rely on, and every integration that reads from or writes to the platform. They also record retention obligations per log type and the contract end date. Output: a signed inventory sheet that maps each source to a target pipeline, each rule to a Sigma or Security Analytics equivalent, and each dashboard to a Dashboards view. The step is done when the security owner and the compliance lead have both approved the list.
Choose the install method and run a pilot
The platform team selects one or two representative log sources and routes them through Fluent Bit or Data Prepper into a test OpenSearch cluster. OpenSearch installs through Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian packages, an Ansible playbook or Windows, so the install method is a decision made here based on your existing platform standards and who will operate the cluster. Confirm the chosen method against the current install documentation. Output: a documented pilot cluster, working ingestion for the chosen sources, and a first set of indexed events searchable from Dashboards. The step is done when the team can reproduce the build from its documented steps.
Build indices, access controls and detections
Engineers define index templates, retention and rollover policies per log type, and configure the Security plugin with the identity provider the organization uses, such as SAML, OpenID Connect or LDAP, together with role-based access and field-level security for sensitive fields. Detections are translated into Sigma rules or Security Analytics detectors and tested against replayed or pilot events. Output: a tested set of index policies, roles mapped to analyst groups, and a detection library with a known result for each rule. The step is done when each pilot detection fires on a known test event and stays quiet on normal traffic in the pilot window.
Run both platforms in parallel
Each in-scope source is sent to SecOps and to OpenSearch at the same time, so the SOC can compare alert volume, detection coverage and search results on identical data. Analysts work from SecOps as the system of record while the team logs every difference, such as missing fields, parser gaps or alerts that fire on one platform only. Output: a parity report listing each detection, its match rate on both platforms, and a fix or accepted gap for each difference. The step is done when the SOC lead signs off that all critical detections behave equivalently or that each gap has a documented decision.
Cut over sources and move analysts
Forwarders and collectors are repointed to the OpenSearch pipeline one source group at a time, SecOps ingestion is stopped for each group after its parity check passes, and analysts are moved to OpenSearch Dashboards with the dashboards and saved searches rebuilt in the inventory. Runbooks are updated to reflect new query syntax and alert paths. Output: a cutover log showing the date each source moved, a confirmed stop of SecOps ingestion per group, and analysts working from Dashboards for live investigations. The step is done when no source still writes to SecOps and the on-call rota has run at least one full cycle on the new stack.
Export history and decommission SecOps
Before the subscription ends, the team exports the history that retention and compliance require, keeping raw logs and rule definitions in the formats you choose and confirming that exports can be read by the new platform. Access to SecOps is revoked, API keys and service accounts are deleted, and the contract is closed with the vendor in writing. Output: a verified archive with checksums, a record of every revoked credential, and written confirmation of contract termination. Confirm with the vendor what data is deleted at contract end and when, and how long the extraction takes for your data volume, since neither is given in the facts for this page.

What drives cost and duration, and how to keep each one down

This table lists the main cost components and effort drivers for moving SecOps log search and detection to self-hosted OpenSearch. Read each row as a lever: the driver explains why it moves cost or schedule, and the reduction column shows what to scope or decide early. OpenSearch has no license fee in the supplied facts, so most of the spend sits in infrastructure, storage, staff time and any support contract.

Cost or effort driver	Why it matters	How to reduce it
Number and variety of log sources	Each source needs a collector, a field mapping and a test that events arrive intact. Mixed sources such as cloud audit logs, endpoints and network devices multiply this work.	Rank sources by detection value and migrate the high-value set first. Confirm which sources Google SecOps parses today and which you ship raw.
Custom parsers and detections to translate	SecOps parsers and YARA-L rules do not carry over directly. Each parser and rule needs rewriting, then testing against sample events.	Inventory rules and parsers before the project starts. Retire unused rules and map the rest to Sigma where Security Analytics supports the logic.
Retention length and storage tier	Retention sets the disk footprint, the hot and cold data split and the backup size. It is the main recurring infrastructure cost.	Decide retention per log type, not one period for everything. Use index lifecycle policies to move older data to cheaper storage and confirm the snapshot target with your storage team.
Historical export while the Data Period applies	Exporting history from SecOps depends on the contract terms and the Data Period still in force. Extraction time grows with volume.	Confirm the Data Period in writing with Google before scheduling extraction. Export the history you need for investigations and compliance first, and record what was excluded.
Cluster sizing and high availability	Node count, shard layout and replicas drive compute, memory and disk spend. A single node is cheaper but has no failover for the SOC.	Size from measured daily volume and query load in a pilot. Ask the implementer for a sizing worksheet and a written availability target before purchase.
Identity integration (SAML, OIDC, LDAP or Active Directory)	OpenSearch Security supports these backends, but mapping groups to roles and testing login paths takes engineering and review time.	Reuse the existing identity provider and define role mappings from an access model. Include the break-glass account and audit log review in the acceptance tests.
Dashboard count and detection content	Each SecOps dashboard or alert view must be rebuilt in OpenSearch Dashboards and checked with analysts. Large dashboard sets extend testing.	Limit the first release to dashboards analysts use weekly. Name owners for each dashboard and retire the rest.
Parallel-run length	Running SecOps and OpenSearch side by side doubles ingestion paths and staff attention until detections match. Length depends on how much tuning the rules need.	Set exit criteria in advance, such as matching alert counts on agreed test cases, and keep the parallel period tied to those criteria rather than to a calendar date.
Support contract and upgrade effort	OpenSearch is Apache 2.0 licensed with no paid edition in the supplied facts, but a vendor support contract is an optional recurring cost. Upgrades follow the release and maintenance cycle.	Decide between in-house support and a retainer based on the staff you have. Ask any provider for a written upgrade and patch plan with named deliverables and acceptance tests.

What usually goes wrong, and how to prevent it

Most failed SecOps-to-OpenSearch migrations do not fail on the day of cutover. They fail quietly, with detections that never fire, history that was never exported or storage that fills months later. Each card below names one failure mode and a check to complete before the old platform is switched off.

Detections that never fire

Rules written against normalized UDM-style fields may reference names that do not exist in your OpenSearch indices once Data Prepper or Fluent Bit has parsed the raw events. A Sigma rule can load without error and still match nothing. Before cutover, replay a known-bad sample event through the new pipeline and confirm each rule produces a finding. Record field mappings for every rule you port.

History lost after the contract ends

If the export starts after the subscription has ended, the raw logs, parsers and rule history may already be unavailable. Confirm with Google what remains accessible after termination and what your tier allows you to export. Start the export of raw events and rule definitions while the subscription is still active, and verify that exported files can be read and searched before the old tenant is closed.

Index sizing that fills storage early

Teams often size OpenSearch for average daily volume and forget peak bursts, replica copies and the retention period set by the old contract. Storage can fill well before the planned retention window ends. Model the daily volume from the old ingestion reports, multiply by the retention you need and the replica count, and add headroom. Configure index lifecycle policies and alerts on disk usage from the first day.

Alert fatigue during parallel run

Running both platforms in parallel doubles the alert paths. If every source feeds both systems at full volume, analysts receive duplicate notifications and noisy low-value detections from sources that were never tuned. Limit the parallel run to a defined set of log sources and detections, route OpenSearch alerts to a test queue first, and agree on which platform is authoritative for each alert type.

Dashboards that break on missing fields

Dashboards built in the old console often depend on normalized fields that OpenSearch does not produce unless the pipeline creates them. Panels then show empty charts or zero counts, which can look like a quiet environment. Inventory every dashboard and saved search, list the fields each one uses, and confirm that each field exists in the OpenSearch index mapping with the same data type.

Access rules not carried over

Access controls in the old platform do not transfer automatically. The OpenSearch Security plugin provides role-based access control, document-level and field-level security and field masking, but each role, index pattern and filter must be designed and tested explicitly. Map each analyst group to a role, restrict sensitive indices by document-level rules where needed, and test that a user cannot see data outside their scope before granting access.

How the migration differs by starting point and organization size

A small SOC with a few log sources and one team usually has the most room to simplify. The scope is narrow, so the first build can focus on a handful of high-value sources, a single cluster and a short list of detections that the team already relies on in Google Security Operations. The risk is mostly operational: one or two people will own ingestion, upgrades, dashboards and on-call alerts, so the migration should not add components the team cannot maintain.

Source inventory: List every forwarder and Bindplane collector, then cut anything nobody reviews. Fewer sources means fewer parsers to rebuild.
Single cluster first: Start with one OpenSearch cluster and a simple index pattern for each log type, and defer multi-tier designs.
Detection priorities: Port the detections that generate real alerts, not every rule carried over from the old platform.
Parallel run: Keep Google SecOps active until the new alerts match expected volumes for a full review cycle.
Export early: Pull the history you must keep while the subscription and Data Period still apply.

Before committing, confirm with your team who will carry the operational load and whether a retainer for upgrades and monitoring fits the budget.

Exporting history before the Data Period ends

History is the most time-sensitive part of this move because SecOps retention is bounded by its own data period and by the contract, not by your compliance needs. Before the subscription ends, confirm in writing with Google the exact data period that applies to your tenant, what happens to data after the subscription ends, and which export routes your package includes. BigQuery export is limited to specific tiers, so do not assume it is available to you. Agree the export window and format with Google early, because the extraction itself can take longer than the time left in the contract.

On the OpenSearch side, decide the retention you will carry forward before you create any index. Retention is a design decision you size yourself, so define the window (for example, the number of days or months your regulators, auditors and incident responders need), then map it to index lifecycle stages. Hot indices hold recent data for search and detection, while warm or archived indices hold older data at lower cost. The storage tier behind each stage is your choice, and it should follow your own storage contracts and hardware. Set index naming, rollover and lifecycle policies in a test cluster first, and check each rule against the Security plugin roles that can read that history.

No export speed or data volume is assumed on this page. Run a timed test extraction for one representative log source and one short time range, record the rate, the file sizes and the number of retries, then extrapolate only from that measured result. Use the test to choose between loading history directly into OpenSearch during the parallel run and archiving raw exports to object storage for later reingestion. Keep the parallel run long enough to load and verify the agreed history window before the SecOps data becomes unavailable.

Questions teams ask before they move from SecOps to OpenSearch

What does a migration from Google SecOps to OpenSearch cost?

The cost is made of components rather than a single figure: engineering time for ingestion pipelines, index and retention design, detection rework, dashboards and cutover, plus the infrastructure that runs the cluster. OpenSearch itself is released under the Apache License, Version 2.0, so there is no license fee to budget for in the software. Infrastructure and staff time recur, while pipeline build, rule translation and data export are largely one-time. The main drivers are daily log volume, how long you must keep searchable history, how many log sources you onboard, and how many detections you rebuild. Ask any implementation partner for a quote built from a written scope that lists each component separately.

How long does a SecOps to OpenSearch migration take?

The timeline depends on scope more than on the platform itself. The biggest variables are the number of log sources to repoint, how many SecOps detections and parsers must be rebuilt, how much history you need to export before the subscription ends, and how long the parallel run lasts. Teams with a small set of sources and a short detection list finish sooner than teams with many parsers and compliance dashboards. Confirm your contract end date with Google early, because that date sets the deadline for exporting history. Ask for a schedule with milestones in the written scope rather than a single end date.

Can our own team run the migration without outside help?

Some teams can, especially those with experienced platform engineers and a detection engineer who already knows Sigma. The work spans several skills: deploying and tuning an OpenSearch cluster, building ingestion with Data Prepper or Fluent Bit, designing indices and retention, configuring the Security plugin, and rebuilding detections and dashboards. Check honestly whether you have people for each of these while still running daily operations. If gaps exist, a fixed-scope engagement can cover specific components, such as pipeline build or hardening, and leave the rest with your staff. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure.

What does the migration require from our SOC and platform teams?

Three groups carry most of the work. SOC analysts review each rebuilt detection for logic, false-positive rates and coverage of the threats they actually respond to, because automatic conversion does not preserve that judgment. Platform staff operate the cluster, including capacity, upgrades, snapshots and access control. A named owner, usually with authority over both groups, approves cutover, decides when sources switch and signs off on the parallel run results. Agree on these roles and time commitments in writing before work starts, so analysts are not pulled off their queues without notice.

Does OpenSearch have a paid edition we need to buy?

The OpenSearch FAQ does not describe any paid edition. All software in the OpenSearch project is released under the Apache License, Version 2.0, and the OpenSearch Software Foundation is a Linux Foundation project that is not involved in technical oversight of the project. Your costs will therefore sit in infrastructure, storage, support arrangements and staff time rather than in a software license. If your procurement team needs written confirmation that no commercial add-on is required for the features you plan to use, ask the vendor or a support provider to confirm it against your feature list, because product offerings can change.

Will our SecOps detections and dashboards convert automatically?

No. Detections and dashboards do not convert automatically, so plan for manual rework. SecOps detection logic is written in YARA-L and is tied to Google's parsers and normalized event schema, while OpenSearch Security Analytics uses its own detector model. Sigma is a vendor-neutral rule format that many teams use as an intermediate step, but translation tools will not reproduce every correlation or threshold exactly, and each translated rule needs testing against sample events. Dashboards must be rebuilt in OpenSearch Dashboards against your new field names. Inventory every rule and dashboard first and mark each as rewrite, retire or keep.

How do we keep historical SecOps data after the subscription ends?

Export it while the contract still provides access, because the retention you need depends on what the subscription allows and what Google will delete at the end. Confirm with Google the data period that applies to your account, the export options available on your package, and the deletion date. Export raw logs where possible, since normalized events may not map cleanly to your new schema, and keep rules, parsers and their documentation alongside the data. Store the exports on storage you control, and test that you can read a sample back in OpenSearch before the window closes. The export procedure is covered in a separate guide.

What should the parallel run check before we cut over?

A parallel run should prove that the new stack sees the same events, fires the same critical detections and supports the same investigations. Check event counts and field coverage per log source against SecOps, confirm timestamps and time zones match, and compare alert volumes for each rebuilt detection over a period that includes normal and busy days. Test a set of known scenarios, such as failed logins or blocked egress, and confirm each one alerts and is searchable. Verify access control, audit logging and TLS settings on the Security plugin, and record every difference for the named owner to sign off. Confirm the exact checks with your SOC and compliance leads, since their evidence needs vary.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this migration, the work starts with a written scope covering your SecOps log sources, detection content and export plan, and then moves through a parallel run before any cutover.

How we scope

Inventory every log source, forwarder and Bindplane collector currently feeding Google SecOps, with its owner.
Agree in writing which detection rules, dashboards and retention periods move to OpenSearch and which are retired.
Confirm the Google SecOps data period and export window with your contract owner before engineering starts.

How we build

Deploy the OpenSearch cluster, Dashboards and Security plugin in your environment, with index and retention design agreed up front.
Build ingestion paths with Data Prepper or Fluent Bit, and test parsing against sample events from each key log type.
Convert priority detections to Security Analytics detectors and Sigma rules, testing each against replayed events before go-live.

How we hand over

Deliver configuration, pipeline definitions, index templates, detector inventory and runbooks as versioned documentation.
Run both platforms in parallel for an agreed period and document the differences in alert volume and coverage.
Provide an archive of exported history with a manifest so your team can locate records during audits or investigations.

How we support

Ongoing support, OpenSearch upgrades, backups and continuous testing are available as a retainer after handover.
Plan upgrades against the OpenSearch release cycle and maintenance windows, so patches reach your cluster on schedule.
DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors issue any reports or certifications.