What you can export from Google Security Operations before the contract ends
Some Google Security Operations data can be exported through documented paths, some may not be exportable at your package level, and every export must finish while the subscription is still active. A renewal, a pricing change or a termination notice starts a clock, and Google may delete SecOps data after the subscription ends. The categories to plan for are raw logs, normalized events, detections, parsers, and cases from the SOAR side. Confirm each export path, format and limit in Google's current documentation and in your contract, because the available options depend on your package and region.
Raw logs and normalized events are different assets. Raw logs are the source records as they arrived, and they matter for evidence and for re-ingestion elsewhere. Normalized events are the records after parsing into Google's unified data model, and they are what your detections and searches used. Detection rules are written as text, so copy them out in full, along with rule versions and any alert history you need for audits. Parsers are configuration that turned vendor formats into normalized fields, so export them as well if you plan to rebuild that mapping. BigQuery export is an Enterprise Plus feature, so if your package does not include it, confirm which other export methods Google offers for bulk data.
Start with an inventory: list each log source, the retention you need for it, and the category it falls into. Ask Google in writing which export methods, output formats, time-range limits and volume limits apply to your tenant, who pays for any export tooling or storage transfer, and what date data is deleted after the contract ends. Run a small test export early to measure throughput, because the time needed for a full extraction depends on your volume and the export method, and you should not guess it. Finish the bulk export with margin before the final day of the subscription, and verify the files by checking record counts and sampling a few entries.
Which data types export, through which path, in which format
This table maps each Google SecOps data type to the export path, output format and limit you need to confirm before the subscription ends. Google's current documentation and your written contract are the sources for each cell, so every open item is a question to put to Google in writing. Treat each unverified cell as a blocking item in your exit plan.
| Data type | Export path | Output format | Limits and who confirms |
|---|---|---|---|
| Raw log data | Item to confirm with Google: any bulk export or retrieval method for original log files | Item to confirm with Google: original format as received | Retention window and export limits; confirm with Google and your contract |
| Normalized events | BigQuery export is listed for Enterprise Plus; confirm your entitlement in the contract | Item to confirm with Google: UDM field schema and file format | Whether events older than the retention period remain available; confirm with Google |
| Detection alerts | Item to confirm with Google: alert export through API or console download | Item to confirm with Google: JSON or CSV output | Maximum alerts per export and time range; confirm with Google |
| Rule content | Item to confirm with Google: export of detection rule text from the rules interface | Item to confirm with Google: plain text rule source | Confirm whether rule versions and author metadata are included in the export |
| Parsers | Item to confirm with Google: parser retrieval, if available to customers | Item to confirm with Google: parser source format | Confirm whether parsers are customer-exportable or Google-managed |
| Reference lists | Item to confirm with Google: list download from the reference list interface or API | Item to confirm with Google: CSV or text format | Size limit per list; confirm with Google |
| Case data | Item to confirm with Google: case export from the SOAR case queue or API | Item to confirm with Google: export format and attachment handling | Confirm whether attachments and analyst comments are included; confirm with Google |
How to keep detection rules, parsers and case history
Detection logic, parsing, reference data and investigation records are what make a SecOps tenant useful after the logs themselves are copied out. Each of the four items below needs its own export path, and Google-managed content may not come out in the same form, so check the documentation before the subscription ends.
Custom detection rules
Export every custom YARA-L rule you own, including its version history and its enabled or alerting state. Keep the rule text as plain files in version control so the logic survives the move. In Wazuh, each rule has to be rewritten as a Wazuh rule or converted to Sigma first, so record which fields and time windows each rule depends on. Confirm in the SecOps documentation whether rule export is available in your package and whether rule metadata comes with it.
Parsers and log normalization
Parsers decide how a raw event becomes a normalized event, so they are the part of the stack you cannot recreate from raw logs alone. Capture the parser configuration for each log type you depend on, along with sample raw events for testing. Plan to rebuild these as Wazuh decoders or as ingestion pipeline transforms in the self-hosted stack. Google-managed parsers may not be exportable in the same form, so confirm with Google what is available.
Reference lists and curated content
Watchlists, allowlists, asset lists and any curated detection packs your team enabled are often where analysts keep institutional knowledge. Export custom reference lists as CSV or JSON and record which rules reference each list. Vendor-curated content is typically licensed to the tenant, so do not assume it can be exported. Ask Google which items are customer data and which are Google content before you plan replacements for them.
Cases, alerts and analyst notes
Open cases, closed investigations and analyst comments show how past incidents were handled and are often needed for audit or legal review. Export case records with their timestamps, assignees, linked alerts and notes into a format your records system can read, and keep attachments with them. Decide which closed cases must move and which can stay in the archive. Confirm how far back case history can be retrieved, since that limit sets how early you need to start.
Raw logs versus normalized events: which copy you need
The raw source logs matter more than the normalized events for a future self-hosted stack, because normalized fields follow Google's schema and the parsing logic that produced them. Before the subscription ends, confirm which raw copies you can keep: the original files your forwarders and Bindplane collectors sent, any archive your own storage already holds, and the source systems that still retain the logs. Normalized events can be read in Google SecOps, but when you move them to another platform, their field names and the way values were derived belong to Google's model, not to yours.
The two copies differ in size, fidelity and reuse. Normalized events are usually larger per record once enriched with parsed fields, and they keep only what the parser extracted, so anything the parser discarded is gone. Raw logs keep the original payload, including fields no parser reads today, which lets you write new decoders for Wazuh or new index mappings in OpenSearch later. The cost of that fidelity is storage, which you will size against the retention you need. The practical question is which log types you would have to rebuild. For each source, list whether its parser exists in your own pipeline; a log type with no raw copy and no parser will leave a gap in your history that no export can fill. Ask your Google SecOps administrator and your log source owners to confirm, in writing, where each raw copy lives, who owns it, and whether it is complete for the Data Period you need. Treat any log type without a confirmed raw copy as a retention risk and decide, before the contract ends, whether to accept the gap or extend the source's own retention.
What cannot be exported and how to work around it
Some Google Security Operations data may be unavailable once the subscription ends, whether because it has aged out of retention, is managed by Google, exists only in the UI, or is derived at query time. Each limit below comes with a workaround you can plan before the contract date, and each should be confirmed with Google in writing.
Data past the retention window
Events older than the retention period in your contract may no longer be queryable, so they cannot be exported at all. Ask Google in writing which retention period applies to each log type and whether any history remains after termination. Where history is missing, the workaround is to recover it from the source: pull archived copies from the original forwarders, object storage or log archives that your team kept before the data reached SecOps. Check those copies now, since they are often the only record of older events.
Google-managed content
Parsers, curated detection rules and other content maintained by Google may not be exportable in their source form. Your own custom rules and any parsers you wrote are a separate question, so confirm which items Google will release and in what format. The workaround is to document the detection logic of each rule in plain language, then rebuild it as Sigma or Wazuh rules, and to rewrite parsing for the key log types in the target platform. Expect this rebuilding work to be part of the migration effort.
Dashboards and UI-only views
Dashboards, saved views, case layouts and some investigation pivots may exist only inside the SecOps interface. Ask Google whether any of these have an export format, and whether a dashboard definition can be retrieved through the API. If not, the workaround is to take inventory before the contract ends, capture each view with its queries and time ranges, and rebuild the important ones in OpenSearch Dashboards or the Wazuh dashboard. Screenshots help with reference but do not restore function.
Derived indexes and enrichment
Search indexes, entity graphs, risk scores and enrichment results are computed by the platform and may not be exported as data. Raw logs and the normalized events you can retrieve remain the reliable record. The workaround is to treat derived data as reproducible: re-run enrichment from raw logs and threat intelligence in the target stack, and record which fields the old platform computed so analysts know what changed. Confirm with Google whether any derived data is included in an export.
The export sequence and how to verify each stage
This sequence moves SecOps history into storage you control in an order that keeps the subscription's data available until each stage is verified. Each step closes with a check and a named owner, and the sequence ends with a signed manifest that proves what left the platform.
Inventory data sources and retention
The security lead and the SecOps administrator list every log source, parser and data type ingested into the instance, along with the retention period each one needs for investigations and compliance. Record which sources feed detections, which are kept only for search, and which legal or contractual holds apply. The output is a signed inventory that becomes the scope baseline for every later stage. Confirm with Google how the Data Period and retention settings in your contract determine how long history remains searchable and when deletion begins, since that date sets the deadline for the rest of the work.
Confirm export entitlements in writing
The account owner and procurement lead ask Google which export paths the current package includes, such as raw log export, search exports, or BigQuery export, which is an Enterprise Plus feature. Ask for the export limits, supported formats, and any charges for egress or query processing, and get the answers in writing. If your package does not include the paths you need, this is the point to decide whether to upgrade for the export window or use a different method. The check is a written confirmation that names each export path and its limits.
Run a small test export
The SecOps engineer exports one source, one short time range and one log type to the target storage. The engineer then reads the file, confirms that fields, timestamps and timezone are intact, and compares a sample of events against the same query in the platform. The test shows whether raw logs and normalized (UDM) fields are both captured, which matters because normalized events may not preserve the original message. The check passes when a reviewer can match the sampled records and fields one for one with the source.
Export bulk data in time windows
The SecOps engineer runs the full export in fixed time windows per source, writing each window to its own path with a naming scheme that records the source, start time and end time. Each completed window gets a record count and a checksum at write time, and failed windows are re-run rather than merged into the batch. Keep the same windowing for each source so that gaps and overlaps are easy to spot. The step closes when every window in the inventory has a file, a count and a checksum in the log of the export job.
Export content and cases
The detection engineer exports detection rules, parsers, reference lists, dashboards and any case or alert records the SOC needs for audit or handover, in the formats the platform supports. Store them in version control next to the rule and parser inventory so their history stays readable after the subscription ends. Compare the exported rule count and parser list with the platform's content list. The check is a reviewer confirming that each rule and parser in the inventory has an exported copy with its last-modified date.
Verify counts, ranges and checksums
A second engineer, not the one who ran the export, re-reads each file and compares record counts, earliest and latest timestamps, and checksums against the values recorded during export. Any window with a mismatch is re-exported and re-verified. Then the reviewer runs sample searches for known events in the source and confirms the same events appear in the exported data. The check passes when every window matches on count, time range and checksum, and every sample search returns the expected results.
Sign off a manifest of the export
The data owner and the security lead sign a manifest that lists every source, time window, file path, record count, checksum, content item and case record, along with the verification results and any known gaps. Store the manifest with the exported data in a location that has its own retention and access controls. Confirm with your legal and compliance team what evidence they need to accept the export, and whether an independent auditor will review it. The step is closed when the signed manifest is stored with the data it describes.
Export paths by entitlement and team setup
If your contract includes the BigQuery export available in Enterprise Plus, the extraction is a copy of your event data into a BigQuery project that you can read from. You then pull that data into self-hosted storage on your own schedule. Confirm with Google which tables and fields the export covers before you rely on it.
- Confirm the entitlement in writing. Ask Google which Enterprise Plus features are in your contract and whether BigQuery export is included.
- Start the historical copy early. Begin exporting while the subscription is active so the full retention window is captured before access ends.
- Match data types to targets. Normalized events suit OpenSearch for search and hunting, and alerts and detections map to the Wazuh indexer.
- Validate before you delete. Compare row counts and time ranges against the source, and keep the BigQuery copy until verification completes.
- Export rules and parsers separately. BigQuery holds event data, so ask Google how detection rules and parser configurations can be retrieved.
Check the covered date range, the owner of the BigQuery project after termination, and whether any access or copy rights end with the contract.
If your contract does not include BigQuery export, your options depend on the search export and API methods that Google documents for your package. Confirm those methods first, then plan extraction around any limits they impose. Other log platforms document row caps on browser exports, so expect Google to have similar constraints and ask for them in writing.
- Confirm the documented methods. Ask Google which search export, API or data retrieval paths your package supports, and where the documentation for them lives.
- Ask for limits. Get the maximum rows or time window per export. Sumo Logic, for example, documents a 100,000-row cap on browser CSV exports and advises splitting large pulls into shorter time ranges.
- Prefer raw events. Where raw log lines are available, export them, since normalized fields may not re-parse identically in OpenSearch.
- Script with checkpoints. Write pull jobs that track progress by time window so an interrupted run resumes without duplicate or missing events.
- Document detections manually. Record rules, dashboards and alert configurations from the console, because event exports may not include them.
Ask Google to confirm in writing the retention window reachable through each method and the rate at which the API returns data.
Many teams send logs through a mix of direct forwarders, third-party collectors and cloud integrations. Each path can carry different log types and may fail independently, so the export plan starts with an inventory of every source and the route it takes into the platform. Confirm with Google which ingestion paths and time ranges each export covers.
- Inventory every source. List forwarders, collectors and direct integrations, along with the log types each one sends.
- Dual-send during cutover. Send logs to the new target while Google still ingests them, so you can compare event counts per source.
- Map targets to sources. Endpoint telemetry suits Wazuh agents, network and application logs suit OpenSearch indices, and syslog devices can use Wazuh agentless syslog collection.
- Export one stream at a time. Extract by log type so a parser problem in one source does not block the others.
- Record cutover points. Note the last ingested timestamp for each source so every export window has a clear boundary.
Confirm with Google how collector-specific data is labeled in exports, since that labeling determines how you split and reconcile the streams.
How long the extraction takes and what drives it
The extraction duration is not a figure you can take from a brochure or estimate from a contract. It depends on how much data you hold, the time range you pull, the export throughput that your Google Security Operations tenant and your export path allow, how many export jobs you run in parallel, and how much verification your team does after each job. Each of these moves the total, and the verification step is the one teams most often underestimate because it is where hash checks, row counts and parser spot checks take real hours. Ask Google for the export limits that apply to your contract and tenant in writing, because they decide how many parallel jobs are even possible.
Do not plan the schedule from a guess. Run a pilot export over a known window, such as one day of a high-volume log source, and time every stage: query, retrieval, transfer to your storage, checksum and row-count verification. Divide the data volume by the measured elapsed time to get a working rate, then extrapolate across the full retention period you need to keep. Repeat the pilot for at least one large and one small log type, because raw security telemetry and normalized events differ widely in size. Add a margin for retries, failed jobs and re-exports, and treat the margin as part of the plan rather than an afterthought.
Work backward from the data deletion date in your subscription terms. Confirm that date with your account team, and confirm whether any grace period applies after the contract ends, because the schedule must finish before the data is gone and not merely before the contract expires. Set internal milestones for each log source, assign an owner to each one, and decide early which exports you will fall back to if throughput is lower than the pilot suggested. Keep a running record of what has been exported, verified and stored so the final handover to your Wazuh or OpenSearch environment is based on evidence.
What to plan before the Google SecOps contract ends
Google SecOps data exits are governed by the contract and by Google's deletion terms, not by the product's interface. The cards below list the decisions to settle with Google in writing and the internal owner for each, so the export window is not spent discovering what was never confirmed.
Confirm the deletion date
Ask Google, in writing, when SecOps data is deleted after the subscription ends, and whether any retention commitment in the order form or data processing terms extends that date. Confirm which data types are covered: raw logs, normalized events, alerts, cases and audit records may follow different rules. The legal or procurement owner should hold this answer, because every other deadline in the plan depends on it.
Check export entitlements
Read the contract for the export options it includes. BigQuery export is an Enterprise Plus feature, so a lower tier may only allow search-based or API-based retrieval. Ask whether the export entitlement is tied to the subscription term, and whether it continues during a wind-down period. The account owner in procurement and the platform team should agree on which method the archive will use.
Set notice and export deadlines
Work backward from the deletion date and the renewal notice period. Record the last day to give notice, the last day to run full extractions, and the date when the archive must be verified. Leave time for a second extraction pass if the first one misses a log source. The CISO or SOC manager should own these dates, and the contract owner should confirm them with Google.
Plan a parallel run
Run the replacement platform, such as Wazuh with an OpenSearch indexer, alongside SecOps for a fixed period so detections and parsers can be compared on the same events. Keep forwarders feeding both destinations until the new stack has matched the alert volume you expect. The SOC engineering lead should own the comparison, and it should be recorded in the cutover plan.
Define archive sign-off
Decide who accepts the export as complete. Acceptance should cover record counts per log source, a sample check of raw events against their normalized fields, a hash or checksum record for each file, and the storage location and access policy. The compliance lead and the data owner should sign off together, because a verified archive is the evidence an auditor will ask to see.
Schedule access and forwarder shutdown
Set the order in which forwarders, Bindplane collectors and user access are turned off. Stop sending new logs only after the parallel run is accepted, and keep read access until the archive sign-off is complete. Ask Google how it handles access and data after the subscription ends. The platform engineering lead should own the shutdown sequence, and the security owner should approve the final access removal.
Common questions before exporting Google SecOps data
Can our team export Google SecOps data on its own?
Often yes, but it depends on what your package includes and how much history you hold. Confirm with Google which export paths your subscription allows, including API or search-based retrieval, and whether bulk extraction is limited. Get the answer in writing before the contract ends. A team with strong query skills and storage capacity can run extraction in-house. Teams with many log sources, long histories or evidence requirements for auditors often bring in outside help. DeployOpen plans and runs this kind of export under a written, fixed scope when a client wants that support.
What drives the effort of exporting SecOps data?
The main drivers are the number of log types you ingest, how far back you need history, how many parsers and rules must be documented, and how many destinations the data must reach. Variety usually matters more than raw volume, because each log source may need its own query, format handling and validation. Retention targets, auditor evidence requirements and the choice between raw and normalized fields also change the scope. Ask any provider for a quote that lists each log source, the time range, the target format and the verification method, so the estimate follows from written scope.
How long does the extraction take?
The duration depends on data volume, the number of log sources, the time range and any throttling or quotas on the export path. No reliable figure applies to every tenant, so ask Google for the export throughput and any limits on your package. Then test one log source over a short time range and measure how long it takes. Extrapolate from that test, and add time for validation, reruns and gaps in the data. Plan the schedule backward from the contract end date, because a failed batch close to the end leaves little room to recover. Confirm the end date and any grace period in writing.
What does the export need from our internal team?
Someone must own the scope decision, provide access to the SecOps tenant and approve which log types and fields matter for investigations and audits. SOC leads or security engineers usually confirm the detection use cases that depend on the data. Platform or data engineers handle storage, file formats and checksums. Compliance staff should define evidence retention periods and who may access exported data. Legal or procurement should confirm the contract's data return and deletion terms. Name these owners early, because most delays come from unanswered questions about what must be kept, not from the copying itself.
Do we need BigQuery export, and is it an entitlement question?
Whether you need BigQuery export depends first on your package, so it is an entitlement question before it is a technical one. Google describes BigQuery export as an Enterprise Plus feature, so check your order form to see whether your current package includes it. If it does not, other extraction paths still exist, but you should plan and price them as separate work. If it does, confirm how schema, partitioning and storage are handled in your own Google Cloud project, because queries and storage there are billed to your account. Complete the entitlement check first, then choose the method.
What happens to detections and parsers when the subscription ends?
Detection rules, parsers and dashboards are configuration, and your right to keep or export them depends on your agreement, so confirm it in writing. Export rule logic, parser definitions and alert or case history where the platform allows it. Record which rules are active, who owns them and how they were tuned. Rules written in a Google-specific language need translation before they run on another platform. Parsers map vendor logs into normalized fields, so they must be rebuilt and tested against sample data. Keep a register of each rule and the log types it depends on, so the rebuild can be checked against the originals.
Should we export raw logs or normalized events?
Export raw logs when you need an unaltered record for audit, legal hold or future reprocessing. Export normalized events when analysts need the fields they query against. Raw data keeps original fidelity but requires your own parsing later. Normalized data is easier to search, but it reflects the parser version used at ingestion, which may differ from what you would produce today. Many teams keep both for the period their evidence obligations require. Confirm with Google which forms the export path supports, and record the parser version alongside each export so reviewers can explain field mappings later.
What should we confirm in the contract before the end date?
Confirm the exact end date, any grace or read-only period, the data deletion timeline and how deletion is evidenced. Ask whether backups and copies are also deleted and whether you can receive written confirmation of deletion. Check which items your entitlement covers, including raw logs, normalized events, rules and dashboards. Ask about any fees for extended access during the transition. Get these answers in writing from Google or your reseller, and keep them with the project records. Legal and procurement should review them before the notice period closes.
How DeployOpen scopes and delivers a SecOps data exit
DeployOpen treats the export as a fixed-scope engagement in your own environment, starting from a written inventory of what Google Security Operations holds for your organization. We agree on which raw logs, normalized events, rules and parsers are extracted, where they land and how they are verified before work begins.
How we scope
- We inventory log sources, retention periods, rules, parsers and dashboards your team relies on in Google Security Operations.
- We agree in writing which raw logs, normalized events and detection content are exported, and which are out of scope.
- We confirm with you and Google which export paths your contract and edition allow before any extraction starts.
How we build
- We set up the target storage and access controls in your own cloud account, data center or air-gapped network.
- We build extraction jobs for each log type and test a sample from each source against the original data.
- We convert exported rules and parsers into documented formats for the replacement platform and record every mapping we make.
How we hand over
- We deliver an export report listing record counts, time ranges, checksums and any records that could not be extracted.
- We document the storage layout, retention settings, access model and the steps needed to query the archived data later.
- We hand over runbooks and walk your team through restoring and searching a sample so they can work without us.
How we support
- Ongoing support, upgrades and continuous testing of the archive are available as a retainer after the handover.
- If your subscription end date moves, we can re-scope the remaining sources in writing and adjust the timeline with you.
- We prepare the export evidence your auditors or compliance team may ask for, though independent auditors issue any formal assessment.
