Migrate from Google SecOps SOAR to Tracecat

Migrate from Google SecOps SOAR to Tracecat: what moves and what you rebuild

A security team that wants its playbooks, cases and alert handling under its own control should expect a rebuild, not a file transfer. Moving from Google SecOps SOAR to Tracecat means exporting what the product documents, recreating workflows as Tracecat workflows, cases and tables, and rewriting integrations as Tracecat custom actions. Playbook definitions and integration code can be exported where the platform supports it, but case history and the operational context around each alert generally do not carry over as working records, so plan to archive them separately. Confirm the export formats and their completeness with Google before you commit to a timeline.

Security automation engineers usually do the translation work, with SOC leads deciding which playbooks still matter and platform engineers owning the target environment. Effort and risk depend on three counts you should establish first: the number of playbooks in use, the number of custom Python integrations that call internal systems, and the number of alert sources that feed the SOAR today. A small library of playbooks against vendor-supported connectors is a very different job from dozens of playbooks that depend on hand-written code. Inventory each one, mark it as retire, rebuild or replace, and record which owner signs off.

Tracecat's deployment options shape the target design. Docker Compose on a single host suits a pilot or a small team, AWS ECS Fargate through Terraform and Kubernetes through a Helm chart suit teams with existing platform tooling, and the air-gapped Kubernetes option fits networks with no runtime internet access. Choose the target before you rewrite anything, because it determines where secrets, the object store and the Temporal and PostgreSQL dependencies live, and how custom actions are pulled from Git. Ask whether Git version control integration and any multi-tenant or single sign-on needs fall under the paid Enterprise Edition, since your cutover plan depends on it.

Which Google SecOps SOAR capabilities map cleanly to Tracecat

This table compares the main Google SecOps SOAR building blocks with their closest Tracecat equivalents and marks each as clean, needs rework or gap. Read the status column first, then check the notes on Enterprise features and Google's case wall and remote agent model, which have no direct counterpart. Confirm each row against your own playbooks before you commit to a cutover plan.

Google SecOps SOAR capability	Tracecat equivalent	Status	What to check
Playbooks	Workflows with webhook and schedule triggers	Needs rework	Google playbook logic must be rebuilt as Tracecat workflows; exports do not translate directly.
Blocks	Workflow actions and reusable custom actions	Needs rework	Map each block to a built-in action or a custom action, then test inputs and outputs one by one.
Prebuilt connectors	More than 100 prebuilt connectors in the repository	Needs rework	Confirm each connector you use exists and matches your current API version and credentials.
Python integrations	Custom actions synced from Git	Needs rework	Port each integration to Tracecat's action model and test against a non-production tenant.
Case management	Built-in case management	Needs rework	Field names, stages and attachments need manual mapping; Google's case wall has no direct equivalent.
Webhook-style alert intake	Webhook triggers in workflows	Clean	Repoint each alert source to the new webhook endpoint and verify payload shape.
Git-based content versioning	Git version control integration	Gap	Git version control integration is an Enterprise feature per the Tracecat documentation; confirm licensing before relying on it.
Single sign-on	Authentication and SSO	Gap	SSO is an Enterprise feature per the Tracecat documentation; plan an interim access model if you do not license it.
Remote agents pulling tasks over the Publisher proxy	No direct equivalent	Gap	Tracecat runs inside your boundary, so you must design network paths to each internal system instead of agents.

What to export from Google SecOps and what to rebuild in Tracecat

Moving from Google SecOps SOAR to Tracecat is split between what you can pull out of the source platform and what you must rebuild in Tracecat. The cards below separate the documented export paths from the gaps they leave, then cover integrations, credentials and alert sources, which need deliberate work on the Tracecat side.

ZIP export of playbooks

Playbook definitions can be exported from Google SecOps as ZIP files, which gives you a copy of each workflow's structure outside the cloud service. Treat the file as a reference for rebuilding logic, not as an import package for Tracecat. Confirm with Google what the export format contains, which items it includes, and whether any part of it can be loaded into another system before you plan around it.

GitSync to Git for content

GitSync pushes playbooks, blocks, connectors and jobs to a Git repository, which gives you versioned copies and a diff history during the move. Set up the repository and its access controls before the first export so that the copies are reviewable. Ask Google which content types GitSync covers in your edition, since coverage determines what you still need to capture by hand.

What exports leave out

