Export playbooks from Google SecOps SOAR

How do you export playbooks from Google SecOps SOAR without losing automation logic?

Renewals, price changes and exit decisions all raise the same question: which automation logic has to leave Google SecOps SOAR, and in what form? Playbook definitions, blocks, connectors and jobs can be exported as ZIP files or pushed to a Git repository with GitSync, so the automation itself can be taken out of the platform. Case history and operational data sit outside that set and need their own export plan. Before you rely on either method, confirm the current export options, file contents and GitSync setup in Google's documentation for your SecOps tenant, because product behavior changes between releases.

Start with an inventory of every playbook, block, connector and job. Mark which ones run on live cases, which are disabled, and which depend on custom Python integrations or environment-specific values such as hostnames and service accounts. Then confirm with Google whether a ZIP export includes integration configuration, how credentials are referenced, and whether a GitSync repository holds the same objects as a ZIP and how changes are versioned. Assign a named owner for this review, keep dated copies of every export in storage your team controls, and restrict access to them. This review takes analyst and engineering time before any replacement platform is chosen.

Treat these exports as a copy of automation definitions, not of history. Expect case records, case comments, attachments and audit records to remain in Google SecOps unless Google provides a separate export for them. Confirm what is retained, for how long, and whether your investigations or regulators need that history after the cutover. On importing, check what Google's documentation says about loading playbook files into systems other than Google SecOps. Plan for rebuilding logic in the target platform, such as Shuffle or Tracecat, since the sibling migration pages cover that translation work. Keep the exports and GitSync history until the new workflows have been verified.

What you can export from Google SecOps SOAR and how

This table lists what you can take out of Google SecOps SOAR before a move, by data type, export method, format and limits. Where the format or limit is not confirmed in Google's documentation, the cell says to confirm it with Google, so check each row against your own tenant before you plan cutover. The main takeaway: exported files describe automation logic only and do not carry case history or execution history, so plan separate retention for those records.

Data type	Export method	Format and limits	Use in migration
Playbook definitions	Export each playbook as a ZIP file from the playbook menu, confirm exact menu path with Google	ZIP archive. Size and item limits: confirm with Google	Source logic to rebuild as Shuffle workflows or Tracecat workflows
Blocks	Export reusable blocks alongside the playbooks that call them, confirm method with Google	Confirm format and dependencies with Google	Map each reusable step to a Shuffle app action or a Tracecat action
Connectors	Export connector definitions, confirm which items Google includes in the export	Confirm format with Google. Confirm whether connector code depends on Google's remote agents	Identify each integration that needs a replacement app or custom action
Jobs	Confirm whether scheduled job definitions can be exported directly	Confirm format and schedule fields with Google	Recreate scheduled runs as schedules or triggers in the target platform
GitSync pushes	Push playbooks, blocks, connectors and jobs to a Git repository you control	Files stored in Git, with version history from commits. Confirm supported content with Google	A versioned copy you own, and a source Tracecat can read for Git-synced custom actions
Case history and execution logs	Not part of these exports	Not included in exported playbook or Git files. Confirm retention options with Google	Keep records from your SIEM or a separate archive before you decommission the SOAR

What a playbook export contains and what it depends on

A playbook export records the steps of an automation, the order and conditions between them, and the references each step makes to integrations, blocks and connectors. It does not carry the software behind those references. Before you export anything, build a dependency inventory for every playbook: list each integration action, block and connector it calls, note whether the item is a Google-provided integration or a custom one, and record the instance or account it authenticates against. A playbook that looks self-contained in the editor may depend on several integrations, and the export file shows only the names of those dependencies, not how they work.

Custom Python integrations and their credentials are managed separately from playbook definitions, so a playbook file alone is not a complete copy of your automation. The integration code, its parameters and the secrets used to reach each system may sit in different places in the product. Confirm with Google, in writing, which of these travel in a ZIP export, which move through a GitSync push, and which must be recreated by hand. Ask specifically how stored credentials are handled: whether they are excluded, masked or exported, and who in your organization will re-enter them. Treat any item that does not appear in both export paths as a separate work item.

Every dependency you inventory needs an equivalent on the target platform before a playbook can run there. In Shuffle, that usually means workflows built from apps, and in Tracecat, workflows that call prebuilt connectors or custom actions. Some integrations will have a direct match, others will need to be written from an OpenAPI specification or a Python SDK, and some may no longer be needed. Record each gap now, with an owner who decides whether to build, configure or retire it. The Shuffle apps documentation describes how those apps are built, and the migration pages walk through the mapping itself.

What does not export with playbooks, and how to handle each item

A playbook export carries workflow logic, not the operational state around it. The six items below are the ones teams most often assume will come along, and each needs its own plan before cutover.

Case history and case data

