Shuffle SOAR migration services

What a Shuffle migration involves

Moving automations onto Shuffle means rebuilding each one as a Shuffle workflow made of triggers and actions, where every action calls an app. The work is not a file copy. A cron job that runs a script, or a playbook in another SOAR, has to be translated into workflow steps, branches and app calls, and each external system it touches needs an app that Shuffle can run. Start by listing every automation, its trigger, the systems it reads from and writes to, and the credentials it uses today.

Some migrations are a direct port of logic: the same decision tree, the same API calls, reimplemented in workflow nodes. Others need a rebuild, because a script that loops over a folder or polls an API every few minutes may fit better as a webhook or scheduled trigger feeding a workflow. Where a vendor app does not exist, the team either writes one from an OpenAPI specification in the App Creator or in Python with the app SDK. Each custom app runs as a versioned Docker container, so plan who will own its versions and tests after cutover.

Triggers for the work are usually a SOAR contract that is ending, scripts that no longer scale with alert volume, or a decision to self-host. Self-hosting adds runtime decisions: the backend and OpenSearch run on your servers, and Orborus starts a worker and app containers for each execution. Confirm early which networks those containers must reach, since an app that cannot resolve an internal SIEM or directory will fail in ways that look like workflow bugs.

Most teams that have a small set of automations and in-house Docker and security engineering can do the migration themselves. Teams with many automations, several internal systems behind firewalls or a fixed cutover date often bring in a partner for the inventory and app work. Ask a prospective partner to name who builds, tests and hands over each workflow, and what your team must run afterward.

What the migration work includes

A typical migration to Shuffle moves each automation through the same sequence, from inventory to retirement of the old tooling. The cards below describe each work package and the written outputs to request.

Automation inventory

Every existing playbook, script, cron job and webhook is listed with its trigger, inputs, outputs, downstream systems, owner and run frequency. Scripts that run outside the SOAR tool are often missed, so the inventory should be built from the scheduler and server configuration as well as the platform's own export. Ask for the inventory as a signed-off document before any rebuild begins.

Mapping register

Each inventoried automation is mapped to a Shuffle workflow, an existing Shuffle app, or a custom app to be written from an OpenAPI specification or the Python SDK. Items with no equivalent are flagged for a decision by your team. The register records the target app and version for every step so gaps are visible before build.

Workflow rebuild and testing

Each mapped automation is rebuilt as a Shuffle workflow and tested against representative inputs, including failure paths such as timeouts and partial responses from target systems. Test evidence is kept per workflow, and changes after sign-off go through versioned revisions. Confirm who approves test results and who can accept a workflow into production.

Credential migration to the encrypted store

Credentials and API keys used by the old tooling are moved into Shuffle's app authentication store, where they are encrypted in OpenSearch with a key held in the SHUFFLE_ENCRYPTION_MODIFIER setting. Plan for the encryption secret to be generated, stored and backed up before any credential is entered, because losing or changing it breaks all saved app authentications. Replace shared accounts with least-privilege service accounts where the target system allows it.

Parallel running and cutover

The old and new automations run side by side for an agreed period, with outputs compared for each workflow before the old one is disabled. Cutover is done per automation, not in one event, so a faulty workflow can be paused without stopping the rest. Confirm the comparison criteria and the rollback steps in writing before parallel running starts.

Retirement record for the old tooling

Once cutover is accepted, scheduled jobs, service accounts, webhooks and hosts from the old tooling are removed or disabled and each removal is logged. The record shows what was retired, when, by whom and what replaced it, which supports later audits. Ask for the retirement record alongside the runbooks for operating the new Shuffle environment.

What drives migration cost and duration

Each row names a factor that changes the effort of moving automations to Shuffle, why it matters, and how to keep it under control.

