Migrate from Splunk to OpenSearch

When migrating from Splunk to OpenSearch makes sense

Choose this path when your Splunk spend is driven mostly by log search, dashboards and retention, not by SIEM content, and when a renewal, a licensing change or a data residency requirement forces a decision. OpenSearch can take over log search and dashboards in your own infrastructure, but SIEM content and the forwarder fleet need separate planning. OpenSearch is Apache 2.0 licensed and forked from Elasticsearch 7.10.2, so the indexing and query layer is familiar to many engineers, and OpenSearch Dashboards covers most day-to-day dashboard work. Detections, correlation searches and the Splunk forwarder estate are different problems and should be scoped on their own.

Internal platform and security teams usually own this work, often with an outside implementation partner for cluster design, hardening and cutover. The first task is an inventory: which saved searches, dashboards and alerts are used every week, which indexes feed them, which sources send data through universal forwarders, and which teams depend on the output. Confirm with the vendor and your own environment which OpenSearch version your team will standardize on, since maintenance windows and end-of-life dates differ by release. Ask for a written scope that separates log search from detection content before any cluster is sized.

Effort and risk are concentrated in three places: translating SPL searches and dashboards into the OpenSearch query and visualization tools, rebuilding index lifecycle and retention policies to match Splunk's buckets, and making sure audit and access rules still meet your obligations. Access controls in the OpenSearch Security plugin, including role-based and field-level security and audit logs, need deliberate design rather than a copy of Splunk roles. Run both platforms in parallel long enough for analysts to confirm that results match, and plan a rollback path before Splunk licenses lapse.

Which Splunk capabilities map to OpenSearch and which need rework

This table compares the Splunk capabilities that a log search and dashboard workload usually depends on with their OpenSearch equivalents. Each row is marked clean, needs rework or gap, so you can see where a move is a configuration change and where it is a rebuild. Confirm every row against your own searches, alerts and apps before you commit to a cutover date.

Capability	Splunk	OpenSearch	Status
Search language	SPL with pipes, stats and eval commands	PPL, SQL and the Query DSL; SPL-to-PPL or DSL translation must be confirmed against your searches	Needs rework
Dashboards	Splunk Dashboards built from saved searches	OpenSearch Dashboards, derived from Kibana 7.10.2; panels are rebuilt, not imported	Needs rework
Saved searches and alerts	Saved searches and alert actions	Saved searches, monitors and alerting plugin; alerting logic must be re-verified per alert	Needs rework
Indexes and retention	Indexes with frozen and archive settings	Indices managed by index lifecycle policies, with snapshots for retention	Clean
Single sign-on	SAML and LDAP via Splunk authentication	Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JWT	Clean
Role-based access	Roles and capabilities in Splunk	Role-based access control in the Security plugin	Clean
Field and document security	Role-level search filters and field restrictions	Document-level security, field-level security and field masking in the Security plugin	Clean
Audit logging	Splunk audit index and internal logs	Audit logs in the Security plugin; confirm retention and export needs with your assessor	Needs rework
Splunk apps and add-ons	Apps and add-ons from Splunkbase	No direct equivalent; each app's parsing and dashboards need a custom build or a gap decision	Gap

Moving historical data and re-pointing ingestion

Historical Splunk data and live ingestion follow different paths, and each needs its own plan. The cards below cover the documented Splunk export methods, how to choose one by volume, how forwarders and syslog sources are re-pointed to OpenSearch, and why Splunk indexes cannot be opened directly as OpenSearch indices.

Splunk export methods

Splunk Web saved searches, the CLI, the REST API, SDKs, the dump search command and data forwarding are the documented ways to take results out of Splunk. Splunk describes the CLI as its most stable retrieval method, which makes it a sensible default for scripted bulk pulls. Confirm the export formats each method supports in your Splunk version before you build the pipeline.

Matching export method to volume

Small, one-off investigations can go through Splunk Web, which is quick but manual. Large histories call for the CLI or REST API run in batches over bounded time ranges, so a failed job restarts without repeating the whole archive. Ask your Splunk administrator how many events each time window contains before you choose a batch size.

Exporting in raw and structured formats

Raw events keep the original text, which helps when parsing rules must be rebuilt on the OpenSearch side. JSON preserves field names and types, so it is the usual choice for re-indexing with the _bulk API. CSV flattens nested fields and can lose data, so test it on a sample before using it for records you must keep.

Re-pointing forwarders and syslog

Universal forwarders, syslog senders and Beats-style agents each need a new destination. Point syslog senders and collectors at the new pipeline first, then move forwarders one source group at a time. Keep Splunk receiving the same feeds until the OpenSearch indices show matching event counts for each source.

