Migrate from Tines to Tracecat

Migrate from Tines to Tracecat: what the move involves

The move from Tines to Tracecat is a rebuild of each story as a Tracecat workflow, not a data import. Tracecat has no way to load a Tines story file and run it unchanged, so every live story has to be read, redesigned and recreated in Tracecat's workflow editor, then tested against the same inputs before anyone switches triggers over. Teams usually arrive here because of a renewal, a three-workflow ceiling on the Tines Free edition, or a requirement to host automation in their own environment. The security engineering team that owns the existing stories normally leads the rebuild, often with an implementation partner doing the platform setup, integration work and hardening. Effort depends mainly on two things: how many stories are live, and how many of them depend on HTTP request actions and stored credentials. Stories that call a small number of well-documented internal or vendor APIs are usually quick to recreate. Stories with branching logic, custom transforms or many hard-coded endpoints take longer, and each credential must be recreated in Tracecat and checked for scope. Ask any partner to inventory both counts before agreeing a fixed scope. Start with the inventory. Export the stories and list every trigger, action and credential reference, then mark which stories are business-critical and which are dormant. Confirm which Tracecat deployment fits your hosting rules, since the documentation covers Docker Compose on a single host, AWS ECS Fargate, Kubernetes and an air-gapped Kubernetes option, and check that the features your stories use exist in Tracecat before you commit. Run the rebuilt workflows in parallel with the Tines originals and keep the Tines stories live until the outputs match.

Which Tines capabilities map to Tracecat, and which need rework

This table compares the Tines capabilities most teams rely on with their closest Tracecat equivalents. Each row is marked clean, needs rework or gap, so you can see which stories can move with little change and which need a rebuild or another tool. Treat each status as a starting hypothesis and confirm it in a pilot using copies of your own stories.

Tines capability	Tracecat equivalent	Status	What to check
Stories as workflows	Tracecat workflows built from actions and triggers	Needs rework	Rebuild each story by hand, using the exported story file as the inventory and checklist
Webhook triggers	Webhook triggers in Tracecat workflows	Clean	Confirm payload shape, authentication and retry behavior with each sending system
HTTP request actions and credentials	Custom actions and workflow secrets	Needs rework	Recreate each request and move every credential into Tracecat secrets, then test responses
Case management	Built-in case management	Needs rework	Map Tines case fields, statuses and comments to Tracecat case fields before moving records
Structured tables	Structured tables	Needs rework	Recreate table schemas and seed data, then confirm lookups behave the same inside workflows
Custom actions from Git	Custom actions synced from Git	Needs rework	Git sync is listed as an Enterprise feature, so confirm licensing before you plan around it
AI agents with tools	Custom AI agents with tools and MCP servers	Needs rework	Review prompts, tool permissions and MCP server access, then retest every agent output
Tines pages	No confirmed equivalent in Tracecat documentation	Gap	Confirm with the vendor and in a pilot, and plan a separate tool if pages are required
Single sign-on and authentication	Enterprise feature under a separate license	Gap	Confirm the Enterprise license terms if SSO is required for your analysts

Which exports and integrations to move, and how

The Tines export is the starting point for this move, but it does not finish it. Each card covers one input you must rebuild or move by hand or by script, with what it needs and what to confirm in your own tenant before you switch anything off.

Story files as the logic inventory

Export each story as a story file and treat the set as your inventory of logic: one entry per story, with its actions, the links between them and the settings that shape each run. Read each file against what the story does in production, because the file describes structure and may omit runtime state, event history and anything held outside the story. Confirm which story elements your export covers before you estimate the rebuild.

Event history through the events API

Run history lives in the events API, not in the story file, so pull it separately if you need past payloads for testing or audit. Plan for paging: results come back in pages, and large payloads may be limited, so script the pull and check that record counts match the source. Confirm the current paging and payload limits in Tines documentation for your plan, and redact sensitive fields before the data leaves Tines.

Re-entering credentials, not copying secrets

Exports should not be the way secrets move. Create each credential fresh in Tracecat, using the same service account or token scope the Tines story used, and record which workflow depends on each one. Rotate anything that was ever pasted into a story or shared outside your vault, because a copied secret carries its old exposure with it. Confirm with your security team which credentials need rotation before cutover.

HTTP request actions as Tracecat actions

Each Tines HTTP request action maps to either a Tracecat action or a custom action. Use a custom action when the same endpoint is called from several workflows or needs a fixed request shape, and keep its definition in Git so changes are reviewed. Map headers, authentication and response parsing one by one, and test each against a non-production target before any live use.