Cases, comments, attachments, and the timeline of analyst actions are stored as case data, not as playbook definitions, so a playbook export does not carry them. Before you plan a move, confirm with Google which export or API routes are documented for case data in your tenant and what format they return. If you need to keep closed cases searchable, archive them in a separate store with a retention owner. Decide whether open cases finish in Google SecOps or get reopened in the target platform.

Alert and event history

Raw alerts and the events attached to them remain in the SIEM and the SOAR case layer, so exporting playbooks leaves your detection history behind. Investigations often depend on that history, especially for repeat activity or a retrospective review. Confirm which alert and event exports Google documents and their retention limits in your contract. Plan a separate archive for records you must keep for audit or legal reasons, and document where each record lives after the move.

SIEM detections and rules that feed the SOAR

Playbooks trigger on alerts, but the detection rules that create those alerts belong to the SIEM side of Google Security Operations. Moving the SOAR does not move the rules, so alerts may stop arriving at the new platform unless you repoint ingestion. List every playbook trigger, map it to its source rule, and confirm which rule definitions Google documents for export. Keep the SIEM running until the new ingestion path has been tested end to end.

Integration credentials and secrets

API keys, service account tokens, and passwords configured for integrations are stored as secured parameters, and exports do not reliably carry their values. Treat every integration as needing new credentials in the target platform. Create them in your secrets manager, scope each one to the minimum access the playbook uses, and record who approves each rotation. Confirm with Google whether any credential values are included in any export format before you assume they are, and delete any copies you find in Git or ZIP archives.

Users, roles and access settings

Analyst accounts, role assignments, case permissions, and environment or group access are administrative settings, so they stay in Google SecOps. Playbooks may also reference a particular owner or approver, which breaks when that person is not in the new system. Build an access matrix from your current roles, map each one to the target platform's permission model, and confirm with your identity provider how single sign-on will apply. Review the matrix with the security team before any analyst logs in.

Dashboards and reports

Dashboards, scheduled reports, and the views analysts use to track queue health are built in the Google SecOps interface and are not part of a playbook export. Management and compliance reports often depend on them, so losing them can create a reporting gap during the move. Export the report definitions you can get through documented routes, screenshot or record the current metrics for the audit trail, and rebuild the essential views in the target platform's dashboards. Confirm with Google which of these can be exported.

Choose an export path by where the automation is going

Choose this path when the team wants playbooks, blocks, connectors and jobs held in a Git repository with history, review and a named owner for each change. GitSync pushes the definitions out of Google SecOps SOAR, so the repository becomes a working copy you can diff, review and test before migration. It moves definitions only, so the operational state around them still needs its own plan.

Repository ownership: Decide who creates the repository, which branch holds the migrated content and who approves changes before anything is pushed.
Object coverage: Confirm with Google's current GitSync documentation which object types are included in your version and how each one is stored in the repository.
Secrets and instance values: Check whether credentials or environment-specific values end up in the files, and move them to your secrets manager before the repository is shared.
Access control: Limit who can read the repository, since playbook logic often reveals detection and response procedures.

After the push, compare the object counts in the repository with the inventory in the SOAR console and open a sample of each object type to confirm it is complete and readable outside Google.

The sequence for a complete playbook export, step by step

This sequence turns the SOAR console into a set of exported files, a Git history and a signed inventory that a migration team can check against the source. Each step closes with a check, so the team knows the export is complete before any playbook is rebuilt on another platform.

Inventory every playbook, block, connector and job
An administrator with access to Google Security Operations lists every playbook, block, connector and scheduled job in the SOAR console, recording each item's name, status and owner. Ask your Google account team to confirm which item types the export covers, so the inventory matches what the export can carry. The step is complete when the count for each category matches what the console shows, and the list is saved in a location outside the SOAR environment.
Record integrations and credentials each playbook uses
For each playbook, note every integration, connector and account it calls, including any hardcoded values inside scripts or custom blocks. Confirm whether credentials travel in the export, and plan to recreate them in the target system either way. The step is complete when every playbook row lists its dependencies and each dependency has a named owner who can supply a replacement credential.
Freeze changes during the export
Ask SOAR administrators and content authors to stop editing playbooks, blocks and connectors until the export finishes, and announce the freeze to everyone who maintains content. Review the change history for edits made after the freeze starts, so the export reflects one version of each item. The step is complete when the change history shows no edits after the freeze start time and the team confirms in writing that the freeze is in effect.
Export ZIP files and configure GitSync
Export each playbook as a ZIP file, and export the custom content bundle, using the export functions in the console. Confirm the exact menu path with Google documentation before the team starts. Then configure GitSync to push playbooks, blocks, connectors and jobs to a repository hosted on infrastructure you manage. The step is complete when each ZIP file opens, the repository holds a commit for each content category, and the commit identifiers are recorded in the inventory.
Store copies in a second location
Copy the ZIP files and a mirror of the Git repository to a second location that your organization controls, such as an encrypted object store in your own cloud account or an on-premises file share. Limit access to the people who already read the production playbooks. The step is complete when a checksum comparison between the primary and second copies matches for every file.
Record file names, versions and counts
Write a manifest that lists each file name, the version or timestamp of its source item, its content category and the total count per category. Compare the manifest with the inventory from the first step, noting any item that was exported but is not in the inventory, or is in the inventory but missing from the export. The step is complete when the manifest totals equal the inventory totals and every discrepancy has a written explanation.
Confirm the export opens in a review tool
Open a sample of ZIP files and the Git repository in a plain-text or JSON review tool, and check that each sampled playbook's steps, conditions and integration references are readable without the SOAR console. Check Google's documentation on importing exported content into other systems, because that guidance sets what the team can expect from the files. The step is complete when every sampled playbook parses cleanly and a reviewer has signed the sample list.
Sign off the inventory against the source
A second reviewer compares the signed manifest with the live SOAR console, confirms that each item and version matches, and records what the export leaves out, such as case history, case data and remote agent configuration. Move those exclusions into a separate plan with an owner. The step is complete when both reviewers sign the inventory, the exclusions list is attached to it, and the change freeze ends.

