TL;DR: Moving telemetry from Splunk to Google SecOps can be done in parallel, with Bindplane used to add SecOps as a second destination, route selected log sources or business units, and apply destination-specific processing without a rip-and-replace migration, according to Bindplane. The key governance issue is preserving detection continuity while reworking ingestion, parsing, and rollout control.
At a glance
What this is: Bindplane outlines a phased SIEM migration pattern that keeps Splunk running while teams add Google SecOps as a parallel destination, then shift sources, routes, and processors in controlled steps.
Why it matters: For IAM and security operations teams, the key issue is not the destination swap itself but preserving telemetry fidelity, routing control, and detection continuity during the transition.
Context
Moving telemetry from one SIEM to another is a governance problem as much as a tooling problem. The migration has to preserve visibility, parser correctness, and rollout control while avoiding a gap where detections stop firing or data arrives in the wrong format. In this article, the identity angle is indirect but real: telemetry pipelines often carry authentication, access, and NHI-related events that must remain observable during change.
The article describes a dual-write migration pattern rather than a cutover. That matters because teams can validate SecOps against the existing stack, route selected sources or business units, and reduce operational risk before decommissioning the legacy destination. The typical failure mode in SIEM migration is not the target platform itself, but the visibility loss that happens when ingestion, filtering, or parsing is changed too quickly.
Key questions
Q: How should teams validate SIEM migration without losing detection coverage?
A: Teams should validate migration on identical source data, not on assumed equivalence between platforms. Build a rule-by-rule parity matrix, compare alert volumes, and check field completeness for every critical source group. If translation changes aggregation or lookup behaviour, treat that as a detection design issue, not a tuning nuisance.
Q: Why do SIEM migrations fail when telemetry is moved too quickly?
A: They fail when ingestion, parsing, or routing changes outpace detection rebuilds. That creates a gap where data still exists but no longer lands in a form the new platform can classify, alert on, or search reliably.
Q: What are the signs that a SIEM cutover is creating visibility loss?
A: Searches that return incomplete recent data, detections that stop firing for a known source, or dashboards that diverge from the legacy SIEM are all warning signs. Those symptoms usually point to routing or parser misalignment rather than a platform defect.
Q: Should teams prioritize dual-write or full cutover for SIEM migration?
A: Dual-write should come first whenever detection continuity matters. A staged overlap lets teams prove that the new destination receives the right data and that security workflows still operate before the old path is retired.
Technical breakdown
Parallel ingestion as a migration control
Parallel ingestion means the collector or pipeline sends the same telemetry to two destinations at once. In this pattern, the existing SIEM continues to receive events while the new platform is evaluated in production conditions. The technical value is not duplication for its own sake, but the ability to compare ingestion behaviour, query response, and detection output before any source is removed from the old path. This is especially useful when logs feed auth, endpoint, cloud, or NHI detections that cannot tolerate blind spots.
Practical implication: Use dual write to validate the new SIEM before any legacy destination is disconnected.
Routing logic and destination-level processors
Routing connectors and destination-level processors let teams decide which log sources, business units, or fields go to which destination. That matters because migrations rarely happen uniformly across every source. One log type may be ready for SecOps while another still depends on Splunk dashboards or rules. Destination-specific processing also avoids forcing one normalisation path onto both systems. Instead, the SecOps path can preserve raw logs and apply only the labels or transforms that SecOps needs for parsing and retention.
Practical implication: Separate migration scope by source or business unit so control changes do not affect the whole telemetry estate.
Raw logs and parser alignment in SecOps
Google SecOps expects raw, unparsed logs so its own parsers can classify the data correctly. That means the migration problem is not just transport, but preserving the original event content and setting the right metadata for parser selection. If a pipeline normalises too early or strips fields needed for classification, the downstream platform may misread the event. This is why standardisation processors, explicit log types, and field-level review matter during cutover.
Practical implication: Preserve raw event structure on the SecOps path and set log type metadata deliberately before rollout.
Threat narrative
Attacker objective: The practical attacker advantage is temporary visibility loss during a SIEM transition, which can delay detection and response on events that should still be observable.
- Entry occurs through a migration path where telemetry is copied to a new destination while the legacy SIEM remains live, reducing the risk of an all-at-once cutover failure.
- Credential or event integrity is preserved only if raw logs, log types, and routing rules are configured correctly; otherwise detections may lose the context they need to work.
- Impact appears as blind spots, missed detections, or dashboards that no longer reflect the environment if the migration changes ingestion or parsing too aggressively.
Breaches seen in the wild
- Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Telemetry migration is a governance exercise, not a copy job. The hard part is preserving detection continuity while changing where logs land, how they are parsed, and which teams rely on them. In practice, migration plans that treat routing and rollout as operational afterthoughts create avoidable visibility gaps. The practitioner takeaway is to govern SIEM cutovers as staged control changes, not simple destination swaps.
Detection continuity depends on parser correctness at the destination boundary. Raw log handling, log type assignment, and enrichment choices determine whether the downstream platform can classify events accurately. That makes the destination path a control surface, not just a transport layer. Teams should treat parser alignment as part of migration design, especially when auth, endpoint, and cloud events feed security use cases.
Dual-write is the right pattern when confidence matters more than speed. Running SecOps alongside an existing SIEM lets teams validate queries, detections, and dashboards without forcing an irreversible cutover. That approach also reduces pressure to drop data just to control cost during evaluation. The broader market signal is that migration success now depends on operational coexistence, not platform replacement alone, and practitioners should plan for staged overlap.
The real risk in SIEM migration is blind-spot creation during change control. When routing logic or source coverage changes faster than detections are rebuilt, teams inherit a temporary but material loss of assurance. That is especially important where identity and access telemetry support threat hunting or incident response. Practitioners should assume any cutover can weaken observability unless the migration is deliberately bounded and verified.
What this signals
SIEM migration pressure is really telemetry governance pressure. Teams are not only choosing a new destination, they are deciding how much visibility they can afford to lose while changing ingestion, routing, and parsing. The safest programmes treat that transition as a controlled coexistence period, not a cutover event.
Destination-specific processing is the part most teams underdesign. Once data is split between platforms, each path needs its own logic for raw delivery, field handling, and parser alignment. That is where many migrations either preserve detection continuity or quietly create the blind spots they were meant to remove.
For practitioners
- Implement dual-write telemetry during migration Keep Splunk receiving events while SecOps is added as a second destination, then verify that searches, detections, and dashboards behave as expected before shifting scope.
- Migrate one log source or business unit at a time Use filters or routing connectors to move a single source, region, or team first, then expand only after the new path is validated in production.
- Preserve raw logs on the SecOps path Enable raw event delivery and set the log type, namespace, and ingestion labels explicitly so SecOps can apply the correct parser.
- Use destination-specific processors for sensitive fields Apply redaction, field dropping, or selective enrichment only on the SecOps path when those changes should not affect the legacy SIEM.
Key takeaways
- The central risk in SIEM migration is not platform change itself but temporary loss of telemetry fidelity and detection continuity.
- A dual-write design lets teams validate SecOps while keeping the existing SIEM operational, which reduces the chance of blind spots.
- Controlled source-by-source routing and destination-specific processing are the controls that make a phased migration workable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Telemetry routing and destination access depend on controlled permissions and correct authorisation. |
| DE.CM-01 — Networks and systems monitored to detect potential cybersecurity events | The article is about preserving monitoring coverage while changing SIEM backends. | |
| Recommendation — Apply PR.AA-05 to restrict who can change telemetry destinations and routing rules. Use DE.CM-01 to verify that monitoring remains continuous during migration. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The migration hinges on retaining and routing logs without breaking downstream use cases. |
| Recommendation — Apply CIS-8 to preserve log collection, routing, and retention across both destinations. | ||
| MITRE ATT&CK | TA0007;TA0010 — Discovery; Exfiltration | Telemetry blind spots can support attacker discovery evasion and data theft. |
| Recommendation — Map migration blind spots to TA0007 and TA0010 when validating coverage gaps. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article relies on keeping telemetry sources, routes, and destinations correctly inventoried. |
| Recommendation — Use API9 thinking to inventory telemetry paths, destinations, and dependencies before cutover. | ||
Key terms
- Dual Write: Dual write is a migration pattern where the same telemetry is sent to two destinations at once. It lets teams validate the new platform against live traffic before removing the legacy destination, reducing the chance of detection gaps during transition.
- Telemetry routing: The process of directing logs and events to different destinations based on value, urgency, and investigative need. In mature SOC designs, routing is a security control because it determines which events remain searchable in the SIEM and which are archived more cheaply.
- Branch-Level Processing: Branch-level processing means applying different transformations to different routes within the same pipeline graph. It is useful when one data path needs redaction or reduction while another needs full fidelity, but it also makes governance harder because control decisions are no longer uniform across the pipeline.
- Raw Log Preservation: Raw log preservation means keeping the original event structure intact so the destination platform can parse and classify it correctly. It matters when the new SIEM depends on its own parsers or labels to detect and search events accurately.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners connect telemetry, access control, and governance decisions across modern security programmes.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org