Splunk to Dynatrace migration changes log analytics governance

At a glance

What this is: This is a migration guide for moving log analytics from Splunk to Dynatrace Grail using Edge Delta as the processing layer, with the key finding that upstream log shaping reduces cost and preserves analytic signal.

Why it matters: It matters because log pipeline design affects access control, retention, and auditability, and identity teams often rely on these telemetry paths for security detection and investigation.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Edge Delta's guide on migrating log analytics from Splunk to Dynatrace

Context

Log migration is not only a tooling change, it is a governance change because the ingest path, query model, and retention design all affect what security teams can see and prove later. In this case, the primary issue is moving from indexed log search to schema-on-read analytics without losing fidelity, while still keeping access to the telemetry pipeline controlled and auditable.

For identity and security teams, the relevant question is how log data is shaped before it reaches the analytics layer. Edge Delta sits in the middle of that flow, so the migration touches secrets handling, token scope, and the ability to preserve investigation-ready evidence as logs move between systems.

Key questions

Q: How should teams migrate log analytics without losing detection fidelity?

A: Start by mapping the queries, dashboards, and alerts that matter most, then preserve the fields those controls depend on through preprocessing. Dual-write during pilot, compare results across platforms, and do not cut over until parsed fields, counts, and alert behaviour match closely enough for operations.

Q: Why do log pipeline credentials need identity governance?

A: Because ingest tokens and forwarder credentials can write into the monitoring record, so they control the integrity of the evidence stream. If those credentials are over-privileged, stolen, or reused broadly, an attacker can alter what defenders see and weaken incident response.

Q: How do security teams know if preprocessing is hiding important events?

A: Compare raw and transformed output for security-relevant fields, run known detection scenarios through the pipeline, and verify that alert thresholds still fire on the transformed records. If summaries reduce context that responders need, the preprocessing layer is too aggressive.

Q: Who is accountable for log retention and archive design during migration?

A: Platform owners, security operations, and compliance stakeholders all share responsibility, but the accountable team must define retention periods, archive destinations, and evidence access rules before cut-over. In regulated environments, that accountability should be documented and tested like any other production control.

Technical breakdown

Index-based log search versus schema-on-read analytics

Splunk and Dynatrace differ first in storage and query behavior. Splunk relies on indexed ingest and SPL, which means field extraction and search performance are tied to how data is parsed at collection time. Dynatrace Grail is schema-on-read and indexless, so records are stored more flexibly and interpreted when queried through DQL. That reduces upfront modelling but pushes more responsibility into query design and upstream log shaping. For migration teams, the key architectural issue is not simply replacing one query language with another. It is deciding which fields should be normalised before storage and which can remain dynamic until analysis time.

Practical implication: pre-structure the fields that drive security detections and incident workflows before you decommission Splunk indexing paths.

Edge Delta as a telemetry processing control point

Edge Delta is positioned as a stream-processing layer between sources and destinations. In practice, that means it can ingest Splunk forwarder traffic or HEC input, apply grok parsing, filtering, aggregation, and summarisation, then forward only the records that matter to Dynatrace Grail. This is technically important because it changes the control boundary. Instead of treating the destination platform as the primary point of intelligence, the pipeline itself becomes a policy layer for data reduction, enrichment, and routing. That matters for observability security as well, because the same layer can fork data to archive stores or validation targets during migration.

Practical implication: treat the pipeline as an enforceable control plane for data minimisation, validation, and archival routing.

Why token scope and log integrity matter in migration

The guide makes clear that Dynatrace ingestion depends on a token with logs.ingest scope, while the Splunk side still depends on forwarder configuration and compatibility settings such as legacy S2S protocol support. Those details are easy to treat as plumbing, but they determine whether the migration preserves integrity or drops data silently. In a security context, token scope is an identity problem because the ingest credential governs who or what can write telemetry into the destination platform. If that credential is over-privileged or poorly stored, the migration introduces a new trust exposure even when the analytics outcome looks correct.

Practical implication: place ingest tokens under least-privilege control and verify end-to-end log completeness before cut-over.

NHI Mgmt Group analysis

Log migration is an identity and governance problem, not just a platform swap. When telemetry moves between systems, the control question becomes who can inject, transform, and retain evidence along the path. That matters to IAM and PAM teams because ingest credentials, archival destinations, and validation flows all shape the trust boundary. The operational conclusion is simple: migration plans should include access governance for the pipeline itself.