Webhook triggers with new endpoints

Tines webhook URLs do not carry over. Every inbound webhook needs a new endpoint from its Tracecat workflow, so the sending tools, log forwarders and ticketing integrations must be reconfigured to point at it. Run the old and new triggers side by side, compare outputs for the same test events, and only then update each sender. Keep a list of every sender per story so none still points at a retired Tines endpoint.

Cases and history: manual or scripted

Open cases in Tines are not carried into Tracecat automatically, so decide per case type whether to close them in Tines or copy them forward. Manual moves suit small volumes and a few high-impact open incidents. Scripting suits larger sets and needs a case export, a field mapping to Tracecat case management and an import step with a log of every record. Confirm what case data your Tines export includes and what Tracecat's case import supports in your version.

The migration sequence from inventory to decommission

The sequence moves Tines stories into Tracecat in controlled stages, so each workflow is proven against the same events before any webhook source is switched. Each step produces a written record that the next step depends on, and Tines is retired only after the last live story has been replaced or deliberately dropped.

Build the story inventory from exported files
Export every story from Tines as a story file, then list each one in a mapping sheet with its owner, trigger type, actions, credentials, connected systems, schedules and whether it is live. Mark which stories depend on Tines-only features such as pages, so they are assessed separately. The step is done when every live story has a row and every row has a named owner who has confirmed the story still matters. Confirm with your Tines administrator that the export captures everything you need, since the story file does not contain all runtime history.
Stand up a self-hosted Tracecat instance
Deploy Tracecat in your own environment using the method your platform team has chosen, such as Docker Compose on a single host, Kubernetes with the Helm chart, or the air-gapped Kubernetes option if your network requires it. Confirm the deployment reaches the systems your stories call and that secrets are stored in a location your security team approves. The step is done when a test webhook reaches a workflow and returns a logged result, and the deployment configuration is recorded in version control.
Rebuild and test one pilot workflow
Choose a low-risk, well-understood live story as the pilot and rebuild it as a Tracecat workflow, recreating each HTTP request action, its credentials and its conditional logic from the story file. Keep the original Tines story unchanged. Run the workflow against recorded or sample payloads and compare each output field with what Tines produced for the same input. The output is a pilot test evidence record listing inputs, expected outputs, actual outputs and any differences, signed off by the workflow owner.
Rebuild the remaining stories in priority order
Work through the inventory in an order agreed by the business owners, starting with stories that have the fewest dependencies. For each story, record the Tines component, its Tracecat equivalent, and any function that has no direct counterpart, such as pages or Tines-specific transforms. Stories that rely on a feature with no clear Tracecat equivalent are flagged for an alternative tool decision rather than forced into a workflow. The step is complete when every inventory row has a Tracecat workflow, a documented gap or a retirement decision.
Run Tines and Tracecat in parallel on the same events
Send the same test events to both the Tines story and the matching Tracecat workflow, keeping Tines as the system of record for actions. Compare the outcomes of each run, including tickets opened, notifications sent, enrichment results and error handling. Capture discrepancies in a parallel run log and fix them in Tracecat until the logs show consistent results over the period your security operations team agrees is sufficient. Confirm with your own change process how long parallel running must continue, since no timeline is set by the platform.
Move cases and switch each webhook source
Decide which case records stay in Tines for reference and which are migrated or recreated in Tracecat case management, and document the field mapping for any that move. Then cut over one webhook source at a time, updating the sending tool to point to the Tracecat webhook. Each cutover uses a written checklist covering the source, the new endpoint, the owner, the rollback method and the verification step. The step is done when the checklist for every source is signed off and no active trigger still points to a Tines story.
Retire Tines after the last live story
Once the last live story has been replaced, archived or formally dropped, disable the remaining Tines stories and revoke any API keys and integrations still connected to Tines. Export a final copy of the story files and any events you need for audit or records retention, and store them where your retention policy requires. Ask your Tines account team to confirm the subscription end date and data handling in writing before you close the account. The decommission is complete when the closure record, the final export location and the access revocation list are filed with the migration evidence.

What drives the cost and duration of the rebuild

This table lists the inputs that set the size of a Tines to Tracecat rebuild, who pays for each one, and whether it is a one-time or recurring cost. Use it to see which numbers to count in your own estate before asking for a written quote.

