Migrate from Google Security Operations to Wazuh

Migrate from Google SecOps to Wazuh without losing detection coverage

A SOC or platform team usually starts this move when a Google SecOps renewal, a change in ingestion pricing or a data residency requirement forces the question of where security telemetry must live. Wazuh replaces the agents, analysis engine and dashboards, but detection content and historical data do not move on their own. Google SecOps YARA-L rules, parsers, normalized event history and retention commitments all need deliberate translation or export. Plan the migration as two workstreams: the platform cutover (agents, collectors, indexer, server and dashboard) and the detection and evidence workstream (rules, parsers, history and compliance views). Most teams find the second workstream takes longer and carries more risk than the first.

Security engineering staff normally own this work, and many organizations bring in an implementation partner for the Wazuh deployment, decoder and rule work, and the evidence export. Start with an inventory: list every log source, forwarder and Bindplane collector, every YARA-L rule and its owner, and every saved dashboard or case workflow that analysts depend on. Mark each rule as one of three types: rebuilt as a Wazuh rule, translated to Sigma for later use, or retired with a documented reason. Confirm with your Google account team what raw and normalized data you can export, in what formats and within what window, because that answer sets how much history you can carry over. Confirm also the Wazuh license terms in the Wazuh LICENSE file with your legal team before you commit to a design.

The main risks are silent coverage gaps and a compressed cutover. Run Wazuh and Google SecOps in parallel for a defined period, and compare alert volumes and detections for the same known test events before you repoint any production forwarder. Keep a rollback path for each log source until its detections are proven. Schedule the export of history before the subscription end date, not after it, and verify a sample of exported records can be read by someone who was not involved in the export. The effort is driven mainly by the number of custom rules, the number of non-standard log types needing new decoders, and how many compliance evidence packs your auditors expect. Ask any implementation partner for a written, fixed-scope plan that lists these items before work starts.

Which Google SecOps capabilities map to Wazuh, and which need rework

This table maps the main Google SecOps capabilities to their closest Wazuh equivalents and marks each as clean, needs rework or gap. Use it to scope the migration work, then confirm parser and rule coverage against your own log sources, because Wazuh's agent and compliance dashboards do not replicate SecOps UEBA one for one.

Capability	Google SecOps	Wazuh equivalent and status
Log ingestion and forwarders	Forwarders and Bindplane collectors send logs to SecOps	Clean for hosts with a Wazuh agent. Needs rework for network devices and cloud sources, which typically use syslog collection or API probing
Parsers and normalization	Managed parsers normalize events into the UDM schema	Needs rework. Wazuh uses decoders and rules, so confirm decoder coverage for each key log type in your environment
YARA-L detection rules	Detection rules written in YARA-L	Needs rework. Translate rules to Wazuh rules or Sigma, then test each against replayed events before cutover
UEBA and entity context	Built-in user and entity behavior analytics	Gap. Wazuh provides agent, alert and compliance views but not equivalent behavior baselining; plan analyst-driven correlation instead
Dashboards and search	Search over normalized events and curated dashboards	Needs rework. The Wazuh dashboard and indexer cover search and alerts, but saved searches and views must be rebuilt
Retention	Retention set by your contract and package	Clean in principle. Wazuh retention is set by the storage you provision, so size indexes for the periods you must keep
Compliance reporting	Compliance and audit reporting for security events	Needs rework. Wazuh includes prebuilt dashboards for frameworks such as PCI DSS, GDPR, HIPAA and NIST 800-53; confirm they match your control mapping

What data and integrations move, and what you must rebuild

A SecOps exit is three different jobs: raw log sources that must be repointed, detection logic that must be rewritten, and history that must be exported before access ends. Each card below names one of these pieces and the check to run before the contract ends. Google's export options, including BigQuery export in Enterprise Plus, should be confirmed with Google in writing before you plan around them.

Detection rules as configuration

YARA-L detection rules, rule sets and their enabled or alerting state live in SecOps and do not transfer to Wazuh as-is. Inventory every rule, record which ones fire in production, and map each to a Wazuh rule, a Sigma rule or a retired item. Expect rules that depend on SecOps-specific entity context or UDM fields to need redesign rather than translation. Ask Google to confirm which rule definitions you can export in a readable form.

Parsers and normalization

SecOps parsers convert raw logs into normalized event fields that rules depend on. Wazuh uses its own decoders and rules, so the fields your detections read will change even when the raw data stays the same. Pick the log types that matter most, such as identity, endpoint and firewall logs, and document the field mapping for each. Confirm with Google which parser configurations you can export and which are managed only by Google.