Driver	Why it matters	How to keep it down
Number and complexity of automations	Each playbook needs rebuilding, testing and sign-off. Branching, loops, error handling and retries add build and test time more than step count alone.	Inventory every automation first, rank by business value and complexity, and retire dead or duplicate playbooks before any rebuild starts.
Number and type of connected tools	Every SIEM, EDR, ticketing system or directory service needs an app, credentials and a test path. Tools with rich vendor APIs are usually quicker to connect than tools reached through scripts.	List tools and their API access per playbook, then group playbooks by shared tools so each integration is built and tested once.
Code-based logic versus visual workflows	Logic held in Python or shell scripts must be redesigned as Shuffle workflows or apps, which takes more analysis than moving a visual playbook from another SOAR.	Document script behavior, inputs and outputs before rebuilding, and move pure data transforms into existing apps where possible.
Custom connectors where no Shuffle app exists	Tools without an app need an OpenAPI specification or a Python app built, versioned and tested in a container. This is often the largest single effort item.	Confirm the app catalog for each tool early, and check whether a tool's API is documented well enough to generate an app from its spec.
Number of environments	Development, test and production each need Orborus runtime locations, credentials and configuration. Keeping them aligned adds ongoing effort.	Limit environments to what the parallel-run plan needs, and manage configuration and app versions from one source.
Data and credential volume	Saved app credentials and API keys must be re-entered or migrated, and the encryption secret must be protected. Large case histories or stored artifacts add export and validation work.	Decide what history must move and what stays archived in the old system, and plan credential re-issue with least-privilege API keys.
Edition and app-run volume during parallel runs	Shuffle licensing uses app runs, which count actions that execute. Running old and new automations side by side raises execution counts during the overlap period.	Ask for a quote that models app runs during parallel running, and shorten the overlap by setting firm cutover dates per playbook.
Compliance evidence requirements	Auditors may expect records of approved changes, test results, access reviews and retained logs for the new automations. Gathering this evidence adds work to every rebuilt playbook.	Agree the evidence list before the build, keep test records and change approvals in the same workflow as each playbook, and confirm requirements with your assessor.

Migration phases and what each produces

The sequence moves automations from the source tooling into Shuffle in controlled stages, with a written output at each phase before the next one starts.

Inventory existing automations and dependencies
Your team and DeployOpen list every playbook, SOAR workflow, script and cron job, with its trigger, inputs, outputs, target systems and owner. Credentials and service accounts are recorded by name only. The step is done when the inventory is signed off by the process owners and every automation has a status: migrate, merge, retire or keep as is.
Prioritize and map each automation to Shuffle
Each automation is ranked by business impact and how often it runs, then mapped to a Shuffle workflow, an existing app or a custom app that still needs to be built. Gaps in integrations are listed. The output is a signed mapping document that names the target app for each external system and the runtime location each workflow will use.
Build the platform and place the runtime
The Shuffle deployment is built in the architecture you chose, whether single server with Docker Compose, Docker Swarm, a hybrid with a local Orborus, or Kubernetes with Helm. Secrets, the app credential encryption secret, TLS and access controls are set. Output: a documented environment with health checks passing and a record of where each Orborus node runs.
Rebuild workflows and test against controlled inputs
Workflows and custom apps are rebuilt from the mapping, using versioned definitions. Each one is tested with recorded or replayed inputs and compared with the output of the source automation. Output: a test report per workflow listing matched results, known differences and fixes, plus the app versions in use.
Run the old and new automations in parallel
Both the source automation and the Shuffle workflow run against live events for an agreed period, with Shuffle actions set to report rather than change state where the target system allows it. Output: a parallel-run log showing where outputs diverge, and a sign-off from the owners of each use case. Length depends on event volume and the risk of each use case, so confirm it in the written scope.
Cut over workflows to Shuffle
Triggers and schedules are switched from the source tooling to Shuffle one use case at a time, with a rollback path written for each. Output: a cutover record listing the switch time, the person who approved it, the rollback steps and the first verified executions in Shuffle.
Retire the source tooling
After a stable period agreed with your team, the old playbooks, scripts, cron jobs and their stored credentials are disabled, then removed, and the secrets are rotated or revoked. Output: a retirement record, updated runbooks and handover documentation for the Shuffle workflows and apps your team will maintain.

What to keep in-house and what to outsource

This table compares migration tasks teams usually keep in-house with tasks often outsourced, and lists the skills each side needs for a move to Shuffle SOAR.

Migration task	Usually in-house	Often outsourced
Defining expected outcomes	Business owners set which alerts, approvals and response steps must behave the same after cutover, and which can change.	Partner drafts a template of questions and turns the owners' answers into written acceptance criteria.
Inventory of existing automations	SOC leads confirm which scripts, cron jobs and playbooks are still used and who depends on them.	Partner interviews owners and reads scripts, schedules and tool configs to build the inventory, requiring Python, shell and cron knowledge.
Mapping old logic to Shuffle	Analysts review mapped decision points because only they know the intent behind each branch of the old process.	Engineers translate logic into Shuffle workflows, conditions and loops, which requires SOC process knowledge and Shuffle workflow design skills.
Building apps and integrations	Platform owners review API scopes and decide which systems each app may reach.	Engineers build apps from OpenAPI specifications in the App Creator or in Python with the Shuffle app SDK, and handle secrets safely.
Setting up the runtime	Infrastructure owners approve locations, network paths, backups and access to the encryption secret used for saved app credentials.	Engineers deploy the backend, frontend, OpenSearch and Orborus with Docker, and administer OpenSearch and Linux hosts.
Parallel-run monitoring	Analysts compare old and new outputs each day and record any gaps in outcomes.	Engineers instrument workflow executions, watch logs and failed app runs, and tune retries, timeouts and error handling.
Approving cutover and retirement	Business owners and security leadership sign off on cutover and decide when old tooling is switched off.	Partner prepares the cutover runbook, rollback steps and a list of old jobs to disable, and documents the result.

