Migrate from Google SecOps SOAR to Shuffle

Which Google SecOps SOAR capabilities map cleanly to Shuffle

This table maps each main Google SecOps SOAR capability to its closest Shuffle equivalent and marks it as clean, needs rework or gap. Read the status column first, then the notes on what your team must rebuild. Case management and any features that depended on the bundled SIEM should be confirmed against current Shuffle documentation before you commit to a cutover plan.

How the migration sequence runs from inventory to decommission

The sequence moves Google SecOps SOAR automation to Shuffle in controlled stages, so each stage produces evidence that the next one can rely on before any alert source or playbook stops running in the old system.

1. Inventory playbooks, blocks, connectors and remote agents

   The SOAR owner and the platform engineer list every playbook, block, connector, job and remote agent in Google SecOps SOAR, along with the alert sources and the internal systems each one touches. Mark which items run in production, which are scheduled, and which are no longer used. The output is a single register with one row per item, an owner, a target Shuffle workflow or app, and a status. The step is done when the register has been reviewed by the SOC lead and every production item has a named owner.

2. Export definitions and map integrations to Shuffle apps

   Export playbook and block definitions using the ZIP export or GitSync, following the export steps for Google SecOps SOAR, and store them in a version-controlled repository. For each connector, check whether Shuffle already ships a premade app for that tool or whether the App Creator must build one from an OpenAPI specification, which is the usual route for internal systems. Record credential requirements separately, since saved authentications will need to be created again in Shuffle. The output is an exported archive and a mapping table from each Google connector to a Shuffle app or a planned custom app.

3. Build and test a pilot workflow on a sized instance

   The platform team installs Shuffle on a server that meets the install guide's minimum of 4 GB of RAM, rather than running the default Docker Compose setup as production, and sets the encryption secret before saving any credentials. The team rebuilds one low-risk playbook as a Shuffle workflow, runs it against test alerts, and compares the actions taken with the original run. The output is a documented pilot with recorded results, a list of differences, and a decision on whether the design needs a scalable architecture before production use.

4. Rebuild production workflows and run in parallel

   Rebuild the remaining priority workflows in Shuffle, and point a copy of the alert flow at the new instance while Google SecOps SOAR continues to receive and act on every alert. Compare case outcomes, enrichment results and approval steps for each workflow over a period the SOC lead agrees in writing. Confirm that app runs are counted as expected under the pricing model, since only executed actions are metered. The output is a parallel-run log showing matching outcomes, with each gap either fixed or accepted by the owner.

5. Repoint alert ingestion from the SIEM

   Change the alert and event sources so that new alerts reach Shuffle directly, either by reconfiguring the SIEM forwarding or by adding Shuffle triggers for each source. Confirm that the SIEM still delivers its own detections and that the handoff does not drop or duplicate alerts. Keep the Google SecOps SOAR feed disabled only after the new path has been tested end to end. The output is a signed-off ingestion diagram and a test record that every source produces a Shuffle execution with the expected fields.

6. Cut over and confirm operations

   Switch production response to Shuffle on an agreed date, with a named rollback owner and a written rollback procedure that re-enables the Google SecOps SOAR feeds. Watch execution health, failed actions and analyst feedback during the first operating cycle, and fix workflow defects as they appear. The output is a cutover record signed by the SOC lead, a list of resolved issues, and confirmation that analysts work from Shuffle cases for new alerts.

7. Decommission remote agents and retire the old platform

   Once the rollback window has closed, stop and remove the Google SecOps SOAR remote agents from internal networks, revoke the service accounts and API keys they used, and disable the old playbooks. Retain the exported archives and the case records that your retention policy requires, and confirm with Google what remains in the tenant after SOAR is turned off, since the SIEM may still be in use. The output is a decommission checklist with removed agents, revoked credentials and an archive location, approved by the security owner.

Which data and integrations to export, rebuild or retire

Each card covers one part of the move: what leaves Google SecOps SOAR as files, what has to be rebuilt by hand in Shuffle, and what can be switched off. Read them in order, because the exports carry the automation logic but not the history or the secrets that connect it to your tools.

How Shuffle's architecture changes where automation runs

How the migration differs by team size and starting point

What usually goes wrong when moving SOAR to Shuffle