Raw log sources and collectors

Forwarders, Bindplane collectors and syslog senders currently point at Google ingestion endpoints. Each source needs a new destination: a Wazuh agent where the endpoint supports one, or syslog into the Wazuh server for network devices and cloud sources that cannot run an agent. Keep a source inventory with the owner, log type and cutover date for each. Test event parity on every source before you switch the old pipeline off.

Alert and case history

Alerts, cases and analyst notes in SecOps are a separate export from raw logs. Decide which records must survive for audits and open investigations, and export them in a documented format before access ends. Store closed-case evidence in a system your retention policy covers, and record which alerts were triaged in SecOps so the audit trail stays readable after the move.

Reference lists and enrichment data

Watchlists, allowlists, asset lists and threat intelligence feeds used by SecOps rules must be rebuilt in Wazuh as CDB lists, decoder data or external enrichment. Export each list from SecOps, check for stale entries and assign an owner. Wazuh vulnerability detection draws on the Wazuh CTI platform or an offline repository, so confirm which feed your environment will use before cutover.

Exports and retained data

Confirm with Google, before the contract ends, which exports are available to your tier, including BigQuery export in Enterprise Plus, and what happens to data once the subscription ends. Raw log retention in your own storage is a separate decision from alert history. Write down the format, the volume and the time each extraction takes, then test one full export before you rely on it.

How to translate YARA-L rules into Wazuh rules or Sigma

Start by treating the translation as a rebuild of detections, not a line-by-line port. YARA-L rules correlate events over normalized UDM fields, so a rule that matches a sequence of events across several log types depends on how Google SecOps parsed those logs. Wazuh works differently: agent and syslog data pass through decoders that extract fields, and XML rules on the Wazuh server match those fields, with <if_sid> and <frequency>/<timeframe> settings handling simple correlation. Sigma sits between the two as a vendor-neutral format, so a detection written once as Sigma can be converted for a Wazuh-compatible backend or another SIEM later. Confirm the current Wazuh rule syntax and correlation options in the documentation for your release before you write the first rule.

Inventory the existing rules by log source before rebuilding anything. Export the rule set with its log types, the UDM fields each rule reads, its run frequency and who owns it. Group rules that cover the same behavior, retire duplicates and rules that no analyst has acted on in your review period, and mark which detections map to a control your auditors or regulators ask about. Then rebuild the highest-value detections first, usually credential abuse, privileged activity and data exfiltration on your most important systems, and confirm that each Wazuh decoder and rule captures the fields it needs from the log sources you have chosen to keep.

Validate every rebuilt detection against replayed logs before it alerts anyone. Keep a set of raw events from both known-bad and normal activity, replay them through the Wazuh server with wazuh-logtest and compare the results against the expected outcome from the YARA-L rule. Record each difference as a decision: a gap to fix, a rule to tune or a detection you accept as retired. Run the new rules in parallel with the old ones for a defined period so analysts can compare alert volume and quality before the Google SecOps rules are switched off.

The migration sequence from inventory to decommission

The sequence moves log sources, detection logic and retention from Google SecOps to Wazuh in controlled stages, so each stage proves coverage before the next one starts. Every step ends with a written output that the team signs off before continuing.