Historical data as re-index or archive

Most teams either re-index exported history into OpenSearch or keep it in a read-only archive that is searched only when needed. Re-indexing gives one search surface but costs cluster storage and time. An archive keeps the cluster small but needs its own search path. Decide which datasets each option covers before exporting.

Splunk indexes are not OpenSearch indices

OpenSearch is wire-compatible with Elasticsearch 7.10 and can read indices from Elasticsearch 6.0 through 7.10, but Splunk stores data in its own bucket format, so a Splunk index cannot be attached to OpenSearch directly. Every historical event must be exported and mapped again. Plan field names, timestamps and index templates before the first bulk load.

How SPL searches and dashboards translate to OpenSearch

SPL is not a drop-in language for OpenSearch, so plan the search and dashboard work as a rebuild, not a copy. Splunk's Search Processing Language pipes commands together, while OpenSearch exposes the Query DSL over its REST API, and OpenSearch Dashboards provides visualizations, saved queries and index patterns. Start by exporting the saved searches, scheduled alerts and dashboards your team actually opens. The Splunk REST API can list them, and Splunk Web lets you review usage, so filter out the searches nobody has run in months before translating anything.

Group the remaining searches by the fields they filter on and by the question they answer, such as authentication failures, application errors or latency by host. Many dashboards collapse into a few reusable query patterns once grouped this way. Rebuild each group in Dashboards Discover, the query workbench or the query language the cluster supports, then check that every field you filter on exists in the index mapping with the expected type. Field mapping mismatches are the most common cause of searches that return nothing after a move.

Test the rebuilt searches side by side on the same time window. Run the Splunk search and the OpenSearch query against the same events, compare counts, top values and timestamps, and record any difference before you retire the original. Confirm current query language support, supported visualization types and dashboard feature coverage in the OpenSearch documentation for the exact version you plan to run, and do not assume parity with Splunk. Where a feature is missing, decide whether to rebuild it, move it to an application-side report, or drop it with sign-off from the team that owns the dashboard.

The migration sequence from inventory to decommission

The sequence moves log search and dashboards from Splunk to a self-hosted OpenSearch cluster in gated stages, so each source, search and retention rule is proven before users depend on it. Splunk stays available until the team has signed off each stage and archived what it must keep.

Inventory sources, searches, dashboards and users
Start by listing every data source sending events to Splunk, every saved search, alert and dashboard, and every user or group that opens them. Pull the index and sourcetype configuration from the Splunk admin team, and export the saved search definitions so they can be reviewed offline. Ask the platform owner to confirm which searches feed tickets, reports or audit evidence, because those are the ones that cannot quietly break. The output is a source register and a dashboard inventory, each item tagged as keep, rebuild or retire, and signed off by the owners of the teams that use them.
Set retention and access requirements
Before building anything, record how long each index must stay searchable and how long it must be retained in an archive, based on your own legal, contractual and internal policies. Confirm with compliance which fields are personal data and who may see them, since OpenSearch Security provides role-based access, document-level and field-level security and field masking that you will need to configure to match. Agree the index lifecycle tiers on paper. The output is a signed retention and access matrix that the later sizing and role design work will use.
Size the cluster for current daily volume
Measure the average and peak daily ingest for the sources in scope, then apply your retention matrix to estimate storage, memory and node count. Choose the installation method your team already operates, such as Docker, Helm, the OpenSearch Kubernetes Operator, RPM or Debian packages, and confirm it against the install documentation. Separate cluster and dashboard hosts from the Splunk estate so they can be patched independently. The output is a sizing sheet and a topology diagram reviewed by the platform owner, with the assumptions written down so they can be revisited when volume grows.
Pilot one log source end to end
Choose a single, low-risk source, such as one application's logs or a firewall feed, and point its collector at both Splunk and OpenSearch. Build the index template, ingest pipeline and index lifecycle policy for that source only, and rewrite its key searches in PPL or the Dashboards query tools. Confirm that fields, timestamps and parsing match between the two platforms. The output is a pilot report that lists field mismatches, parsing gaps and any search that could not be translated, along with the owner's acceptance.
Run Splunk and OpenSearch in parallel
Extend the dual-send to every source in scope and keep Splunk as the system of record while OpenSearch receives the same events. Run each translated search and dashboard against both platforms over the same time windows, and compare result counts, field values and alert firings. Log every difference and fix the cause, whether it is a parsing rule, a timezone setting or a query that behaves differently. Ask the team to confirm the comparison method before starting, because informal checks rarely catch missing events. The output is a signed-off search comparison sheet covering every item on the inventory marked keep.
Cut over users, dashboards and alerts
Move named user groups to OpenSearch Dashboards in stages, starting with teams whose workflows are simplest. Map each Splunk role to an OpenSearch role through the authentication backend your identity team uses, such as SAML, OpenID Connect or LDAP, and test that access restrictions behave as the retention and access matrix requires. Retire alerts only after their OpenSearch replacements have fired in parallel, and publish the new dashboard links to users. The output is a cutover record showing which groups, dashboards and alerts moved on which date, with the owner's sign-off for each group.
Decommission Splunk after archiving
Once no user, alert or report depends on Splunk, export the data you must keep through the Splunk CLI, REST API or saved search exports, and store it in your own archive with the retention periods from the matrix. Verify that a sample of archived events can be read back. Only then stop forwarders, revoke Splunk accounts and cancel or reduce the Splunk entitlement, after the contract terms have been checked with procurement. The output is a decommission certificate listing archive locations, verification results and the date Splunk stopped receiving data.