How to verify the export before you rely on it

Treat the ZIP files and GitSync output as a candidate set, not a finished migration. Start by comparing the playbook inventory you built from the Google SecOps SOAR interface against the list of files you actually exported. Every playbook, block and connector that a live case depends on should appear in the export, and any that do not should be explained, not assumed. Record which playbooks are triggered by which alert sources and which are called as sub-playbooks, because a missing child playbook can break a parent that exported cleanly. Then go through each referenced integration and confirm that it has a documented replacement on the target platform, whether that is a Shuffle app built with the App Creator from an OpenAPI specification, an app written with the Shuffle app SDK, or a custom action in Tracecat. Where no replacement exists, mark the step as blocked before cutover begins.

Next, review the exported logic with the people who own each playbook. An export carries the steps, conditions and variables, but it does not tell you why a branch exists, which fallback is relied on during an outage, or which manual approval a case analyst expects. Ask owners to walk through the decision points and sign off on the intended behavior, and record their comments next to the playbook name. Then run the logic against a test target in a non-production environment, but only where doing so is safe: use sandbox tenants, disposable hosts and test mailboxes, and disable any action that would change production identities, block traffic or close real tickets. Confirm with your security and change teams which actions are permitted in test before anyone runs them.

A successful file export does not prove the automation will behave the same on another platform. Execution order, error handling, variable scoping, timeouts and the way each integration authenticates can differ, and none of that is fully captured in a definition file. Case history, attachments, analyst notes and the audit trail of past runs also stay behind in the source system, so keep Google SecOps SOAR available, with its licenses and access for the responsible roles, until verification is complete and you have confirmed which historical records you need to retain. Ask your vendor and your own environment team to confirm what each export format includes and excludes before you decide that the source can be switched off.

What to plan before the Google SecOps contract renewal or termination date

The export is only one step in leaving Google SecOps SOAR. The cards below cover the contract dates, data access and internal decisions that determine how much time you have to move automation safely. Confirm every date and period in your written contract or with your reseller, not from this page.

Confirm notice period and access end date

Check the notice period for renewal or termination and the exact date your access to the SOAR console ends. If you bought through a reseller, confirm whether the reseller or Google controls that date. Write down both dates and the owner of each, because an export started late can run into the cutoff.

Schedule the full export early

Plan the full export of playbooks, blocks, connectors and jobs well before the access end date, not on the final day. Use the ZIP export for each playbook and, if your team uses GitSync, confirm the repository push is current. Keep a dated copy of each export file so you can compare it with the target system later.

Confirm read access and retention after termination

Ask Google or your reseller how long read access and data retention last after the contract ends, and what format case history can be retrieved in. Playbook exports do not carry case history, so any cases you need for audit or investigation reference must be pulled out while access still exists.

Plan a parallel run on the target platform

Run the rebuilt automation on the target platform alongside Google SecOps for a defined period before cutover. Compare outputs for the same alert types and confirm each connector action completes. Keep the source platform live until the parallel run passes, which means the contract date needs to leave room for it.

Assign an owner to each playbook

Before the move, name an owner for every playbook and block, including who approves changes and who responds when an automation fails. Many exported playbooks reflect decisions made by people who have left the team, so ownership must be decided by you, not inherited from the export file.

Budget internal review time

Reviewing exported playbooks takes engineering and SOC time that the export tool does not provide. Estimate the hours with your security engineers and playbook owners, and ask your implementation partner for a written scope that covers review, rebuild and testing. Treat this as one-time effort that recurs only when playbooks change.

Common questions about exporting playbooks from Google SecOps SOAR