Inventory sources, rules and retention needs
Platform engineering and the SOC lead list every log source currently forwarded to Google SecOps, with its log type, owner, volume trend and the detections that depend on it. They also export the list of YARA-L rules, parsers and dashboards in use, and record which of them alert the SOC every week. Ask Google for your current data retention terms and for a list of the ingestion parsers in use, since these settle how much history you must keep. The output is one inventory sheet with a row per source and a row per rule, each marked for pilot, parallel run or retire. The team is ready to move on when the SOC and compliance owners have both signed it.
Pilot key log types with agents or syslog
Choose a small set of high-value log types, such as Windows security events, Linux authentication logs and one firewall, and onboard them to a non-production Wazuh server. Install Wazuh agents where the platform supports them, and use syslog collection with a decoder for network devices that cannot run an agent. Confirm that the Wazuh server decodes each event correctly and that the matching Wazuh rules fire on test events. The output is a pilot report listing each log type, its decoder, the rules it triggers and any fields that did not map. Move on only when the SOC has reviewed alerts from the pilot and agreed that they match what SecOps shows for the same events.
Translate detections to Wazuh rules or Sigma
Rewrite each YARA-L rule that the pilot covers as a Wazuh rule, or as a Sigma rule converted to a Wazuh format where a Sigma-based workflow is in place. Map the fields that the old rule used to the decoded fields in Wazuh, and note any rule that depends on a SecOps feature with no direct equivalent, such as built-in entity analytics. Replay the historical test events against both rule sets to compare outcomes. The output is a translation log with one row per rule, its status (equivalent, partial or not carried over) and the test result. Move on when every rule in the pilot scope has a status and each partial rule has a documented compensating control or an accepted risk.
Run both platforms on the same sources
Send the same pilot and in-scope sources to Google SecOps and Wazuh at the same time, through the existing forwarders or Bindplane collectors plus a second destination. The SOC works from one queue while a platform engineer compares alert volumes, false positive rates and missed detections between the two systems each week. Record every difference and its cause, whether it is a parser gap, a timing gap or a rule that needs tuning. The output is a parallel run log that shows agreement per rule and per source, with the reasons for each gap. The team moves on only when the SOC lead accepts the gaps as closed or documented, and the incident responders confirm they can investigate alerts in Wazuh.
Cut over source groups in stages
Move sources to Wazuh in groups, such as identity, endpoints, network and cloud, and stop forwarding each group to SecOps only after its parallel run has closed. Repoint each forwarder or Bindplane collector, verify that events arrive in the Wazuh indexer, and update the runbooks and alert routing that the SOC uses. Keep the SecOps path available for rollback until the group has run in Wazuh through a full review cycle. The output is a cutover record per group with the change date, the verification results and the rollback status. Each group is complete when its alerts route to the SOC queue from Wazuh and no new events for it reach SecOps.
Export history and decommission SecOps
Before the subscription ends, export the raw logs, normalized events, rules and parsers you need to keep, following the export steps for Google SecOps. Store the exports in your own object storage with access controls, retention and integrity checks that match your policy, and test that a sample can be searched and read. Confirm with Google the date after which your data may be deleted, and do not disable access until the export is verified. The output is an archive record listing each dataset, its location, its checksum or hash, the retention period and the approver. Decommissioning is complete when the archive has been tested, the compliance owner has accepted it, and the SecOps tenant is closed in writing.

What drives migration cost and duration

This table lists the main drivers of cost and effort when moving from Google SecOps to Wazuh, with ways to reduce each one. Read it before requesting a quote, because the drivers decide whether the work is a small rule port or a multi-month program. The main takeaway is that log source count, rule complexity and history volume usually matter more than the platform license, which Wazuh does not charge.

Driver	Why it moves cost or effort	How to keep it down
Log sources and parsers in use	Each log type needs a Wazuh decoder and rule set, or an agent or syslog path, and each custom Google SecOps parser must be re-created or replaced by a Wazuh decoder for the same format.	Inventory sources by volume and detection value, retire unused feeds, and start with the log types behind existing alerts.
Count and complexity of YARA-L rules	YARA-L rules that join events, use time windows or aggregate counts do not translate one to one into Wazuh rules, so each one may need redesign and testing.	Export the rule set, group rules by log source, and port the simple single-event rules first. Confirm which rules the team still uses.
Retention and history volume to export	Exporting or archiving large volumes of normalized events and raw logs takes storage and extraction time, and the Wazuh indexer must size storage for the retention you choose.	Decide which history must be kept for audits or investigations, and export only that range. Ask the vendor which export formats and retrieval paths are available for your contract.
Running both platforms in parallel	Keeping Google SecOps and Wazuh side by side doubles forwarding, alert review and subscription time until the cutover is validated.	Limit the parallel period to the sources and rules under test, and define exit criteria for each cutover wave in the written scope.
Team skills in Wazuh and Sigma	Staff who know YARA-L must learn Wazuh decoders, rules and the Sigma format if rules are converted through Sigma, which adds training and review time.	Assign a named owner for rule conversion, use Sigma as a shared rule format where it fits, and plan pairing or training before the rule port starts.
Compliance evidence needs	Auditors may ask for proof of log coverage, alert handling and retention during and after the move. Preparing this evidence takes time, and DeployOpen prepares evidence but does not issue audit reports.	Map required controls to log sources and rules early, keep change records for each cutover, and confirm the evidence format with your independent auditor before work starts.
Infrastructure for the Wazuh indexer and storage	Recurring hosting, storage and backup costs depend on event volume, retention and whether the Wazuh server runs as a cluster for scale.	Size from measured daily volume and the agreed retention period, and ask for the sizing assumptions in the quote.
Partner fees and internal engineering time	Partner fees are typically one-time for scoped migration work, while internal engineering time and ongoing SOC tuning recur. Both depend on the written scope.	Request a fixed-scope quote with named deliverables per log source and rule group, and ask which tasks remain with your team after handover.