What drives cost and duration in a Splunk to OpenSearch move

This table lists the components that set the effort and recurring cost of moving log search and dashboards from Splunk to self-hosted OpenSearch, with the driver and the way to keep it down for each. Read it as a checklist for scoping and for comparing written quotes. No figures are given because none were supplied for this move; ask each bidder to price every row separately.

Driver	Why it changes effort or cost	How to keep it down and what to ask for in a quote
Inventory of sources, forwarders and saved searches	Every forwarder, input, index and saved search or dashboard must be mapped before anything is rebuilt. Undocumented sources usually cost the most time.	Export the inventory from Splunk first. Ask the quote to state how many sources, dashboards and searches it assumes, and whether the inventory is in fixed scope.
Staff time for SPL translation and dashboard rebuilds	SPL does not map one to one onto OpenSearch PPL or Dashboards queries. Each dashboard is rebuilt and checked by its users.	Retire unused dashboards before migrating. Ask for a per-dashboard rebuild list and who signs off on each result.
Cluster compute and storage sizing	Current daily ingest, replica count, retention window and search concurrency set node count, CPU, memory and disk. Compute and storage recur every month.	Measure current daily volume from Splunk license or index metrics. Ask the quote to show the sizing inputs and the monthly infrastructure cost it assumes in your cloud or data center.
Retention and index lifecycle design	Hot, warm and delete stages decide how much disk is needed and how old data is handled. Changing the policy later means reindexing or resizing.	Agree retention periods per index with compliance owners first. Ask for index lifecycle policy definitions as a deliverable.
Identity integration	Connecting OpenSearch Security to your identity provider through SAML, OpenID Connect, LDAP or Active Directory, with role mapping, takes coordination with the identity team.	Confirm which identity source is authoritative and who approves role mappings. Ask whether SSO, role mapping and access testing are included.
Number of forwarders and sources	Each source needs a new shipper or input and a parser check. Forwarder count drives both build time and ongoing maintenance.	Group sources by type and move the largest or most critical ones first. Ask for the number of inputs in scope and how parallel running is handled.
Upgrades, patching and staff time to run the cluster	OpenSearch releases a new minor version about every eight weeks, and each version is maintained until the next major version or one year, whichever is longer. Someone must plan and test each upgrade.	Choose a version with a maintenance window you can meet. Ask the quote to separate one-time build work from the recurring upgrade and on-call effort.
Outside implementation and support	A fixed-scope build, a retainer for upgrades or both change the total. Scope gaps are the most common source of extra cost.	Ask for written scope, deliverables, acceptance criteria and what is excluded. Request separate line items for build, training and ongoing support.

What usually goes wrong and how to prevent it

Most failed Splunk-to-OpenSearch moves do not fail on the query language. They fail on things nobody wrote down: dashboards, alert logic, retention periods, disk headroom, access controls and the trust analysts place in results. Each card below names one of these failure points, the step that prevents it and the role that should own that step.

Dashboards nobody inventoried

Splunk dashboards accumulate over years, and many were built by people who have since left. Before any ingestion is re-pointed, export a list of every dashboard, its owner, its last-viewed date and the indexes it reads. Dashboards with no views in the review window can be retired on purpose instead of breaking silently after cutover. Owner: the platform team lead, with each dashboard's named business owner confirming it is still needed.

Saved searches that drive alerts

A saved search scheduled with an alert action is a detection, even if no one thinks of it that way. Inventory every scheduled search and alert, record the action it triggers (email, ticket, paging or script), and translate each one into an OpenSearch alerting monitor with a test event. Searches that only feed a dashboard are a lower priority than searches that page someone. Owner: the security operations lead signs off on each alert translation.

