Overview
This is a typical-engagement scenario, not a delivered customer story. A platform team is considering OpenSearch as a replacement log store and needs to know what leaving Splunk would involve. Storage is the smaller half of that question. The larger half is the content built over years in SPL: saved searches, scheduled alerts, dashboards, lookups and field extractions that other teams depend on.
Challenge
Nobody can say how many saved searches exist, which are still used, who owns them, or what each alert triggers. Some alerts page an on-call rota. Some feed a ticket queue. Some only exist because of a long-closed incident. Without that picture, any estimate of the migration is a guess, and a cutover that drops an alert nobody remembered is the failure the team fears most.
Environment
Splunk Enterprise or Cloud Platform with search heads, indexers and forwarders, and a candidate OpenSearch cluster on Kubernetes or virtual machines. Content spans several apps and owners, with lookups, macros and data models in use.
Approach
We work from evidence of use, not from the list of what exists. Search and alert definitions are exported from the REST API and the internal audit indexes, joined to run history and owners, and sorted into keep, rewrite, merge and retire. Each keep or rewrite item is mapped to an OpenSearch equivalent (a query in DSL or PPL, a monitor, or a dashboard panel) and tested by running both stores on the same sample window and comparing result sets. There is no automatic conversion of SPL, so every rewrite is a reviewed change.
Solution
- Inventory of saved searches, scheduled searches, alerts, dashboards, lookups, macros and data models, with owner and last-run evidence
- Classification into keep, rewrite, merge and retire, agreed with the owning teams
- Field-extraction map from Splunk props and transforms to OpenSearch ingest pipelines and index mappings
- Per-item target design: query language, monitor or dashboard, with notes on features that have no direct equivalent
- Parity test plan comparing result sets on the same sample window in both stores
- Dual-running and alert-retirement plan, with a rollback path and a cutover order by criticality
- Written findings and a sizing sheet for effort and for the OpenSearch cluster
Outcome
The team receives a counted, owner-confirmed inventory and a per-item mapping, a test method for proving parity, and a sequenced plan with dual running. The decision to proceed, stay on Splunk or reduce ingest first can then be made on evidence. The engagement stops at the written plan unless the team asks AceMQ to continue.
Technologies
Splunk
OpenSearch
Kubernetes
Linux
Amazon S3
Kafka
OpenTelemetry