What usually goes wrong and how to prevent it

Most failed SIEM migrations fail quietly rather than loudly. The risks below connect because they share one root cause: the old platform kept doing work nobody wrote down, and the new one was never checked against it. Each card names the failure and the check that catches it before the Google SecOps contract ends.

Silent detection gaps after cutover

A rule that fired in SecOps may never be rebuilt in Wazuh, and nothing alerts when it goes missing. Build an inventory of every active YARA-L rule, its owner and its last alert date, then map each one to a Wazuh rule, a Sigma rule or a documented decision to retire it. Replay known attack samples through both platforms and confirm that each mapped rule produces an alert before the old one is switched off.

Parsers that lose field meaning

Wazuh decoders extract fields differently from SecOps parsers, so a field such as a user name or source IP can arrive under a new key or as an empty value. Rules that filter on the old field names then match nothing, with no error. For each key log type, compare a sample of raw events against the normalized output in both platforms and record which fields your detections depend on. Test the decoders with wazuh-logtest before forwarding production traffic.

History lost after the subscription ends

Exports started after the subscription ends may be impossible, because the data is no longer accessible. Investigations, audit evidence and baseline statistics for detection tuning all depend on that history. Start the raw log and normalized event export while the contract is still active, confirm the archive can be read without SecOps, and store it in your own object storage with a retention period set by your policy, not the vendor's.

Bindplane collectors still pointing at Google

A Bindplane configuration or forwarder that still sends to the Google ingestion endpoint keeps shipping logs to a platform you are paying for, or to one that is being shut down. Logs can then reach both systems, or stop reaching Wazuh altogether. Inventory every collector, agent and forwarder with its destination, repoint each one in a change window, and check the destination on each host after the change.

Alert volume spikes in Wazuh

Wazuh rules and default decoders can generate far more alerts than the SecOps detections they replace, especially for file integrity, authentication and syslog firewall events. Analysts then tune out the queue, which hides real incidents. Before cutover, run both platforms in parallel, measure alerts per day per source, and tune noisy rules by severity, suppression or scope. Set a target alert volume for each source and review it weekly during the first month.

Underestimated indexer sizing

The Wazuh indexer stores alerts and must hold the retention you chose, plus the replicas and headroom your search needs. Teams that size from the ingestion figures in their SecOps invoice often run short of disk within weeks. Measure daily event volume per source over a representative period, multiply by your retention window, then add replica and growth margin. Ask your implementation partner to show the sizing worksheet and test a node failure before go-live.

How the migration differs by starting point

A small team with a handful of log sources and a short list of YARA-L rules usually has the smallest migration. The main work is to rebuild the few detections that matter, point the existing forwarders at Wazuh, and decide what history is worth keeping. A single-node Wazuh deployment, such as the all-in-one installation or the prebuilt OVA, is often enough to start, and the team can add agents as sources are onboarded.

Rule inventory: List every active YARA-L rule and mark which ones alert on a real workflow. Many small teams find that a few rules carry most of the value.
Source list: Map each forwarder or Bindplane collector to a Wazuh agent, a syslog input or an API probe for agentless devices.
Scope of history: Export only the events needed for open investigations and compliance evidence, not the full retention.
Parallel run: Keep Google SecOps running for a short overlap so the team can compare alerts from both systems before cutting over.
Staffing: One or two people can often own the rules and agents, so document ownership before the subscription ends.

Confirm with your team how many sources and rules are in scope before you choose the installation path, because both drive the size of the work.

Questions buyers ask before moving from Google SecOps to Wazuh

What does a migration from Google SecOps to Wazuh cost?

The migration cost is driven by the work, not by a license fee, because Wazuh is free and open source under GPLv2. Costs fall into four groups: infrastructure to run the Wazuh indexer, server and dashboard with the retention you need; engineering time to repoint forwarders and Bindplane collectors, translate detection rules and rebuild parsers for your key log types; history export before your subscription ends; and running both platforms in parallel. Infrastructure and staffing recur, while translation and cutover work is largely one-time. Ask Google for your contract terms on data deletion and export windows, and ask any implementation partner for a fixed-scope quote built from your rule count, log sources and retention target.