Retention set too short for audit

Index lifecycle policies in OpenSearch delete data on the schedule you write, and nothing warns you when that schedule is shorter than an audit or incident review window. Take the retention periods required by your regulators, contracts and internal policy from the compliance lead, then set the hot, warm and delete stages to match them. Confirm the periods in writing before the first policy is applied. Owner: the compliance lead, with platform engineering configuring the policy.

Storage that fills during parallel run

Running Splunk and OpenSearch side by side doubles ingestion for the overlap period, and historical backfill adds more. A cluster sized only for steady-state daily volume can reach its disk watermark during this window and stop accepting writes. Calculate storage for both pipelines plus the backfill, keep headroom above the watermark thresholds, and set alerts on disk usage before the parallel run starts. Owner: the platform engineer responsible for capacity, reviewed against the sizing worksheet.

Authentication and access gaps

Splunk role and index permissions do not carry over automatically. Map each Splunk role to an OpenSearch role with explicit index patterns, and decide whether document-level or field-level security is needed for sensitive fields. Connect the Security plugin to your identity provider through SAML, OpenID Connect or LDAP, and check that admin certificates and TLS are enabled for node and client traffic. Owner: the identity lead, with the security engineer reviewing role mappings.

Trust lost over small result differences

Splunk and OpenSearch differ in how they tokenize text, handle time zones, round numbers and order events with equal timestamps. Analysts who see a count change by a few events will stop trusting the new platform, even when the new result is correct. Run a fixed set of reference searches against both systems over the same period, document each difference and its cause, and publish the list before cutover. Owner: the security operations lead, with an analyst who will own the reference set.

Setting index lifecycle policies and sizing the cluster

Set the index lifecycle policy before you migrate any data, because it decides how long events stay searchable and what each stage costs. In OpenSearch, an index state management policy moves indices through hot, warm, cold and delete states. Map them to Splunk's index lifecycle as follows: hot holds recent, actively written and frequently searched indices, roughly what a Splunk hot or warm bucket serves today; warm and cold hold older data that is still queried less often on cheaper storage; delete removes indices once the retention you set for compliance or investigations has passed. Splunk's frozenTimePeriodInSecs setting controls when data is frozen, so take the value from each index's indexes.conf and write it down as the delete age for the matching OpenSearch index pattern. Confirm the exact state and action names against the version you deploy, and test the policy on a non-production index first.

Size the cluster from measured numbers, not from the Splunk license or a rule of thumb. Four inputs drive the design: current daily ingest volume per index, the retention period for each hot and warm tier, the number of replica shards (each replica roughly multiplies stored data), and query load from dashboards, alerts and analysts. Ingest volume should come from your own Splunk license usage reports and from measurements at the forwarders, since the Splunk license meter does not capture every byte you will send to OpenSearch. Review the OpenSearch cluster design guidance for your exact version before you choose shard counts, node roles and storage types. Run a pilot that ingests real production traffic for a representative period, then size the production cluster from the observed index size, indexing rate and search latency. This document provides no sizing figures, so ask your platform team or implementation partner to produce them from the pilot results.

How the move differs by starting point

A single team that uses Splunk mainly for search and dashboards over a small number of sources usually has the simplest path. The cutover can be planned around a handful of inputs, a short list of saved searches and a few dashboards, and one team can own the whole change. The main risk is underestimating the dashboards and alerts that people rely on without thinking of them as migration items.

Sequence: Start with the two or three sources that drive most searches, point them at OpenSearch in parallel with Splunk, then move the rest in waves.
Identity model: Usually one administrator group and a few read-only roles. Map them onto the OpenSearch Security plugin backend your directory supports, such as LDAP or SAML.
Risk profile: Low data volume and few consumers, but a missed saved search can go unnoticed until an incident. Inventory every scheduled search and alert before the cutover.
Operations: One small cluster is often enough, with a single operator. Confirm the upgrade cadence and who applies security patches.

Before cutover, confirm with your team which dashboards and alerts are used weekly and which are unused.

Questions teams ask before moving from Splunk to OpenSearch

How much effort does moving from Splunk to OpenSearch take?

The effort depends mostly on how many sources feed Splunk, how many saved searches and dashboards your team relies on, and how much of your log content is tied to Splunk apps. A team that forwards a modest set of sources and uses Splunk for search and dashboards has a much smaller job than one with many custom apps, lookups and scheduled alerts. The main work falls into four areas: re-pointing ingestion, translating SPL searches and dashboards into OpenSearch queries and Dashboards objects, defining index lifecycle policies, and sizing a cluster for current daily volume. Ask any implementation partner to break the estimate into those four areas and to list which saved searches they consider out of scope.