Most failed SOAR migrations come from a handful of predictable gaps: secrets, integrations, cutover timing, single points of failure and assumptions about data. Each card below names one of these risks and the check that prevents it before production traffic moves.

What drives the cost and duration of the move

This table lists the components that set the cost and length of a move from Google SecOps SOAR to self-hosted Shuffle, who is paid for each, and whether it is one-time or recurring. Use it to build a written scope, since most of the effort sits in playbook rebuilding and integration work rather than in the software itself.

Questions buyers ask before moving off Google SecOps SOAR

What your team owns after the cutover

Where to confirm the export and deployment details

This sequence sets out the documents and checks to complete before scoping a move from Google SecOps SOAR to Shuffle, so the export method, deployment design and app coverage are confirmed against current sources rather than assumed. The output is a written list of open questions and the sources that answer them.

1. Check the current Shuffle release and tags

   Your platform or security engineering lead reviews the Shuffle releases page on GitHub to identify the current stable version and the Docker tags the project recommends for production. The Shuffle configuration documentation explains that the latest tag is the recommended choice for stable releases and the nightly tag is for experimental changes, so a pilot should not run on nightly without a clear reason. Record the version you intend to test, the tag you will pin, and the date you checked. You know this step is complete when the pinned version is written into the migration scope document.

2. Read the Shuffle architecture and configuration docs

   Your solution architect reads the Shuffle architecture documentation and the configuration documentation together. The architecture document covers four deployment models, including single-server Docker Compose, Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus, and Kubernetes with Helm charts. The configuration document covers high availability guidance, OpenSearch clustering, and the SHUFFLE_ENCRYPTION_MODIFIER secret that protects saved app credentials. Note which model fits your network boundary and which secrets must be backed up before any credential is entered. The step is complete when the chosen deployment model and the encryption key custody process are documented.

3. Confirm the Google SecOps export path with Google

   Your SOAR administrator and the Google Security Operations account team confirm how playbooks, blocks, connectors and jobs can be exported today, including ZIP export and GitSync to Git. Ask Google to confirm in writing what its export formats contain, what they omit (for example, case history and environment-specific values), and whether Google supports importing those files into unrelated systems. Google's own export documentation is the starting point, but the export behavior must be verified against your tenant before you rely on it. You know this step is complete when you hold a written answer for each question and a test export from a non-production environment has been reviewed.

4. Verify app coverage against your integration list

   Your security engineers list every Google SecOps integration and connector used by production playbooks, then check each one against the Shuffle apps catalog and the app creator. Shuffle builds apps from OpenAPI specifications or from Python using its app SDK, so an OpenAPI-described tool is a candidate for the app creator while a bespoke integration may need a custom app. Mark each integration as available, buildable, or requiring custom development, and confirm the status against the Shuffle apps documentation and the current release. Do not assume an app is present because a similar product is listed. The step is complete when every integration has a status and an owner.

5. Confirm alert ingestion and SIEM dependencies

   Your SIEM engineer confirms which alert sources currently reach Google SecOps SOAR through the bundled SIEM and which of them must be repointed to Shuffle. Because SOAR is not bundled with the SIEM in a self-hosted design, you need written confirmation of the ingestion route, the webhook or API method each source will use, and whether the SIEM remains in Google. Verify the Shuffle trigger options against the current documentation rather than relying on memory. The step is complete when each alert source has a named destination, a trigger type, and a test plan.

6. Confirm remote agent replacement and network access

   Your network and infrastructure team lists every remote agent or Publisher proxy path used today and decides how each internal system will be reached from a self-hosted Shuffle deployment. The hybrid model in the Shuffle architecture documentation needs no inbound firewall ports for a local Orborus, which is relevant to the decision, but your team should confirm the outbound and internal connectivity each app requires. Record which agent functions are no longer needed and which must be re-created through apps. The step is complete when the connectivity matrix is approved by the network owner.

7. Request written scope and a quote

   Your procurement or platform lead collects the answers from the previous steps and asks DeployOpen, or any other implementation partner, for a fixed-scope proposal. The written scope should name the Shuffle version and deployment model, the export and rebuild method, the integrations in scope, the testing and cutover plan, and the backup and key custody process. Ask which items are one-time and which recur, such as upgrades and support retainers. DeployOpen does not publish a price list, so the quote follows from the agreed scope. The step is complete when the scope, deliverables and timeline are signed off in writing before work starts.