Case history does not travel with the playbooks. Open cases, comments, attachments, analyst actions and closure notes stay in Google SecOps. Decide early which cases remain there for audit, which are closed out, and which are summarized into Tracecat case records. Ask Google to confirm exactly which case data, if any, can be exported for retention purposes.

Rebuilding Python integrations as custom actions

Python integrations written for Google SecOps need to be re-expressed as Tracecat custom actions, then synced from a Git repository so that changes go through review. Inventory each integration by the API it calls, its inputs and outputs, and its error handling. Expect some functions to need rewriting because the runtime, dependencies and secret access differ between platforms.

Mapping connector credentials to secrets

Connector credentials in Google SecOps must be recreated as Tracecat secrets, scoped to the workflows and actions that need them. Build a register that lists each connector, its account, its permissions and its rotation owner before you enter any value. Rotate credentials during the move so that copied values are not reused from the old platform.

Repointing alert sources to webhooks

Each alert source that currently feeds Google SecOps must be pointed at a Tracecat webhook trigger, one source at a time. Run both paths in parallel for a period, compare the alerts each platform receives, and then cut over. Confirm which sources can send to a custom endpoint and which need an intermediary, since the SIEM side of the flow may still hold some of them.

Migration sequence from inventory to decommission

This sequence moves Google SecOps SOAR playbooks, cases and alert sources to Tracecat in controlled stages, so each change is proven against live alerts before the old path is switched off. Each step ends with a written record that the next step depends on.

Inventory playbooks, blocks, connectors and alert sources
The security engineering lead, with the SOC manager, lists every Google SecOps SOAR playbook, custom block, integration connector, scheduled job and remote agent, and every alert source that feeds cases into the platform. For each playbook, record its trigger, the connectors it calls, the case fields it reads and writes, and who owns it. Export definitions as ZIP files or through GitSync where possible, and note what the export leaves out, such as case history. The step is done when the inventory register lists every item with an owner and a disposition: migrate, rewrite, retire or keep in place.
Translate integrations into Tracecat custom actions
The automation engineer rewrites each Python integration that the playbooks depend on as a Tracecat custom action and stores it in a Git repository that Tracecat syncs. Check each action against the vendor API it calls, confirm credentials are held in Tracecat secrets rather than in code, and confirm which connectors Tracecat already provides before writing new ones. Confirm with Tracecat's documentation how Git sync is configured in your edition, since Git version control integration is listed as an Enterprise feature. The step closes with a register of translated actions, their source commits and any gaps that need a workaround.
Pilot one or two representative playbooks
Choose one or two playbooks that represent the common path, such as enrichment followed by a ticket or a containment action with an approval gate. The automation engineer rebuilds them as Tracecat workflows in a dedicated test workspace, using webhook triggers and the case management features, and runs them against sample alerts and a non-production connector set. The SOC lead reviews each run and the case output. The step is complete when a pilot report records the workflow version, test alerts used, outcomes, defects found and the decisions needed before scaling up.
Run both platforms in parallel
Send the same alerts to Google SecOps SOAR and to the Tracecat workflows for an agreed period, with containment actions in Tracecat limited to notify or approve mode until results match. The SOC lead and analysts compare each alert's enrichment results, case fields, routing decisions and actions taken, and they record every difference with its cause. Parallel running is the point where gaps in translated actions and missing case history usually surface. The step closes with a comparison log that shows agreement by playbook, the open differences and the owner and fix date for each.
Cut over alert sources one at a time
Repoint one alert source at a time from Google SecOps to Tracecat's webhook intake, starting with the lowest-impact source. The SIEM or detection team changes the forwarding rule, the SOC lead confirms that cases open in Tracecat with the expected fields, and the old forwarding rule is disabled only after that check passes. Keep a rollback path for each source until the parallel comparison for that source has stayed clean. The step is done when a cutover record lists each source, the change date, the verification performed, the rollback owner and the sign-off.
Decommission Google SecOps SOAR content and remote agents
After every alert source is cut over and no playbook still routes live alerts to Google SecOps, the platform owner disables scheduled jobs, removes remote agents from the network, and revokes their service accounts and API keys. Archive the final exports, the inventory register and the comparison log in a location your records policy requires, and confirm with Google what retention and export obligations apply to your contract. Confirm also how case history will be retained if you need it for audit or investigation. The step is complete when decommission evidence shows the disabled jobs, removed agents, revoked credentials and archived records, signed off by the security owner.

How Tracecat fits your existing alert and case flow