What drives the timeline for a Splunk to OpenSearch migration?

The timeline is driven by the number of data sources, the number of dashboards and alerts that must match before cutover, the retention period you need to preserve, and how many approval cycles your security and change processes require. Parallel running is usually the longest phase, because you want the same searches to return comparable results on both platforms before you switch off Splunk. Your Splunk renewal date also matters, since it sets the deadline you are working toward. Request a written schedule from any partner that ties each milestone to a deliverable, and confirm which dependencies sit with your teams rather than with the partner.

Can our internal team migrate from Splunk to OpenSearch without outside help?

Yes, a team with experience running Linux servers, Docker or Kubernetes, and search engines can do the work internally, provided it has the time and the operational skills. The skills that are often thin are cluster tuning, TLS and authentication setup, shard management and upgrade planning. The SPL translation work also requires someone who knows which searches your analysts depend on. Many teams split the work: internal staff own the data sources and dashboards, while an outside partner handles hardening, sizing or the cutover runbook. Check your team's capacity honestly before choosing, because a cluster that is poorly sized or unpatched creates risk for the whole security program.

What does the work need from our staff?

The work needs named owners on your side for each data source, for the list of searches and dashboards that must keep working, and for sign-off on the retention and access model. Security engineers should validate that alerts still fire on known test events, and platform engineers should review the cluster design, storage layout and backup approach. Compliance or audit contacts should confirm which logs must be retained and for how long, because that decision sets the index lifecycle policies. Plan for analysts to test their daily searches during parallel running. Agree these responsibilities in writing before work starts so that gaps show up early.

Can we keep our historical Splunk data after the move?

You can keep historical data, but you need to decide what format it lives in and who can search it. Splunk search results can be exported through Splunk Web, the CLI, the REST API, SDKs and other methods described in Splunk's documentation, and the CLI is the method Splunk describes as its most stable retrieval option. Large exports take longer and need careful planning, so split them by time range and index. Once the data is in files or a separate archive, decide whether it is re-indexed into OpenSearch or kept as read-only archives. Confirm with your compliance team that the export format and integrity checks meet the retention rules that apply to you.

Does OpenSearch have an enterprise edition with paid features?

OpenSearch is released under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe a paid edition of the project. That means the core search, indexing, Dashboards and Security plugin features are available to self-host without a license fee. Costs come from the infrastructure you run, the staff who operate it, and any outside support or retainer you buy. Some vendors sell managed OpenSearch or support contracts, which are separate commercial agreements and not editions of the project. Ask any vendor to state exactly which features, if any, sit behind a paid tier, and confirm that answer against the current licensing statements.

How are OpenSearch upgrades handled under its maintenance policy?

OpenSearch releases a new minor version about every eight weeks, and each version stays in maintenance until the next major version enters maintenance or one year passes, whichever is longer. During maintenance, versions receive bug fixes and security patches but no new features. Version 1 reached end of life on May 6, 2025, and version 2 is maintained through the 4.0 GA release, so plan upgrades before a version leaves maintenance. Rolling upgrades are supported, and the OpenSearch documentation covers migration and upgrade steps, which you should review for your current version. Budget recurring staff time for testing and patching, and ask any partner whether upgrades are included in a retainer or priced separately.

How DeployOpen scopes and runs a Splunk to OpenSearch migration

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For this migration, we start from the log sources, searches and dashboards your teams depend on, then build and hand over an OpenSearch cluster that runs in your cloud account, data center or air-gapped network.

How we scope

Inventory every Splunk input, forwarder group, index and daily ingest volume that the new cluster must receive.
Classify saved searches and dashboards by use, separating log search from SIEM content that belongs in a different migration path.
Agree the written scope, deliverables and timeline with you before work starts, since engagements are fixed-scope.

How we build

Re-point log shipping to OpenSearch and set up index lifecycle policies that match your retention requirements.
Translate SPL queries and dashboards into PPL or Dashboards equivalents, testing each one against the same time ranges in Splunk.
Size the cluster for current daily volume, configure TLS, roles and audit logging through the OpenSearch Security plugin, and test the result.

How we hand over

Document the ingestion paths, index lifecycle settings, cluster sizing assumptions and the dashboard translation log.
Run a parallel period with your teams so they can compare Splunk and OpenSearch results before any source is cut over.
Provide runbooks for upgrades, backups and access changes, so your own staff can operate the cluster after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
Plan OpenSearch upgrades against the release and maintenance schedule, with the work scoped in writing each time.
Ask any implementation partner for the written scope, deliverables and support terms before you agree to a quote.