Driver	Why it changes cost or effort	One-time or recurring	How to keep it down
Live stories in scope	Each live story is rebuilt as a Tracecat workflow and tested, so the count sets most of the rebuild effort. Tines Free caps live workflows at 3, so larger estates usually run paid editions.	One-time	Retire stories that no longer run, and merge stories that share the same logic before rebuilding.
HTTP actions and credentials	Each HTTP request action needs its URL, headers, body and authentication recreated, and each credential must be stored in Tracecat again. Credentials often take longer than the logic because owners must be found.	One-time	Group actions by target system and reuse one authenticated connection pattern per system.
Case volume and history to preserve	Open cases and historical records may need migration into Tracecat case management. Pulling event history through the Tines events API and mapping it takes more time as volume grows.	One-time, with storage recurring	Migrate only open cases and the records your retention policy requires, and archive the rest read-only.
Depth of integrations	Stories that call many internal tools, use custom code or depend on Tines-specific features such as pages need more design and may need a different tool. Tracecat offers more than 100 prebuilt connectors, so check each integration against that list.	One-time	Inventory integrations first and flag any feature with no Tracecat equivalent before estimating.
Hosting choice	Docker Compose on a single host is the simplest path. Kubernetes with the Helm chart, AWS ECS Fargate through Terraform, and air-gapped Kubernetes each add platform setup and ongoing operations. Tracecat's stack includes Temporal, PostgreSQL and an S3-compatible store, all of which need running.	One-time setup, recurring operations	Match the hosting option to the skills you already run rather than adopting a new orchestrator for this project alone.
Internal skills available	Staff who know Python, Docker, Kubernetes and your SIEM or ticketing APIs shorten the rebuild. Staff who only know the Tines editor will need training and more review time.	One-time (training), recurring (on-call)	Name an owner for each workflow and pair builders with the people who run the target tools.
Testing effort per workflow	Each rebuilt workflow needs a test against representative input and a parallel run before its trigger moves. This step often takes as long as the build for high-risk stories.	One-time	Define test cases from the exported story file and keep a checklist of trigger switches.
Enterprise features and identity	Single sign-on, multi-tenant workspace management and Git version control are Tracecat Enterprise features under a separate license. Ask whether your access model needs them before you design the rebuild.	Recurring license, if required	Confirm the Enterprise scope in writing with Tracecat and your procurement team before the build starts.

Running Tracecat yourself: what the platform needs

Before you plan a Tracecat rebuild, confirm that your team can operate its stack. Tracecat's backend is Python with FastAPI, its frontend is Next.js, and it runs workflows on Temporal for durable execution. Data sits in PostgreSQL, files and artifacts sit in an S3-compatible object store, and actions run inside nsjail sandboxes. Each of these is a component you patch, monitor, back up and restore, so the operating burden is closer to a multi-service application than a single container. The Tracecat documentation describes Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart, and an air-gapped Kubernetes option, so pick the deployment shape first and map each component to a team that owns it.

Plan backups around the two data stores that hold your migrated work: PostgreSQL for workflows, cases, tables and configuration, and the object store for files. Test a restore of both together, because a case that references an object missing from the bucket is a broken record. For upgrades, check the release notes before each move. The repository's releases page lists Tracecat 1.2.0 as released on October 16, 2026, and the Temporal and sandbox layers mean a version change can touch more than the web application. Run upgrades in a staging copy built from the same deployment method, and keep a record of which version your rebuilt workflows were tested against.

Licensing is the second decision. The core platform is licensed under AGPL-3.0, which governs how you may modify and offer the software. Code in packages/tracecat-ee and the enterprise feature gates falls under a separate paid Enterprise Edition license. The repository names multi-tenant workspace management and Git version control integration as Enterprise features, and the documentation places authentication and single sign-on in that group. If your Tines stories depend on SSO, multiple tenants or Git-based change control, get the Enterprise license terms in writing before you commit, and ask Tracecat which of your planned features require it. Confirm this with the vendor rather than assuming the open-source build covers your requirements.

What usually goes wrong and how to prevent it

Most failed Tines to Tracecat rebuilds fail on assumptions made before the first workflow is built. The cards below cover what exports miss, what gets copied unsafely, and what gets discovered too late, each with a check to run before cutover.

Assuming stories export everything

A story file describes workflow logic, but it may not carry everything a live story depends on, such as event history, runtime state or every linked resource. Treat the export as the inventory of workflow logic, not a complete backup. Before you start, list each Tines story, its triggers, its actions and any external dependencies, then compare that list with what the export contains. Ask Tines support to confirm exactly what the export omits for your plan.

Copying secrets through exports