Schema-on-read improves flexibility, but it also shifts security responsibility upstream. When fields are extracted at query time, teams need stronger discipline around pre-processing, field normalization, and investigation-ready logging. That is especially relevant for security operations because detection logic can fail if the source event structure is inconsistent. Practitioners should therefore tie pipeline design to detection requirements, not just storage economics.

Pipeline-based log shaping creates a named control pattern: telemetry minimization with retention integrity. The idea is to drop noise before storage while preserving enough structure for audit, response, and compliance. This is not the same as simple cost cutting, because over-filtering can destroy evidence. Teams should treat the balance between minimization and retention as a governed design decision, not a tuning exercise.

Least-privilege ingest credentials belong in the observability security model. The article’s mention of logs.ingest scopes is a reminder that telemetry systems are also identity systems. If the ingest path is over-permissioned, an attacker or careless operator can corrupt the monitoring record. The practitioner takeaway is to align log pipeline permissions with the same standards used for production application identities.

What this signals

Migration programmes increasingly fail when teams optimise for cost reduction but ignore the identity governance of telemetry pathways. In practice, ingest tokens, forwarders, and archive destinations all become part of the security boundary, so observability architecture now needs the same entitlement discipline applied to production systems.

Telemetry minimization with retention integrity: the useful pattern is to reduce noisy data in flight without destroying evidence quality for later investigation. That requires explicit controls for preprocessing, validation, and archive routing, plus alignment with frameworks such as the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls.

As more teams move from indexed search to schema-on-read analytics, the governance burden shifts from storage design to control assurance. The practical signal is whether your pipeline can preserve detection fidelity, evidence quality, and least-privilege access at the same time.

For practitioners

• Inventory query dependencies before cut-over Map every SPL search, dashboard, and alert to the fields it actually needs, then decide which of those fields must be preserved through Edge Delta preprocessing and which can remain schema-on-read in Dynatrace.
• Apply least-privilege to ingest credentials Store Dynatrace ingest tokens in controlled secret stores, limit them to logs.ingest scope, and review any Splunk forwarder or HEC credentials that can write into the pipeline.
• Run dual-write validation before decommissioning Splunk Send the same telemetry to both systems during pilot and dual-write stages, then compare counts, parsed fields, and alert outcomes to catch loss introduced by filtering or format changes.
• Set retention and archive rules up front Define how long Grail buckets retain logs, when archives move to S3 or Azure Blob Storage, and which records must stay available for audit or incident reconstruction.
• Test parsing against security detections, not samples alone Validate grok, filtering, and aggregation rules against real incident scenarios so the pipeline preserves the indicators used by responders rather than only producing clean output.

Key takeaways

• This migration is really about controlling how telemetry is shaped, retained, and trusted as it moves between platforms.
• The strongest operational risk is not the query language change, but the possibility that preprocessing or credentials weaken detection fidelity and evidence integrity.
• Teams should validate fields, scope ingest access tightly, and prove dual-write consistency before cutting Splunk out of the path.

Key terms

• Schema-on-read: Schema-on-read means data is stored first and structured later, at query time. For security teams, that allows many log formats to land in one place without upfront modelling, but it also means ingestion validation must catch format drift before detections and investigations start failing.
• Telemetry pipeline: A telemetry pipeline is the path security data follows from collection to analysis and retention. In mature environments it must preserve context, maintain throughput, and avoid introducing blind spots as sources, formats, and volumes change over time.
• Ingest token: A credential that authorises a system or agent to send data into an analytics platform. In observability and security tooling, ingest tokens must be treated like production secrets because they can affect data integrity, visibility, and downstream investigation quality.
• Dual-write validation: A migration technique where the same data is sent to two systems at once so results can be compared before cut-over. It helps teams detect parsing errors, field loss, and query mismatches before one platform is retired.

What's in the full article

Edge Delta's full guide covers the operational migration detail this post intentionally leaves for the source:

• Step-by-step Splunk forwarder and HEC configuration examples for routing traffic into Edge Delta
• Pipeline processor patterns for grok parsing, filtering, aggregation, and summarisation before Dynatrace ingestion
• Practical DQL translation examples for rebuilding SPL logic in Grail
• Cut-over sequencing guidance for pilot, dual-write, validation, and decommissioning

👉 The full Edge Delta guide covers pipeline configuration, DQL mapping, and cut-over sequencing in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, secrets management, and workload identity. It helps security practitioners connect identity controls to the broader security programmes they run.