Notifications
Clear all
Topic starter
19/08/2026 3:56 pm
TL;DR: Splunk-to-Dynatrace migrations shift teams from index-based ingest and SPL to schema-on-read Grail and DQL, with upstream filtering used to reduce cost and preserve signal quality, according to Edge Delta. The governance issue is not just query translation but controlling data shape, retention, and token scope across the pipeline.
NHIMG editorial — based on content published by Edge Delta: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Edge Delta's guide on migrating log analytics from Splunk to Dynatrace →
Splunk to Dynatrace migration: what changes for observability teams?
Explore further
19/08/2026 4:34 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Splunk to Dynatrace migration changes log analytics governance