Credentials referenced by HTTP actions can end up in files, screenshots or chat threads during a rebuild. Do not paste API keys or tokens into a migration spreadsheet or into a workflow as plain values. Create each credential once in Tracecat's secrets handling, scope it to the workflow that needs it, and record only the secret's name and owner in your inventory. Rotate any credential that appeared in an exported file or a shared document.

Cutting over without a parallel run

Switching webhook triggers from Tines to Tracecat in one step removes your ability to compare outputs. Run both platforms side by side for a defined period against the same sample events, and compare case creation, enrichment results and downstream tickets. Only move a trigger after its Tracecat workflow produces matching results. Keep the Tines story disabled but intact until you have confirmed the new path in production.

Losing case history

Open cases, comments and their linked evidence do not move with a workflow definition. Decide before cutover which cases stay in Tines for reference, which are closed, and which are recreated in Tracecat with their history summarized. Export the case records you need for audit before any Tines access is removed, and confirm the retention terms in your Tines contract. Recreated cases should link back to the original record.

Underestimating HTTP action rework

Each Tines HTTP request action carries its own URL, headers, body templates and error handling, and these often need rewriting as Tracecat actions with their own parameters and secrets. Pagination, retries and response parsing tend to take the most time. Budget rework per action type, not per story, and test each endpoint against a non-production tenant. Ask your Tracecat implementation partner to confirm how many distinct HTTP patterns your stories use.

Finding Enterprise-only features late

Some capabilities that matter to a regulated team sit behind Tracecat's paid Enterprise Edition, including multi-tenant workspace management, Git version control integration, and authentication and single sign-on. Check these against your requirements at the start, not during testing. Also confirm how Tines features you rely on, such as pages, map to Tracecat or to another tool. Put the gaps into the written scope so they are not discovered after cutover.

Leaving the self-hosted stack unpatched

A Tracecat deployment runs several components, including a Python API, a Next.js frontend, Temporal, PostgreSQL and an object store. Each needs a patch and upgrade routine, and Tracecat releases move quickly, so pin versions and read release notes before upgrading. Assign an owner for patching, test upgrades in a staging environment, and confirm backup and restore for the database and object store before production go-live.

How the move differs by team size and starting point

A team at the three-live-workflow ceiling of the Tines Free edition usually has a short list of stories that matter and a clear reason to move now. The first step is to decide which of those three live stories must keep running during the cutover and which are experimental. Only the live ones need a Tracecat counterpart on day one, so the scope is narrower than a full estate inventory. Build the surviving stories as Tracecat workflows with webhook triggers, test them against sample payloads, then switch the trigger source last.

Scope: limit the first build to the stories that are actually live, plus any drafts you plan to promote.
Sequence: stand up Tracecat first, then rebuild one story at a time in a non-production workspace.
Credentials: recreate each connection in Tracecat's secrets handling before the workflow that uses it is tested.
Cutover: repoint each webhook or schedule only after the replacement has produced the expected output.
Hosting: Docker Compose on a single host is a common starting point for a small set of workflows, though you should confirm it fits your availability needs.

Before committing, confirm which Tines triggers and connectors your live stories use and check that Tracecat's prebuilt connectors cover them.

Questions buyers ask before moving from Tines to Tracecat

How much does a migration from Tines to Tracecat cost?

The cost is mostly labor, not software, because Tracecat's core platform is AGPL-3.0 licensed and you pay for infrastructure, the rebuild and the people who run it. The main drivers are the number of live stories, how many distinct HTTP integrations and credentials each one uses, how many stories rely on Tines-specific features such as pages, and how much of your event history you need to keep. One-time costs include the rebuild, testing and cutover. Recurring costs include the hosting you choose, storage, upgrades and on-call time. Ask any quote to separate these lines, to state which stories are in scope, and to say who maintains custom actions after handover. Tracecat's Enterprise features, such as single sign-on and multi-tenant workspace management, are a separate license decision with their own cost.

How long does it take to rebuild Tines stories in Tracecat?

Duration depends on the size of the story inventory and how many stories need custom HTTP logic, and no timeline can be given before that inventory is counted. Start by exporting your stories as story files so you can count live workflows, actions, credentials and webhook triggers. Simple webhook-to-notification stories move quickly, while stories with branching, retries and external case updates take longer to rebuild and test. Ask for a timeline that is tied to a written list of stories, with a test and cutover step for each one. Your own environment, change windows and approval steps will also set the pace.

What does the internal team need to provide during the migration?