What goes wrong in Shuffle migrations

Most Shuffle migrations stall for reasons that have little to do with the platform itself. These are the failure modes we see most often when playbooks move from another SOAR, scripts or cron jobs, and how to prevent each one.

Automations copied without decision logic

Teams often recreate the visible actions of an old playbook but miss the branching, thresholds and exception handling that actually made it useful. Before building, export the old logic and document each decision point, including who approved it and why. Prevent this by reviewing each rebuilt workflow against the original decision tree with the analyst who owns it.

Credentials lost to the encryption secret

Shuffle encrypts saved app credentials and API keys in OpenSearch using the SHUFFLE_ENCRYPTION_MODIFIER secret, and the configuration docs warn that losing or changing it breaks every saved app authentication. Store the secret in your secrets manager before the first import, keep it identical across all backend nodes, and rehearse a restore. Confirm the procedure for rotation with your team before go-live.

Unexpected app-run counts in parallel runs

Shuffle licensing on paid tiers is based on app runs, meaning actions that actually execute, so running old and new automations side by side can raise volume faster than teams expect. Estimate run counts per playbook from the old system's alert history, then compare them against the license terms your organization holds. Ask your Shuffle representative to confirm how the current edition counts runs before you start parallel operation.

Missing links to internal systems

Scripts often reach internal SIEM, EDR, ticketing or directory services through network paths and service accounts that nobody documented. Shuffle workflows need the same reachability, and a runtime outside the private network cannot call those systems without a planned path. Inventory every endpoint each script touches, then confirm which runtime location can reach it and which service account each app will use.

Error paths never tested

Happy-path tests pass easily, but migrated workflows fail in production when an API times out, returns partial data or rejects a credential. Old scripts may have quietly retried or logged failures that nobody remembers adding. Test each error path deliberately, including expired tokens, empty responses and rate limits, and record the expected result for each one.

Retiring old tooling too early

Switching off cron jobs or the previous SOAR before new workflows have handled real cases removes the only working fallback. Define proof criteria for each playbook, such as matching outcomes over an agreed number of cases reviewed by analysts, and keep the old automation available until every criterion is met. Schedule retirement one playbook at a time, with a named owner signing off each step.

How the migration changes by starting point

Playbooks from a commercial SOAR rarely convert one to one, so the inventory starts with what the vendor lets you export and in what format. Each playbook is then rebuilt as a Shuffle workflow, with every vendor integration mapped to a Shuffle app or a custom app.

Inventory: list playbooks, triggers, connectors, credentials and the case data they write to.
Rebuild: redesign each playbook as a workflow and test it against non-production systems.
Cutover: run both platforms in parallel for a period agreed with your SOC before disabling the old playbooks.
Confirm with the vendor: export rights, data retention obligations and the contract end date.
Confirm in your environment: which connectors your analysts still rely on after the switch.

What you need to provide

Before migration work starts, you provide the material that defines what the old automation actually does. That means read access to the existing playbooks, scripts and cron schedules, including the crontab entries and any scheduler configuration, so the inventory reflects what runs in production rather than what the documentation says. Each automation also needs a named owner who can answer questions about its intent, approve its migrated behavior and decide whether it is still needed.

For every connected tool, provide read access to its configuration and API credentials scoped to the least privilege the migrated workflows will need. Credentials stay in your secrets management process, and the team should confirm which service accounts exist, which permissions they hold and who rotates them. Also decide where the Shuffle deployment will run (single server with Docker Compose, Swarm, Kubernetes, or a hybrid with a local Orborus), because app containers and runtime placement depend on that choice and on which internal systems the workflows must reach.

Provide an approved test environment that can reach non-production instances of your SIEM, ticketing and identity systems, so parallel runs can be checked without touching live data. Book change windows for cutover in advance, and agree the cutover rollback criteria with the operations team. Finally, agree a written definition of done for each migrated automation: the inputs, expected outputs, error handling and the parallel-run period that must pass before the old job is switched off.