Tracecat is built from several components, and each one changes where you place it on your network. The backend is Python with FastAPI, the frontend is Next.js, and Temporal runs workflow executions durably, so a run can resume after a process restarts instead of being lost. Data sits in PostgreSQL, files and large artifacts go to an S3-compatible object store, and nsjail sandboxes the code that runs inside workflows. Webhook triggers are the entry point for alerts from your SIEM or other sources, cases hold the investigation record, structured tables store enrichment data, and custom actions are the Python functions your workflows call. Confirm the current component versions and minimum resource requirements in the Tracecat documentation before you size hosts.

Network placement follows from that layout. Your alert sources need a route to the webhook endpoint, analysts need a route to the frontend, and the workers need outbound paths to every system a playbook touches, such as your EDR, identity provider and ticketing tools. Egress deserves its own review because custom actions and prebuilt connectors make outbound calls on the platform's behalf. Decide which destinations workers may reach, and whether an air-gapped Kubernetes deployment, which documents no runtime internet access, fits the integrations you keep. The same review covers the object store and PostgreSQL, which should stay inside your boundary with backups handled under your existing policy.

Credentials are the part most teams underestimate. Each connector and custom action needs secrets for the systems it calls, and those secrets end up in the platform's data store, so treat PostgreSQL and the object store as sensitive. Decide who may create or change secrets, whether Single Sign-On and multi-tenant workspace management are needed (the Tracecat documentation lists authentication and single sign-on as enterprise features, and the repository names multi-tenant workspaces as an Enterprise feature), and how you will rotate credentials that Google SecOps currently holds for you. Ask your Tracecat contact to confirm which of these controls the Community Edition includes before you finalize the access design.

What drives the cost and duration of the move

This table lists the factors that expand or shrink a move from Google SecOps SOAR to Tracecat, with the reason each matters and how to keep it under control. No figures are given because the scope of each factor depends on your own environment, so use the rows to build an inventory before you ask for a quote.

Driver	Why it changes cost or effort	How to keep it down
Number of live playbooks	Each playbook must be re-created as a Tracecat workflow, tested against sample alerts and approved. Effort grows with the count and with how many branches and sub-playbooks each one contains.	Retire unused and duplicate playbooks before export. Group similar playbooks so one rebuilt workflow can serve several alert types.
Custom Python integrations and blocks	Custom code must be rewritten as Tracecat custom actions, packaged and synced from Git. Integrations that call internal APIs or depend on libraries the team does not control take the longest to validate.	Inventory each integration by owner and by the API it calls. Remove integrations nobody uses, and standardize on a small set of helper functions.
Connectors and third-party credentials	Each connector needs a Tracecat equivalent or a custom action, plus vault-held credentials, network paths and test accounts. Credential rotation and approval for each system adds calendar time that is outside the build work.	List every connector with its owner, credential type and network path early. Ask owners to pre-approve service accounts so testing is not blocked.
Number of alert sources and SIEM feeds	Every ingestion path from the SIEM or other detection tools must be repointed to Tracecat webhooks, and each one needs field mapping and a parallel run. Cutover risk increases with the number of feeds that fire during the same window.	Migrate one alert source at a time. Document field mappings once and reuse them across feeds that share a schema.
Case volume and history retention	Google SecOps case history does not carry over automatically, so retention rules decide whether you need an archive, a read-only export or a bridge period. High case volume raises the work needed to map case fields and attachments.	Confirm with compliance which open cases and which historical records must be kept. Close or export older cases before cutover, and set a clear retention rule for the archive.
Approval and change control	Playbooks that touch production systems usually need sign-off from the SOC, change advisory board or system owners. Each review round adds time that does not scale with build effort.	Agree on the approval path and the test evidence required before work starts. Batch reviews by playbook category.
Deployment target	A single host running Docker Compose needs less setup than a Kubernetes deployment, and an air-gapped Kubernetes deployment adds offline image handling, internal registries and update procedures. Each choice affects who maintains the platform after go-live.	Choose the target from your hosting standards and data residency rules first. Confirm which deployment method your team already operates to avoid new skills.
Enterprise features required	Multi-tenant workspace management, Git version control integration and single sign-on are listed as Enterprise features in Tracecat's repository and documentation. A paid Enterprise license is a separate cost line that recurs under its own terms.	Map each requirement to a feature before you commit. Ask Tracecat for the current license terms and whether a community setup covers your needs.
Internal staff time	Engineers and SOC analysts who inventory, rebuild, test and approve automations are the largest cost in most moves. This is one-time effort during migration, followed by recurring effort to maintain workflows.	Name owners for each playbook group and schedule their time before the project starts. Ask whether a quote includes knowledge transfer.
DeployOpen fixed-scope work, if engaged	If you engage DeployOpen, the cost follows from a written scope covering inventory, translation, deployment, testing and handover. DeployOpen does not publish a price list, so the quote depends on the scope you agree.	Provide a complete inventory and a clear list of out-of-scope items. Ask for deliverables, acceptance criteria and timelines in the written scope.