Your team needs to supply knowledge that the story file does not contain. That includes the business intent behind each story, the owners of each connected system, service account rights for every credential, and the approved trigger sources such as SIEM alerts, email or ticketing webhooks. Someone must also be able to run a Tracecat deployment, whether Docker Compose on a single host, Helm on Kubernetes, or an air-gapped Kubernetes install, because Tracecat depends on PostgreSQL, Temporal and an S3-compatible object store. Plan for a named technical owner, a security reviewer for credential handling, and an analyst who can confirm that each rebuilt workflow produces the same case outcome.

Can our own engineers do the Tines to Tracecat migration without outside help?

Yes, a capable internal team can do it, provided it has the time, the platform skills and a test process. Tracecat's documentation covers deployment and workflow building, and the story files give you a starting inventory. The risks are not usually the first workflow but the edge cases: credential scope, retry behavior, error handling and workflows that change during the rebuild. If you want outside help, DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, under a fixed-scope written agreement, and ongoing support is available as a retainer. Ask any partner to show how it will test each story before cutover.

Do Tines pages and other Tines-specific features move to Tracecat?

Pages do not map directly to Tracecat workflows, so plan to rebuild their function with another tool. Tracecat covers webhook-triggered workflows, case management, structured tables, custom AI agents with tools and MCP servers, and custom actions synced from Git. Before the migration, list every Tines feature each story uses, including pages, scheduled runs, built-in transforms and any Tines-hosted storage, and classify each one as rebuilt in Tracecat, replaced by a case or table, or kept in another system. Confirm the exact feature match with Tracecat's documentation rather than assuming one, and record any gap as a decision for the business owner.

Which Tracecat features require the Enterprise Edition?

Tracecat's repository names multi-tenant workspace management and Git version control integration as Enterprise features, and its documentation describes authentication and single sign-on as enterprise features. Code in the enterprise package and enterprise feature gates falls under a separate paid license, while the core platform is AGPL-3.0. Decide early whether you need single sign-on, multiple workspaces or Git-based change control, because each one affects licensing, identity integration and how custom actions are promoted between environments. Ask Tracecat for current Enterprise terms in writing before you plan around them.

What happens to Tines event history and cases during the switch?

Event history and open cases need a separate plan, because a story file does not hold everything you may need. Export your Tines event history through its events API, noting paging and payload limits, and decide how much of it to keep and where. For open cases, decide whether to close them in Tines, recreate them in Tracecat case management, or run both systems in parallel for a defined period. Ask your partner or internal team to document how analysts find historical records after cutover, and confirm that the retained data sits inside your own storage.

How do we confirm each rebuilt workflow is safe to switch on?

Test each workflow against the same input as the Tines version, compare the actions it takes and the case records it creates, and only then move its trigger. Run replayed or sample alerts in a non-production Tracecat workspace, check that credentials are scoped to the least rights the workflow needs, and confirm that failures alert a person. Keep the Tines story running until the replacement passes, then switch triggers one story at a time. Document each test result so an auditor or incident reviewer can trace why a workflow was approved. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications.

How DeployOpen scopes and runs a Tines to Tracecat migration

Most DeployOpen migrations of this kind start with a written, fixed scope. Before any work begins, the scope, deliverables and timelines are agreed in writing, and a quote follows from that document. DeployOpen does not publish a price list, so the practical step for your team is to write down the inventory it needs to price: how many Tines stories are in use, which ones are live, which connect to case handling or pages, which credentials they depend on, and where the self-hosted Tracecat platform will run (Docker Compose on a single host, Kubernetes with the Helm chart, AWS ECS Fargate, or an air-gapped Kubernetes deployment). Ask for each of these to appear as a named deliverable with an acceptance check, so that rebuilt workflows are not counted as done until they have been tested against real triggers.

The work usually falls into four parts. The first is planning and implementing the self-hosted Tracecat platform itself, including its PostgreSQL database, S3-compatible object store and Temporal dependency, along with the SSO and access model your identity team requires. The second is hardening it, covering network placement, secrets handling and backup of the platform data. The third is rebuilding the workflows, testing each one before its trigger is switched over, and documenting the result. The fourth is handover and support. Ongoing support, upgrades and continuous testing are available under retainers, which many teams prefer because Tracecat releases change over time and someone must own the upgrade path after the initial cutover.

DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. If your migration has to support a review, ask the scope to include the specific evidence you will hand to your auditor, such as access configuration, change records for each rebuilt workflow and backup test results. Independent auditors and certification bodies decide whether those controls meet their criteria. Confirm with your assessor early which evidence they expect, and confirm with your own compliance lead which Tines features still in use, such as pages, need an alternative tool before the Tracecat scope can be finalized.

Migrate from Tines to Tracecat