Retirement sign-off: the automation owner confirms behavior parity, the security or SOC lead confirms that detection and response coverage is unchanged, and the platform owner approves removal of the old cron job, script or SOAR content. Ask who holds the final decision on each retirement and keep that record with the migration plan, because retired jobs are hard to reconstruct later.

Questions about migrating to Shuffle

What drives the cost and timeline of moving playbooks to Shuffle?

The main drivers are the number of automations to inventory, how many are scripts or cron jobs versus workflows in another SOAR, how many tool integrations each one needs, and how much testing you require before retiring the old tooling. One-time costs cover inventory, rebuilding workflows and custom apps, testing and cutover. Recurring costs cover runtime hosting, OpenSearch, app-run licensing where it applies, and upkeep. Ask any partner for a written scope that lists each automation, its integrations, and the testing and parallel-run period, so the quote can be compared line by line.

Can our own engineers migrate playbooks to Shuffle without a partner?

Yes, if your team already understands the automations, has capacity to rebuild them, and can test against live tools. Shuffle documents its platform publicly and all features are available in the open-source edition, so the constraints are skills and time rather than licensing. Teams most often struggle with undocumented cron jobs, mapping error handling and retries, building custom apps from OpenAPI specifications or Python, and running parallel tests without disrupting analysts. A partner adds a fixed scope, a second set of hands, and a documented handover.

Do parallel runs in Shuffle increase our licensing cost?

They can, because Shuffle prices on app runs, which are actions that actually execute in a workflow. Running old and new automations side by side adds executions. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. To control the cost, scope parallel workflows to read-only or test actions where possible, measure current action volume from your existing logs before the parallel phase, and set a clear end date for the overlap. Confirm current terms and how your volume maps to them with Shuffle before you commit.

Does the AGPL-3.0 license affect custom apps we build for Shuffle?

It depends on how the code is distributed, modified and offered to others, so confirm the position with your counsel before building. Shuffle's code is licensed under AGPL-3.0 according to its GitHub repository and open-source article. Counsel should review internal use of an unmodified platform, any changes you make to Shuffle itself, whether you provide the software to third parties or over a network, and how a custom app that runs in its own container is treated. Ask any partner which components they would deliver separately and which parts they would modify.

How are saved credentials moved safely during a Shuffle migration?

Do not export credentials from the old tool in plain text. Re-enter or rotate each one in Shuffle, using least-privilege API keys scoped to the actions each workflow needs. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. The documentation warns that losing or changing this secret breaks every saved app authentication, so store it in your secrets manager, back it up with your database, record its owner, and test each connection after cutover.

How do we compare partner quotes for a Shuffle migration?

Compare the written scope first, then the assumptions behind the effort. Check the number of automations covered, which integrations and custom apps are included, whether testing and parallel runs are priced, and who operates the runtime after handover. Ask for one-time and recurring components separately, including infrastructure and support. Ask how app-run volume was estimated and what changes if actual volume is higher. A quote that cannot list the automations it covers is difficult to compare with another, so request the same inventory baseline from every bidder.

How DeployOpen runs Shuffle migrations

DeployOpen scopes each Migration to Shuffle SOAR project in writing before work starts, then rebuilds, tests and hands over the automations in your own infrastructure. Engagements are fixed-scope, and ongoing support is available as a retainer.

How we scope

The written scope lists each source playbook, script or cron job to be inventoried and its owner named.
Scope states which automations are rebuilt as Shuffle workflows and which need custom apps or integrations.
Scope records the runtime locations, such as on-premises Orborus nodes, where migrated workflows will execute.

How we build

Each inventoried automation is rebuilt as a workflow, with its inputs, triggers and outputs mapped from the original.
Saved app credentials are stored under the Shuffle encryption secret, with the secret recorded in your own secrets process.
Rebuilt workflows run in parallel with the legacy tooling so outputs can be compared before any cutover is approved.

How we hand over

Deliverables include the workflow inventory, the parallel-run comparison results and the documentation of each rebuilt workflow.
Runbooks describe how your team updates apps, rotates credentials and back up the OpenSearch data store.
Retirement steps for the old SOAR, scripts and cron jobs are written down, with the decommission sequence agreed in advance.

How we support

Ongoing support, upgrades and testing of migrated workflows are available as a retainer after handover.
Support can cover keeping Shuffle images on supported versions and updating apps when the Shuffle release changes.
Ask in the quote which support items, response expectations and upgrade work are included in any retainer.

Migration to Shuffle SOAR