How to export your data from Splunk SOAR starts with playbooks, not everything
If a renewal, a licensing change or a data residency requirement is forcing you out of Splunk SOAR, start by listing what you actually need to take with you. Playbooks can be exported as .tgz archives, but assets, container and case history, and configuration do not travel the same way, so the export is only the first step. Splunk documents the export paths for playbooks, and this page covers those documented paths only, with the gaps stated plainly so you can plan for them.
Playbooks can be exported from the playbooks table, from the classic editor settings, or from the modern editor menu. The rule that matters most is that a playbook must be saved at least once, because the export downloads its latest saved version. Check every playbook in your inventory for unsaved draft changes before you start, and record which editor each one was built in. Import is stricter: Splunk documents that .tgz files import only into tenants running the same or a higher Splunk SOAR version with the same playbook editor, so a modern editor playbook cannot be imported into a classic editor environment. Confirm the version and editor of every target before you plan the order of the work.
Treat the exported archives as the input to a rewrite, not as a finished migration. Imported playbooks can lack action block configurations, and the import flow asks you to map missing asset configurations to existing assets before a playbook can run. Asset configurations, credentials and app connections therefore have to be recreated and mapped in the target platform, and the people who own each integration should confirm those mappings. Keep a dated inventory of playbooks, assets and exports so you can show what was moved, what was rebuilt and what was retired.
What can be exported from Splunk SOAR and how
This table lists the playbook export paths in Splunk SOAR, the file format they produce and the rules that apply when the file is reimported. Read it before a move to check which playbooks can travel, which version and editor they must match, and which parts need to be rebuilt by hand.
| Export path or rule | What it covers | What to check before reimport |
|---|---|---|
| Playbooks table | Exports playbooks listed in the playbooks table as .tgz playbook archives | Confirm each playbook has been saved at least once, since export downloads the latest saved version |
| Classic editor settings | Exports a playbook from the settings of the classic playbook editor | Target tenant must use the same playbook editor, because classic playbooks cannot be imported into modern editor environments |
| Modern editor menu | Exports a playbook from the modern editor menu as a .tgz archive | Target tenant must use the same playbook editor, because modern playbooks cannot be imported into classic editor environments |
| Saved-version rule | Export always downloads the latest saved version of a playbook | Unsaved edits are not included, so save and test each playbook before exporting it |
| Version rule on reimport | Imports only into tenants running the same or a higher Splunk SOAR version | Confirm the target platform version before moving any archive |
| Editor rule on reimport | Modern and classic editor playbooks cannot cross between environments | Inventory which editor each playbook uses and plan a rebuild for any mismatch |
| Action block configurations | Imported playbooks can arrive without some action block configurations | Review every action block after import and retest its behavior |
| Asset configurations | The import flow asks users to map missing asset configurations to existing assets | Prepare the target asset list and credentials, since the playbook cannot run until mapping is complete |
What does not come out with the playbook archive
A playbook export carries the workflow logic, but the environment around it stays behind. Asset configurations, credential owners and action block settings have to be recorded or rebuilt on the target side, so plan those items before the archive is downloaded.
Asset configurations need remapping
On import, Splunk SOAR asks users to map missing asset configurations to existing assets before the playbook can run. The playbook refers to assets by name, so the target system must already hold assets that the playbook can bind to. Before the move, export a written inventory of each asset name, its app, its endpoint and its settings. Check that each asset exists on the destination, then confirm the mapping in a test run before any production trigger is connected.
Action block configurations can be missing
Imported playbooks can arrive with action blocks that lack their configuration. The archive contains the flow, but the per-block settings may not survive the import, so a playbook can look complete and still fail on its first run. Open each imported playbook and review every action block, including inputs, target assets and conditions. Keep a record of the original settings from the source playbook so the rebuilt blocks can be compared line by line.
Credential owners must be recorded
Credentials are tied to the service accounts and app connections that Splunk SOAR holds, and they do not travel inside a playbook archive. Record which team owns each credential, which account it authenticates as, and which systems it reaches. Before the move, confirm with the owners who will issue replacement credentials on the destination, and record the rotation schedule so keys are not reused from the old environment.
Editor and version constraints
A playbook archive only imports into a tenant running the same or a higher Splunk SOAR version with the same playbook editor. Modern editor playbooks cannot be imported into a classic editor environment. Record the version and editor of the source system, and confirm that the destination matches before exporting. Playbooks that do not fit that combination will need a rebuild rather than a reimport.
Confirm other data types with Splunk
This page covers only the export paths documented for playbooks. Container history, case records, audit logs, custom functions and configuration data may need separate handling, and the documented route for each one should be confirmed with Splunk before planning begins. Ask which types have an export or migration path, which are supported only for a specific edition, and which must be recreated by hand. Record the answers in the migration plan.
Saved versions define what is exported
Export downloads the latest saved version of a playbook, so unsaved edits are not in the archive. Before exporting, open each playbook in the editor, save it at least once and confirm the saved version matches the logic you expect. Keep a list of the playbooks that were exported, with their saved versions, so the destination can be checked against that list.
Why version and editor rules decide the export order
Before you export anything from Splunk SOAR, confirm the target version and playbook editor of the environment that will receive the playbooks. Splunk documents that a .tgz playbook archive can only be imported into a tenant that runs the same or a higher Splunk SOAR version and the same playbook editor. A modern editor playbook cannot be imported into a classic editor environment, so an export made for the wrong target is a file you cannot use. Write down the source version, the target version, and the editor each playbook was built in, and treat that table as the first deliverable of the migration.
The classic playbook editor was deprecated in 2024, and that date changes the order of work. Playbooks built in the classic editor may need to stay on an environment that still runs that editor, or be rebuilt in the modern editor before they can move to a target that has no classic editor. Check the editor each playbook uses before you choose a destination, and ask Splunk for the current support position on classic editor environments, because the deprecation affects which targets remain valid. Export the playbooks you intend to keep in the editor they were built in, and record any that will need rebuilding as a separate work item.
Because export downloads only the latest saved version, check that every playbook you need is saved and tested in its final form before you start. The version and editor check tells you which archives will import cleanly, and the saved-version check tells you whether each archive contains the logic you expect. Keep both results in the same inventory so that a playbook that fails on import can be traced back to its editor, version or unsaved changes.
The export sequence and how to verify each step
This sequence produces a complete set of current playbook archives and a written record of asset and action configurations, so nothing is lost before a move away from Splunk SOAR. Each step ends with a check you can perform yourself.
Inventory every playbook and its editor type
Before exporting anything, the Splunk SOAR administrator lists every playbook in the playbooks table, noting its name, owner, status and whether it was built in the classic or modern editor. The editor type matters because Splunk documents that a .tgz archive from one editor cannot be imported into an environment running the other editor. Record the list in a spreadsheet or ticket. The step is done when every playbook you intend to keep has a row and an editor type, and the count matches what the table shows after filtering out drafts you have confirmed are obsolete.
Save each playbook to capture its latest version
Open each playbook in its editor and save it at least once, even if nothing changed. Splunk documents that export downloads the latest saved version, so an unsaved edit can leave the archive out of step with what your team believes is running. Check the version history or last-modified timestamp in the playbooks table after saving. The step is complete when each playbook shows a fresh save time that matches the date of your export, and any playbook that refuses to save is flagged for investigation before you continue.
Export each playbook as a tgz archive
Export each playbook from the playbooks table, from the classic editor settings or from the modern editor menu, depending on how it was built. Splunk documents that the output is a .tgz playbook archive. Name the files consistently, for example by playbook name and export date, and store them in a versioned location outside the Splunk SOAR server. The step is complete when you have one archive per inventoried playbook. Confirm that each file opens with a standard archive tool and that the file size is not zero.
Record asset and action configurations separately
The playbook archive does not carry the values that connect a playbook to a working system, so document each asset the playbooks use, including the app it belongs to, its target address, its non-secret settings and the action blocks that reference it. Splunk documents that imported playbooks can lack action block configurations and that users must map missing asset configurations to existing assets before a playbook can run. Credentials should be recorded by location in your secrets store, not copied into the document. The step is complete when every asset referenced by an archived playbook appears in your register with an owner.
Export supporting custom functions and app details
Collect the custom functions and Python code that your playbooks call, along with the list of installed apps and their versions. Splunk's migration documentation notes that custom code must be converted to Python 3 before a move to Splunk SOAR (Cloud), so confirm which functions are written for Python 2 or Python 3 and keep a copy of each source file. The step is complete when every custom function referenced by an archived playbook has a source copy on file and the app versions are listed. Check that the source files compile or parse in a Python 3 environment if you plan to move them.
Test the archives against an inventory check
Compare the archive set with the inventory from the first step. Each playbook should have one archive, the editor type should match your notes, and the save time should match the export date. Where possible, use a non-production Splunk SOAR tenant at the same or a higher version to confirm that a sample archive imports, since Splunk documents that imports require a matching or higher version and the same editor. The step is complete when the sample imports and the import flow lists the asset mappings you recorded earlier.
Verify the full export before deleting anything
Hold the original Splunk SOAR data until the export has been checked from a second location. Copy the archives, the asset register and the custom code to storage your team controls, then confirm that each file can be read after the copy. Keep the Splunk SOAR instance intact until the migration target has been validated and your retention obligations are confirmed with your compliance lead. The step is complete when the team signs off a checklist that shows every archive, configuration record and code file has been verified in the second location.
What the exported playbooks need before they run on Shuffle
A .tgz playbook archive is a Splunk SOAR format, and Shuffle does not import it directly. Each exported playbook has to be rebuilt as a Shuffle workflow, and every Splunk SOAR action it calls has to be matched to a Shuffle app. For integrations that Shuffle does not ship, you can build an app with the App Creator from an OpenAPI specification or write one in Python with the Shuffle app SDK. Shuffle apps run as versioned Docker containers, so the version you test is the version you deploy. Before you start, list every custom Python function in the archive, because each one needs a Shuffle app or a rewrite in a workflow step.
Plan the target environment before the rebuild. Shuffle's backend is licensed under AGPLv3, while its workflows, documentation, apps and app specifications are licensed under MIT, so confirm with your legal team how that split applies to any custom apps you publish or modify. On the infrastructure side, Shuffle supports Docker and Kubernetes, and its install guide states a minimum of 4 GB of RAM. The default Docker Compose setup is not a scalable build without changes, so decide early whether the first environment is a single test server or a design that will carry production load. Confirm current requirements in the install guide for the version you intend to deploy.
Use the migration page as the step-by-step path for mapping playbooks, apps and assets to Shuffle. This section only establishes what the exported files need before they can run. Confirm with the migration guide and with your own test environment which Splunk SOAR apps have a matching Shuffle app, which need a custom app, and which action parameters must be entered again as Shuffle app authentication. Treat that inventory as the input to your scope and testing plan, not as a finished migration.
What to plan before the Splunk SOAR contract ends
The export itself is the easy part. The decisions that cause trouble are made earlier: which deployment and editor you run, how long you can keep the old tenant reachable, and who owns the credentials behind every asset. The cards below cover what to settle before renewal or termination, and what to confirm with Splunk rather than assume.
Confirm version and playbook editor
Record the exact Splunk SOAR version and whether your playbooks were built in the classic or modern editor. Splunk imports .tgz archives only into tenants running the same or a higher version and the same editor, so a modern editor playbook cannot land in a classic environment. Inventory which editor each playbook uses before you choose a target, because that choice limits what can be reimported later.
Identify the deployment model
Determine whether you run Splunk SOAR (On-premises) or Splunk SOAR (Cloud). The on-premises path exports archives from your own servers, while the cloud path depends on what Splunk allows you to take out of its managed service. Splunk documents a migration path from on-premises to cloud, which requires converting custom code to Python 3 first. Confirm with Splunk which export routes are available for your exact deployment.
Plan the export window
Set a date by which every playbook is exported, and freeze edits to playbooks in that window. Export downloads only the latest saved version, so any unsaved or half-finished change is not captured. Ask Splunk how long the tenant stays readable after the contract ends, since that window sets how long you can re-export if something is missed.
Secure credentials and asset ownership
Imported playbooks can lack action block configurations, and the import flow asks you to map missing asset configurations to existing assets before a playbook can run. Assets carry credentials that do not travel with the playbook file. Record who owns each integration account, rotate or re-issue keys where needed, and keep a list of asset names and parameters so mapping can be completed in the target platform.
Decide retention of archives and cases
Decide which exported archives, case records, container history and audit notes must be kept, for how long, and in what store. Playbook archives are not the same as case history, so an export of playbooks alone does not preserve investigations. Confirm with Splunk which case and audit data it can return, in what format, and whether it is included in the contract or billed separately.
Set a parallel-run period
Run the old and new automation side by side for a fixed period before switching off the old tenant. During that period, compare outputs of each mapped playbook against known alerts and keep the Splunk instance reachable as a fallback. Agree the length of the overlap in writing with your own change board, because the contract itself may not guarantee access beyond its end date.
Confirm contract and data return terms
Read the agreement for data return, export assistance, notice periods and deletion obligations before assuming any of them. Ask Splunk to state in writing which exports it will support, the format of each, how long the data remains accessible, and when it is deleted after termination. Involve legal and procurement early, because these terms decide what you can do after the last invoice.
Questions buyers ask before exporting Splunk SOAR data
How much effort does a full Splunk SOAR export take?
The effort depends mostly on how many playbooks exist, which editor each one was built in, how much custom code sits behind them, and how many assets need to be recreated. Exporting the .tgz archives is the quick part. Reviewing each archive, confirming it matches the latest saved version and listing the assets and credentials it depends on takes longer. Ask your team to produce a playbook inventory with editor type, custom function use and asset references before estimating the work. No export duration is stated here because none was supplied for this page.
What drives the cost of exporting playbooks from Splunk SOAR?
Cost follows the number of playbooks, the mix of classic and modern editor playbooks, the amount of custom Python code and the number of assets to remap. Most of this is internal staff time, since exporting is done from the SOAR interface. Costs that recur are the infrastructure and licenses for whichever platform you move to. Ask any partner for a quote built from a written scope that lists those counts, and ask who performs the review of each exported archive.
Can our own team export Splunk SOAR playbooks without outside help?
Yes, a SOAR administrator with access to the playbooks table or the editor menu can export individual playbooks. The harder part is verifying them. Each playbook must be saved at least once before export, because the export downloads the latest saved version, so unsaved edits are lost. Teams without an administrator familiar with both editors, or without someone who can read the custom functions, usually need help in the review stage. Confirm internal capacity before deciding.
Who needs to take part in a Splunk SOAR export?
Three groups are usually involved. SOAR administrators run the exports, confirm saved versions and check the target environment. App owners or engineers who wrote custom functions confirm that the code still makes sense outside Splunk SOAR. Credential holders are needed to reconnect each asset in the new platform, because asset configurations are not carried over as working connections. Agree on these roles and on who signs off each playbook before the work starts.
Does a Splunk SOAR export include case history?
The playbook export covers playbook archives, which contain the workflow logic, not the case history. Confirm with Splunk documentation and your own SOAR instance what else you can retrieve for containers, cases and audit records before the move, and decide whether those records must be kept for investigation or compliance purposes. Plan a separate retention or archive step for them, and verify that your chosen target can hold or reference that history.
Why do imported playbooks fail until the assets are mapped again?
Imported playbooks can lack action block configurations, and the import flow asks users to map missing asset configurations to existing assets before the playbook can run. In practice, each playbook needs its assets rebuilt in the target platform, with credentials and API keys entered again by someone with the right access. Keep an asset register that lists each integration, its owner and the secret it uses, so the mapping does not stall the project.
How do playbook versions and editor types limit reimport?
Splunk SOAR imports .tgz playbook archives only into tenants that run the same or a higher Splunk SOAR version and the same playbook editor. Modern editor playbooks cannot be imported into classic editor environments. Check the version and editor of each source tenant and target tenant first, and plan any editor conversion as separate work. Your Splunk documentation and the vendor are the sources to confirm the current rules for your version.
When should we bring in an implementation partner for the export?
Consider a partner when the playbook count is high, custom code needs rewriting, several editor types exist, or the export has to be reconciled with a compliance evidence request. A fixed-scope engagement starts with a written scope listing the playbooks, assets, credential owners and deliverables, and DeployOpen provides a quote from that scope. Organizations with a small, well-documented set of playbooks may be able to manage the export internally.
How DeployOpen scopes and delivers a Splunk SOAR data export
DeployOpen treats a Splunk SOAR export as a scoped piece of migration work, not a file download. We agree in writing which playbooks, saved versions, asset mappings and target environment are covered, then deliver the export inventory and the rebuild plan with your team. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Inventory every playbook, its saved version and whether it uses the classic or modern editor.
- Record which assets, credentials and action block configurations each playbook depends on.
- Agree in writing the export format, target platform and the evidence your reviewers will need.
How we build
- Export playbooks from the playbooks table or editor menu after confirming each has a saved version.
- Map each asset configuration to its replacement credential or app authentication in the target platform.
- Test every exported playbook against a non-production copy before any cutover decision is made.
How we hand over
- Deliver an export register listing each playbook, its version, export date and mapping status.
- Document open gaps such as missing action block configurations or unsupported editor versions.
- Provide runbooks for asset remapping so your own engineers can repeat or audit the work.
How we support
- Offer ongoing support and upgrades as a retainer after handover, scoped in writing.
- Re-run export checks when the source Splunk SOAR version or editor changes during the project.
- Confirm with your team which environment, retention and access rules apply before any data leaves Splunk SOAR.