How long does a Google SecOps to Wazuh migration take?

Duration depends on the number of log sources, detection rules and parsers you must rebuild, the retention you need, and how many people can work on it. A small environment with a few log types and a short rule set moves much faster than a multi-region estate with custom YARA-L content and compliance reporting. Wazuh's own release cadence does not set your timeline, but you should plan around it: the 4.14 line received six patch releases in 2026, so pin a version for the cutover and schedule upgrades deliberately. Ask for a written timeline that separates inventory, pilot, parallel run and cutover.

What does our team have to provide for the migration?

Your team supplies the knowledge of what the SIEM must detect and where the data comes from. The minimum inputs are an inventory of log sources and forwarders, an export of YARA-L rules and their owners, the list of alerts that analysts act on, the compliance frameworks you report against, and access to the Google SecOps tenant and the systems that feed it. You also need named people who can approve rule changes and test alerts during the parallel run, and a place to host the Wazuh indexer, server and dashboard that meets your data residency rules. Confirm with Google which exports and API access your contract includes before you start.

Can our own team migrate from Google SecOps to Wazuh without a partner?

A capable team can do it in-house if it has Linux and infrastructure skills, detection engineering experience and time that does not compete with live SOC work. Most of the difficulty is in rule translation and log parsing, not in installing Wazuh. Wazuh offers several deployment routes, including an all-in-one installation, Docker, Kubernetes, Ansible and an offline guide, which lowers the installation risk. Weigh whether your engineers can rebuild decoders and rules for your key log types while keeping current detections running. An outside partner can take on defined scope, such as deployment, rule translation or compliance evidence, under a written agreement.

How do we keep Google SecOps history, and when must export start?

Start the export before the subscription ends, because the contract, not Wazuh, decides how long Google keeps your data. Export raw logs where possible, since normalized events and parser output may not be portable as-is. BigQuery export is listed as an Enterprise Plus capability, so confirm with Google whether your package includes it and what the deletion date will be after termination. Plan storage in your own environment for the history you must keep, and test that archived logs can be searched and read before you rely on them. Extraction time grows with data volume, so measure it on a sample first.

How do we run Google SecOps and Wazuh in parallel?

Run both platforms against the same log sources for a fixed period, and compare what each one alerts on for the same events. Dual-feed the sources where your forwarders allow it, or repoint a subset of sources to Wazuh first and keep the rest on Google. Track alert counts, false positives and missed detections for each translated rule, and sign off on each use case before you retire the matching YARA-L rule. Keep the SOC's escalation path clear during the overlap so analysts know which system is authoritative for each alert type.

Does Wazuh cover compliance reporting after we leave Google SecOps?

Wazuh includes prebuilt dashboard views for PCI DSS, GDPR, HIPAA and NIST 800-53, and it supports file integrity monitoring, vulnerability detection and log analysis that feed that evidence. These views help you gather and present evidence, but they do not make you compliant. Auditors and certification bodies decide whether your controls meet a framework, and DeployOpen prepares systems, controls and evidence for those assessments without issuing audit reports. Confirm with your assessor which evidence formats and retention periods they expect, and check which framework views match your scope.

How DeployOpen scopes and runs a Wazuh migration

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Google Security Operations to Wazuh, we start with a written scope that names the log sources, rules and history in play, then build and test the Wazuh deployment in your environment before any cutover.

How we scope

Inventory every log source, forwarder and Bindplane collector that currently feeds Google SecOps
List the YARA-L detection rules and map each one to a Wazuh rule, a Sigma rule or a retired use case
Agree in writing which log types need parsers, which history must be exported, and the cutover criteria

How we build

Deploy the Wazuh indexer, server, dashboard and agents in your cloud accounts, data centers or air-gapped network
Repoint forwarders and collectors to Wazuh agents or syslog and test ingestion for each agreed log type
Run translated rules in parallel with Google SecOps and document detection gaps, false positives and tuning changes

How we hand over

Deliver configuration, decoder and rule documentation, plus an export record for retained Google SecOps data
Walk your SOC and platform team through dashboards, alert triage and the runbooks for agent upgrades
Provide evidence that supports your compliance assessment, while independent auditors issue any formal opinion

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the handover
Plan Wazuh patch upgrades on your maintenance windows, using the release line you have validated
Confirm the scope, deliverables and timeline in writing before work starts, with a quote based on that scope