What usually goes wrong in a SOAR migration and how to prevent it

Most SOAR migrations stall on the same few issues: assumptions about what an export carries, underestimated code rewrites, and cutovers that happen too fast to compare behavior. Each card below names one failure point in a move from Google SecOps SOAR to Tracecat and the check that prevents it before cutover.

Assuming exports carry case history

Playbook exports capture automation logic, not the open and closed cases, analyst notes or evidence attached to them. Teams that treat the export as a full backup lose the audit trail they may need for past incidents. Before cutover, decide where closed case records will live, confirm with Google what the export omits, and archive case data in a system your retention policy covers.

Underestimating Python integration rewrites

Custom Python integrations and actions written for Google SecOps do not run unchanged as Tracecat custom actions. Each one needs its inputs, outputs, error handling and secrets mapped to Tracecat's action model, then tested against the real API. Inventory every integration, rank them by how many playbooks depend on them, and budget rewrite and test time per integration rather than per playbook.

Cutting over all alert sources at once

Repointing every SIEM rule, webhook and log source to Tracecat on one day removes the fallback if a mapping is wrong. Move one alert source at a time, starting with a low-volume source, and keep Google SecOps receiving the same alerts until the new path has produced matching case outcomes. Record which source moved on which date so any regression traces back to a single change.

Losing secrets and credential scope

Google SecOps integrations often run with service accounts and API keys that were scoped for that platform's remote agents. Copying the same credentials into Tracecat can give workflows broader access than they had, and rotating them mid-migration can break playbooks silently. Create a separate credential set per Tracecat integration, grant only the actions each playbook uses, and document which secret backs which workflow.

Silent differences during parallel run

Enrichment lookups, field normalization and response actions can behave differently between platforms even when the playbook looks identical on paper. A timeout, a default value or a block that returns a slightly different field can change a verdict without raising an error. Run both platforms on the same alerts for a defined period, compare enrichment results and response actions field by field, and sign off each difference before retiring the old playbook.

Relying on Enterprise features unbudgeted

The Tracecat repository names multi-tenant workspace management and Git version control integration as Enterprise features, and the documentation places authentication and single sign-on in the same group. A design that depends on Git-synced custom actions or SSO for analyst access can stall when the paid edition is not in the budget. Map each planned capability to the Community or Enterprise edition before design freeze, and ask Tracecat in writing which license covers it.

How the migration differs by team size and starting point

A small SOC usually has a short list of playbooks, most of them calling prebuilt connectors for common tools such as ticketing, email and endpoint products. The migration here is mostly about deciding which playbooks are still worth moving and rebuilding them as Tracecat workflows with webhook triggers, rather than carrying over every historical automation. Because the surface area is small, a single-host Docker Compose deployment is often enough to start evaluation, and the team can validate each workflow against a test alert before cutover.

Playbook triage: Export the playbooks you actually run, then retire any that no one has triggered in a long time.
Connector check: Confirm that each prebuilt connector you depend on has an equivalent in Tracecat's connector catalog, and note any gaps.
Single-host start: Docker Compose on one host is a reasonable first deployment, but confirm it meets your backup and recovery expectations before production use.
Case handling: Decide whether historical Google SecOps cases stay in the old system as read-only records or are re-created in Tracecat.
Cutover: Switch one alert source at a time so a problem affects a single queue.

Before you start, confirm with the Tracecat documentation which of these features your plan includes, since some capabilities are gated behind the Enterprise Edition.

Questions teams ask before moving from Google SecOps SOAR to Tracecat

How much effort does a move from Google SecOps SOAR to Tracecat take?

The effort depends mainly on how many playbooks you run, how many custom Python integrations they depend on, and how many alert sources feed them. A small set of playbooks that call prebuilt connectors is a much smaller job than a estate of customized integrations with years of case-driven logic. Inventorying those three things first gives you the basis for a written scope. Ask any provider to price the work from that inventory rather than from a flat estimate, and ask what is excluded, such as SIEM changes or retraining analysts.

