What you can take out of Splunk before you leave
Splunk lets you export search results through six documented methods: Splunk Web, the CLI, the REST API, the Splunk SDKs, the dump search command and data forwarding. Splunk Cloud Platform customers can also archive expired index data to their own Amazon S3, Google Cloud Storage or Azure Blob Storage location through Dynamic Data Self Storage (DDSS). If a renewal, a licensing change under Cisco's ownership, or a data residency requirement is forcing a move, these two paths determine what leaves Splunk and in what form. Search exports return events, CSV, JSON or XML, and PDF is available only for saved searches in Splunk Web. DDSS keeps only the raw data journal from each bucket, so index metadata and search-time artifacts are not carried into your archive.
Several things are not covered by these paths. DDSS archives can be restored only to a Splunk Enterprise instance, not back into Splunk Cloud Platform, so a restore target must exist before you depend on it. The storage location must be in the same region as your Splunk Cloud Platform environment, which can shape where your archive lands if you need it elsewhere. Saved searches, dashboards, alerts, correlation content and configuration are not exported as part of the data paths described here, so you will need a separate inventory. Confirm current limits and supported formats with Splunk and your own environment before you plan volumes. The sections that follow cover choosing a method by volume, the DDSS setup, and the restore constraints.
Export methods, formats and volume fit for Splunk search results
This table compares the six documented ways to export Splunk search results, the formats each one supports and the volume Splunk's guidance assigns to it, plus the separate Dynamic Data Self Storage archive path for Splunk Cloud Platform. Use it to match each export route to the size and frequency of the data you need to move before a platform change.
| Export route | Formats | Volume fit and notes |
|---|---|---|
| Splunk Web | Raw events, CSV, JSON, XML; PDF for saved searches only | Low-volume, on-demand exports from the browser |
| Splunk CLI | Raw events, CSV, JSON, XML | Medium-volume, on-demand exports; Splunk calls it the most stable retrieval method |
| REST API | Raw events, CSV, JSON, XML | High-volume, automated computer-to-computer exports; requires scripting and credentials |
| Splunk SDKs | Raw events, CSV, JSON, XML | High-volume, automated exports from application code; language choice is yours |
| Dump search command | Raw events, CSV, JSON, XML | Confirm the fit for your search volume with Splunk documentation before relying on it for a full export |
| Data forwarding | Forwarded events rather than exported files | Streams events onward to another system; plan the receiving side and duplicate handling before cutover |
| Dynamic Data Self Storage (Splunk Cloud Platform) | Raw data journal from expired buckets, stored in your S3, GCS or Azure bucket | Requires Splunk Cloud Platform; storage must sit in the same region; restore only into Splunk Enterprise, not back into Splunk Cloud Platform |
Which export method fits your volume and team
A single analyst exports the results of one search, usually to answer a question, support an incident or hand a sample to a colleague. Splunk's export guidance treats Splunk Web as the right tool for low-volume, on-demand exports, so this work needs no scripting and no approval beyond the analyst's own search permissions. The output is typically a raw events file, CSV or JSON, and PDF is available only for saved searches in Splunk Web.
- Who runs it: the analyst, from the search interface, with no engineering involvement.
- What comes out: a file per export, in the format the analyst picks, sized by the result limits set in the environment.
- What to script: nothing. Keep a record of the search string and time range so the pull can be repeated.
- What to approve: whatever your data handling policy requires for moving security or personal data out of the platform.
Before a migration, confirm with your Splunk administrator which result limits and export roles apply to your users, since these settings decide whether a one-off pull is practical for the data you need.
A recurring extract that runs on a schedule but still fits within a human-operated process usually goes through the Splunk CLI. Splunk calls the CLI the most stable retrieval method, and its export guidance places it at medium on-demand volumes. A platform or security engineer typically owns the job, and the team wraps the command in a script with a fixed search, time window and output path.
- Who runs it: a platform or security engineer, with the job stored in version control and run from a controlled host.
- What comes out: files written to a path you choose, in the formats the CLI supports, which your downstream tools can read on a schedule.
- What to script: the search, the time window, the output naming, the credentials handling and error checks for partial exports.
- What to approve: the service account, its role and the destination storage, which should match your retention and access rules.
When you plan the migration, record each recurring extract, its search and its consumers, because a CLI job that nobody documented is the export most likely to break unnoticed.
Moving a large volume of historical events to a new platform is a computer-to-computer job. Splunk's guidance points to the REST API and the SDKs for high-volume automated exports, because they let a program page through results, handle retries and write to the target system without a person in the loop. This is usually an engineering project with its own design, testing and sign-off, and it is the method most likely to need custom code.
- Who runs it: a development or platform team that owns the transfer code, with security review of the service account and the data path.
- What comes out: structured records, usually JSON or XML, that the receiving pipeline ingests directly.
- What to script: pagination by time window, checkpointing so a failed run resumes, validation of record counts, and a plan for rate limits set by your Splunk environment.
- What to approve: the transfer design, the staging location and the reconciliation method that proves the target matches the source.
Ask your Splunk team for the search concurrency and export limits in your environment before sizing the job, since no throughput figure is given here and the real limit depends on your deployment.
How Dynamic Data Self Storage moves expired Splunk Cloud data to your bucket
Dynamic Data Self Storage (DDSS) applies only to Splunk Cloud Platform indexes. When indexed data reaches the end of its retention period, DDSS moves it to a bucket or container you own: an Amazon S3 bucket, a Google Cloud Storage bucket or an Azure Blob Storage container. The feature needs no license add-on, so the cost question shifts to the storage you pay for in your own cloud account. Before you enable it, confirm with Splunk that your environment supports DDSS and that your retention settings produce the archive volume you expect. The Splunk Cloud Platform admin manual entry on storing expired data in your private archive is the primary reference for the setup steps.
Two constraints shape the archive design. DDSS keeps only the raw data journal from each bucket, so index metadata is not preserved and the archive is a copy of raw events rather than a searchable index. The storage location must be in the same region as your Splunk Cloud Platform environment, which should be settled with your cloud and compliance teams before you create the bucket or container. Plan the region, the bucket policy and the retention period together, and record who owns the storage account, since you are responsible for its access controls and lifecycle.
Restores are one-way and limited. Archived data can be restored only to a Splunk Enterprise instance, not back into Splunk Cloud Platform. Restored data is placed in the thawed directory as bucket structures and does not count against indexing license volume. For a migration, this means you need a Splunk Enterprise instance ready to receive restored buckets, and you should test one restore of a representative bucket before you rely on the archive as your exit path. Ask Splunk to confirm the current restore procedure and version requirements for your environment.
What does not export cleanly and the workaround for each
The documented export paths move search results and, on Splunk Cloud Platform, expired index data. They do not carry the surrounding configuration, content and access model that makes a Splunk deployment work. The cards below list each gap, the workaround we would start with, and what to confirm with Splunk before you rely on it.
Index metadata and configuration
Search export returns events, not the definition of the index that holds them. Retention settings, index sizes, data types and storage paths live in configuration files and in the admin interface, not in the events themselves. Before the move, record each index's retention period, maximum size and sourcetype mapping, then keep a copy of the index configuration files from your Splunk Enterprise deployment. On Splunk Cloud Platform, ask Splunk which index settings you can read through the admin interface, since the cloud service restricts direct file access. Confirm this with Splunk.
Apps and dashboards as a whole
Dashboards, reports and apps are stored as configuration and XML objects tied to specific indexes, sourcetypes and knowledge objects. Exporting a dashboard as PDF or as search results captures the rendered output, not the panels, searches or permissions that produce it. Inventory each app and dashboard, export the saved search definitions from the app's configuration directory on Splunk Enterprise, and rebuild the dashboards in your target platform. Treat the PDF exports as a record of what was shown, not as a migration artifact.
Correlation searches and alert definitions
Correlation searches, alert conditions, schedules, throttling and action settings sit in the saved search configuration, not in the indexed data. A search export returns the results of a search at one moment, so the logic that generated the alert is lost. Copy the search text, schedule and trigger conditions for each alert from the saved search definitions, then map them to detection rules in the target platform. Run both systems in parallel until the new rules produce the same alerts on the same events.
User accounts and role mappings
Exports carry no user accounts, role assignments, authentication settings or capability grants. Splunk's access model, including which roles can search which indexes, cannot be read from event data. Document each role, its capabilities and index access by hand, along with the group or identity provider mapping used for single sign-on. Confirm with Splunk which account and role details are available for export from your deployment type, and plan to recreate access controls in the target platform rather than copying them.
Index data that has not expired
Dynamic Data Self Storage applies only to data that has reached the end of its retention period on Splunk Cloud Platform. Data still inside its retention window can only leave through search export, which suits small and medium volumes. For larger volumes, the REST API and SDKs suit automated, computer-to-computer export, while the CLI is the most stable method for medium on-demand exports. Estimate the data volume per index before choosing a method, and schedule the export to run before any retention change removes events.
Expired buckets on Splunk Cloud
For Splunk Cloud Platform customers, Dynamic Data Self Storage moves expired data to a customer-owned Amazon S3 bucket, Google Cloud Storage bucket or Azure Blob Storage container. It keeps only the raw data journal from each bucket, so index metadata and search-time knowledge are not preserved. The storage must sit in the same region as the environment, and archived data can be restored only into Splunk Enterprise, not back into Splunk Cloud Platform. Confirm with Splunk whether a restore path into your target platform is supported.
The sequence for a complete Splunk export with checks at each step
This sequence turns an export from ad hoc downloads into a documented, verifiable transfer, where each set of exported data can be matched to its source, its time range and a restore test before the old environment is retired.
Inventory indexes, sources and retention
The Splunk administrator lists every index, its data sources, its retention settings and its approximate daily volume, working from the index configuration and the current license usage reports in the Splunk instance. Security and compliance owners confirm which indexes hold regulated or incident-relevant data. The step is done when the inventory is signed by both teams and every index has a named owner and a stated retention period. Any index without an owner is a blocker, because nobody can later confirm what was exported.
Confirm scope and time ranges per dataset
For each index, the team decides which data leaves Splunk, which time ranges are required (for example, data still inside active retention, or data already past retention) and which fields the receiving system needs. Legal or records teams should confirm any hold or retention obligation before anything is deleted at the source. The output is a written export register that lists each dataset, its time window and its receiving destination. The check is that someone outside the Splunk team can read the register and identify exactly what should exist at the end.
Match each export to its method and volume
Splunk documents six export routes: Splunk Web, the CLI, the REST API, the Splunk SDKs, the dump search command and data forwarding. Its export guidance suggests Splunk Web for low-volume, on-demand exports, the CLI as the most stable method for medium on-demand exports, and the REST API or SDKs for high-volume automated transfers. Teams should pick one method per dataset and record it in the register. The check is a trial export of a small time window through the chosen method, which confirms that the output format (raw events, CSV, JSON or XML) keeps the fields the receiving system needs.
Configure DDSS for expired buckets
Teams on Splunk Cloud Platform can set up Dynamic Data Self Storage so that expired index data moves to a customer-owned Amazon S3 bucket, Google Cloud Storage bucket or Azure Blob Storage container. The storage must sit in the same region as the Splunk Cloud Platform environment, and only the raw data journal from each bucket is kept. The cloud administrator and the Splunk administrator should confirm access, encryption and retention on the target storage before enabling the archive. The check is that a bucket appears in the target storage after the first expiry cycle, and that its contents match the index names listed in the register. Teams on Splunk Enterprise or without DDSS should skip this step and use the export routes above.
Record counts, time ranges and checksums
Every export file or archive should be logged with its source index, the exact start and end times, the row or event count returned by Splunk, the file name and a checksum such as SHA-256 computed when the file is written. The log should be kept with the export register, not in the Splunk instance being retired. The check is a reconciliation pass: the stored checksums are recomputed after transfer, and the event counts are compared with a count query against the same time range in Splunk, where that query can still run. Any mismatch stops the step until the cause is found.
Restore a sample to test the thawed path
Archived DDSS data can be restored only to a Splunk Enterprise instance, not back into Splunk Cloud Platform. Restored data is placed in the thawed directory as bucket structures and does not count against indexing license volume. Teams should restore a representative sample into a test Splunk Enterprise instance, confirm that searches return the expected events, and compare counts with the records from the previous step. The check is a documented search that returns the same counts for the same time range. If the destination platform is not Splunk, this test still validates that the raw data is intact and readable.
Sign off with the receiving team
The receiving team, which may be the operations team running the new OpenSearch or Wazuh stack, reviews the export register, checksum log, reconciliation results and restore test. They confirm they can read the files in their own tooling and that the field mapping is understood. Compliance or legal owners confirm the retention obligations are met. The step closes when the signed register is stored with the archive. Only after this sign-off should anyone decide when Splunk data is deleted, because the sign-off is the evidence that the export is complete.
Questions buyers ask about the effort of a Splunk export
How long does a Splunk export take?
No supplied fact gives a duration, so the honest answer depends on three inputs: the volume of events, the retrieval method and the time range. A small saved search exported from Splunk Web can finish in one session, while a multi-year history pulled through the REST API or an SDK is a scripted job that runs over many hours or days. Before you plan a cutover date, run a test export of one representative index and one month of data, time it, and extrapolate. Confirm the expected throughput for your environment with Splunk and your own platform team, since search load, indexer capacity and network path all affect the result.
Can our own team export Splunk data without outside help?
Yes, for small and medium volumes, a team with Splunk administration experience can export results through Splunk Web or the CLI without specialist help. Splunk describes Splunk Web as suited to low-volume, on-demand exports and the CLI as the most stable method for medium on-demand exports. High-volume jobs run through the REST API or the Splunk SDKs, which means writing and maintaining scripts that handle paging, authentication, retries and file formats. Skills needed include SPL, Splunk role and capability setup, scripting and an understanding of how your indexes are organized. Confirm with Splunk which capabilities your account needs for each method.
What does the export need from our cloud and security teams?
The export touches several teams, and each has a checklist:
- Splunk administrators confirm the search, index and role permissions, and the retention settings that decide what is still in the indexes.
- Cloud teams prepare the destination, such as an Amazon S3 bucket, Google Cloud Storage bucket or Azure Blob Storage container, with encryption, lifecycle rules and network paths.
- Security teams review access to exported data, since raw logs often contain personal data and credentials that need the same controls as the source.
Agree on who approves the destination, where keys are held and how exported files are checked for completeness before the source is decommissioned.
What drives the cost of exporting Splunk data?
Four cost components drive the total, and each has a different payer:
- Staff time for scripting, testing and validating the export, paid by your organization or a partner under a written scope.
- Storage at the destination, which you pay to your cloud provider or storage vendor and which recurs for as long as you keep the archive.
- Compute and network transfer used by the export job, which depends on volume and where the data leaves.
- The restore environment, since archived data can be restored only to a Splunk Enterprise instance, which carries its own license and infrastructure cost.
Ask Splunk for current licensing details for any restore instance, and ask your cloud provider for its current storage and egress prices. Ask any partner for a quote that separates one-time work from recurring storage.
Can Dynamic Data Self Storage archive our expired Splunk data, and where can it be restored?
Dynamic Data Self Storage (DDSS) is available to Splunk Cloud Platform customers. It moves expired index data to a customer-owned Amazon S3 bucket, Google Cloud Storage bucket or Azure Blob Storage container, and it needs no license add-on. Three constraints matter for planning:
- The storage location must be in the same region as your Splunk Cloud Platform environment.
- DDSS keeps only the raw data journal from each bucket.
- Archived data can be restored only to a Splunk Enterprise instance, not back into Splunk Cloud Platform.
Confirm the region mapping and the restore path with Splunk before you choose a destination, because restored data lands in the thawed directory of a Splunk Enterprise instance.
Does restoring archived data count against our Splunk license?
Data restored from a DDSS archive into Splunk Enterprise is placed in the thawed directory as bucket structures and does not count against indexing license volume, according to Splunk's Splunk Cloud Platform admin manual. This matters when you plan a read-only investigation or an audit replay after the subscription ends. Confirm the current rule with Splunk for your license type, and confirm that the Splunk Enterprise instance you use for restores is licensed and supported for that purpose.
Can DeployOpen run the Splunk export for us?
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and it can scope export work as part of a migration. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope. DeployOpen does not publish a price list, so the cost depends on your volume, methods, destination and restore plan. Ask for the scope to state what is exported, how completeness is verified and who owns the archive afterward.
What to plan before the Splunk contract ends
The export methods and archive options only help if the plan around them is settled before the contract date. The cards below cover retention, contract scope, storage placement, restore capacity, cutover timing and regulated records, which together decide how much data you can take out and when.
Map retention and expiry by index
List every index, its retention period and the date its oldest data expires. Data that expires before the exit date may be gone before you export it, so export or archive those indexes first. Ask your Splunk account team which indexes hold regulated or audit-relevant events, since those usually need a separate export plan. Keep the inventory in a shared document that stays current until the last index is retired.
Confirm contract and version support
Ask Cisco or your Splunk account team in writing which export and archive options your contract and your Splunk Cloud Platform version include. Do not assume that a method documented for one deployment type applies to another. Record the answer, the version it applies to and the name of the person who confirmed it, because exit timelines often run past a renewal.
Decide DDSS region placement early
If you plan to use Dynamic Data Self Storage, the storage location must be in the same region as your Splunk Cloud Platform environment. Choose and provision the Amazon S3 bucket, Google Cloud Storage bucket or Azure Blob Storage container before the switch, and confirm access rights for the archive. Moving the archive to a different region later is a separate project, so settle the location before any data is archived.
Reserve capacity for restores
Archived DDSS data can be restored only into a Splunk Enterprise instance, not back into Splunk Cloud Platform. Plan that instance, its storage and its access before you rely on the archive. Restored data is placed in the thawed directory as bucket structures and does not count against indexing license volume, which should be confirmed for your license type. Test a restore of a sample bucket before the exit date.
Separate ingestion stop from archive verification
Set two dates: the day ingestion stops and the day archives are verified as complete and readable. Keep ingestion running until the exports and archives for the final period are checked against record counts and sample searches. Agree on a rollback window in which Splunk stays available, and confirm with your team how long that window must be before the contract ends.
Plan retention for regulated records
Regulatory and internal policies may require keeping security and audit logs for a defined period after the platform changes. Decide which record types must survive the exit, who owns the retention decision and where the records will be stored and searched. Have your compliance lead confirm the requirement with the relevant regulator or auditor, and make sure the archive format can still be read by the tools you will use after the move.
Where the exported data should land for a self-hosted stack
The destination depends on what the exported data is. Security telemetry such as authentication events, endpoint activity and alerts usually belongs in a platform that can correlate and alert on it, which points to Wazuh for detection content and agent-based sources, or to OpenSearch when you build your own analytics and dashboards. General application or infrastructure logs can often go straight to an OpenSearch cluster for search and retention, with no detection layer. Decide this per data set before you export anything, because the answer also sets the retention period, the access model and who on your team owns the content. The license terms matter for that decision and for the long term. OpenSearch is licensed under Apache 2.0 and has no paid edition described in its FAQ, so you can run the cluster without a license fee. Wazuh is licensed under GPLv2 with an OpenSSL linking exception, which carries obligations if you modify and distribute the software, but internal use does not trigger distribution. Ask your legal or procurement team to confirm how these terms apply to your deployment, and to check any other components, such as dashboards or plugins, that you add to the stack. Exported files are not the same as data a platform can use. Raw events need a parser or ingest pipeline to produce fields, CSV and JSON need a column or key mapping to match the target index, and timestamps, time zones and field names often need correcting. Treat re-ingestion and format mapping as separate work from the export itself, and test a sample of each data set against the target before loading the full history. The sibling topics on migrating from Splunk to Wazuh and migrating from Splunk to OpenSearch cover the wider ingestion and rule work.
How DeployOpen scopes and delivers a Splunk data exit
DeployOpen treats a Splunk data exit as a fixed-scope engagement inside your own infrastructure. We agree in writing which indexes, formats and retrieval methods are in scope, then build, document and hand over the export and archive path so your data stays under your control.
How we scope
- Inventory which indexes, sourcetypes and saved searches hold data you need to keep, and their retention periods
- Classify each dataset by volume and by whether it is a one-off pull or an automated recurring export
- Confirm the target storage, region and format with your legal, records and security owners before work starts
How we build
- Set up export jobs with the Splunk CLI for medium on-demand pulls and the REST API or SDKs for high-volume automated transfers
- For Splunk Cloud Platform, configure Dynamic Data Self Storage to a bucket or container you own in the same region
- Test restores into a Splunk Enterprise instance and check event counts and timestamps against the source
How we hand over
- Document each export method, command, credential scope and storage location in a runbook you keep
- Provide a reconciliation record showing event counts and time ranges per dataset for your audit file
- Walk your operations team through restore steps, including how archived data lands in the thawed directory
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing of the export path are available as a retainer
- Ask for the written scope to state which exports, restores and handover documents are included and excluded