Can our own team export Google SecOps playbooks without outside help?

Often yes, but the answer depends on who on your team has administrator access to Google SecOps, who can read and check the exported files, and who can run the Git repository that receives them. Teams with a few simple playbooks and an engineer who understands both the source and target tools usually handle the export in-house. Teams with many playbooks, custom integrations or strict change control tend to bring in outside help for the mapping and review work. DeployOpen plans and implements these engagements under a fixed scope agreed in writing before work starts, so the scope can be sized to what your team wants to keep. Confirm role requirements for export and GitSync with Google's documentation before you plan the work.

What makes the playbook export effort grow or shrink?

Four factors drive most of the effort:

The number of playbooks and how many steps each one contains.
The number of custom integrations and blocks, since each one needs an owner and a decision about its target equivalent.
The GitSync setup, including repository structure, branch rules and who approves changes.
Reviewer time, because someone must confirm that each exported playbook still does what the security team expects.

Playbooks that depend on environment-specific values, such as hostnames, queue names or case field mappings, add review work because those values must be found and replaced. A quote from DeployOpen follows from a written scope that counts these items, so ask for each factor to be listed separately.

How long does the export take, and what sets the timeline?

The timeline is set by the same factors that set the effort: the count of playbooks, the number of custom integrations, how quickly the GitSync repository is approved, and how fast reviewers can sign off. Waiting on access, approvals and review usually takes longer than the export itself. Your team can shorten the schedule by naming owners early, keeping a current inventory of playbooks and integrations, and booking reviewer time in advance. DeployOpen does not publish a fixed duration. Timelines are agreed in the written scope, so ask for a milestone plan that shows which steps depend on your team's decisions.

Can Google SecOps playbook exports import directly into Shuffle or Tracecat?

Plan on a translation step rather than a direct import. Shuffle workflows and Tracecat workflows are built in their own formats, and each target platform has its own way of defining integrations: Shuffle builds apps from OpenAPI specifications or from Python code using its app SDK, and Tracecat runs custom actions synced from Git. Read Google's documentation on the export format and on any statements about importing into other products, and confirm what the files contain before you decide on the approach. The exported files still serve as the reference for each step's logic, which helps the rebuild, but each playbook needs to be rebuilt and tested on the target platform.

What happens to case history when we leave Google SecOps SOAR?

Playbook exports define automation logic, so case history should be treated as a separate workstream. Confirm with Google which case data can be exported, in what format, and what the retention terms are for data that stays in the platform. Decide before cutover how long closed cases must remain available for audit, incident review or legal hold, and where they will be stored. Open cases should be closed or transferred through a documented process so responders know where to work. Your compliance team should own the retention decision, and DeployOpen can prepare documentation and evidence for the controls that support it, but it does not issue audit reports or attestations.

What does the export work need from our team?

Most of the work needs named people from four groups:

Playbook owners who can explain what each playbook is meant to do and approve the rebuilt version.
Integration owners who know the credentials, endpoints and permissions for each connected tool.
An administrator with access to Google SecOps to run the export and confirm the scope of what it includes.
A Git host administrator who can create the repository, set branch protection and grant access.

Also name a security reviewer for secrets handling. Confirm whether exported playbooks carry credentials or only references to them. Shuffle, for example, stores saved app credentials encrypted under a secret you set, so those values must be re-entered on the new platform. Agree these responsibilities in the written scope before work begins.

How DeployOpen scopes and delivers a playbook export and exit

DeployOpen approaches a Google SecOps SOAR playbook export as a written, fixed-scope engagement inside your own infrastructure. We inventory what the export actually captures, rebuild the parts that do not transfer, and document the gaps, such as case history, before any cutover decision is made.

How we scope

Inventory every playbook, block, connector and job, and record which ones are exported as ZIP files and which are synced through GitSync.
Confirm with Google which export formats and import paths apply to your tenant and version, and record the answers in the scope.
Agree in writing what happens to case history, attachments and remote agent configuration, which the playbook exports do not carry.

How we build

Set up a Git repository for exported playbook definitions and review each file for credentials, hostnames and tenant-specific references.
Test exported definitions against a staging Shuffle or Tracecat instance and log every step that needs manual rebuilding.
Document the mapping from each Google SecOps action to its replacement integration, with notes on anything that has no direct equivalent.

How we hand over

Deliver a written inventory, the exported artifacts, a gap register and a rebuild list agreed with your security operations owners.
Provide runbooks for re-exporting and versioning playbooks so that future changes are tracked in Git rather than in a console.
Walk your team through the evidence package so that auditors and internal reviewers can trace each playbook to its source.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Confirm with DeployOpen during scoping which retainer terms, response expectations and review cadence apply to your environment.
Ask for a quote built from the written scope, which lists the playbook count, connector count and the depth of rebuild work.

How to export your playbooks from Google SecOps SOAR