Can Google SecOps SOAR playbooks be imported into Tracecat directly?

No direct import path should be assumed. Google's exports are meant for its own product, so expect to export definitions, read them, and rebuild each workflow in Tracecat. Logic that uses Google-specific blocks or case fields has to be mapped by hand to Tracecat workflow steps, and any Python integration code has to be translated into Tracecat custom actions synced from Git. Confirm the current export formats and any import guidance with Google before you start, since the export does not carry over everything a playbook depends on.

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

Case history normally stays in Google SecOps and is not moved with the playbooks. Playbook exports define automation, not the record of what happened in each case, so the notes, timelines and attachments remain where they are unless you extract them. If you need that history in Tracecat, plan a separate export of closed cases and decide whether you need it as searchable records or as read-only archive. Confirm with Google which case fields and attachments its export methods cover, and agree with your compliance team how long the source records must be kept.

Do Tracecat's Git sync and single sign-on require the paid edition?

Yes, both are listed as Enterprise features. The Tracecat repository names multi-tenant workspace management and Git version control integration as Enterprise features, and the documentation describes authentication and single sign-on as enterprise capabilities. Code in the enterprise package and enterprise feature gates is under a separate paid license, while the core platform is AGPL-3.0. Before you plan around these features, confirm the current edition boundaries with Tracecat and get the license terms in writing, because Git-based custom actions are central to translating Python integrations.

Can our internal staff move playbooks to Tracecat without outside help?

Internal staff can do it if they have the time and the skills. The work requires someone who can read the current playbook logic, someone who can write and test Python custom actions, someone who can run Tracecat in your environment, and someone who understands the cases and alert sources. Many teams underestimate the time that analysts need for testing and sign-off alongside their normal duties. An outside implementation partner can take on the inventory, translation, deployment and cutover work under a written scope, while your team keeps ownership of the decisions.

What do we need to provide for the migration to succeed?

The migration needs three groups of people and one environment. Playbook owners must explain what each workflow is meant to do and which decisions it makes. Integration owners must confirm credentials, API behavior and any custom code that calls internal systems. Analysts must test cases against the new workflows. The environment is a test instance of Tracecat, deployed with Docker Compose on a single host, on Kubernetes through a Helm chart, or in an air-gapped cluster, where you can run replayed alerts before any alert source is cut over.

How do we get a quote for a migration?

Ask for a quote from a written scope. DeployOpen plans, implements, integrates and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. To get a quote, provide the playbook inventory, the list of integrations and alert sources, your target deployment model, and the testing and sign-off requirements. DeployOpen does not publish a price list, so the quote follows from that scope, and you should ask which items are excluded, such as SIEM changes or ongoing support.

How DeployOpen scopes and runs a Tracecat migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and that is how we approach moving Google SecOps SOAR playbooks and cases to Tracecat. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

We inventory playbooks, blocks, connectors and alert sources exported from Google SecOps SOAR before estimating any work.
The written scope lists which playbooks move, which are retired, and which custom Python integrations become Tracecat custom actions.
We confirm which Tracecat deployment fits your environment: Docker Compose, Kubernetes, AWS ECS Fargate or air-gapped Kubernetes.
We state which Tracecat features your scope needs and whether any fall under the separate Enterprise Edition license.

How we build

We translate Python integrations into Tracecat custom actions and store them in Git so they sync into the platform.
We rebuild playbooks as Tracecat workflows with webhook triggers, then test each one against sample alerts from your sources.
We map Google SecOps cases to Tracecat case management and document any fields that do not carry across cleanly.
We configure alert sources to point at Tracecat in stages, keeping the existing path available until each cutover is verified.

How we hand over

You receive documentation of the deployed architecture, configuration, secrets handling and each migrated workflow.
We provide a runbook covering cutover steps, rollback steps and the checks run at each stage of the move.
Knowledge transfer sessions cover how your team edits workflows, manages custom actions in Git and reviews run history.
Test evidence and configuration records are delivered so your own auditors or certification bodies can review them.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover Tracecat version upgrades, backups of the PostgreSQL and object store data, and patching of the hosts.
We can run security testing of the Tracecat deployment and its integrations as part of a separate, written scope.
Support terms, response expectations and the retainer scope are agreed in writing and confirmed before any work begins.

Migrate from Google SecOps SOAR to Tracecat