Migrate from Tines to Shuffle

Migrate from Tines to Shuffle: what the move involves

Most teams start this move because of a renewal, a licensing change, or a requirement that security automation data stay inside their own network. The migration is a rebuild of each Tines story as a Shuffle workflow, not a file import. Shuffle does not read a Tines story file and run it. Effort depends on how many stories are live, how many credentials and HTTP integrations each one uses, and how much logic depends on Tines-specific actions. Start by exporting every story as a story file, using the process in the export guide, and treat those files as the inventory and the specification. Each story file shows the actions, their order, and the fields they read and write, which is the starting point for each Shuffle rebuild.

Security engineering usually owns the rebuild, with platform engineers responsible for the Shuffle deployment and app owners confirming which systems each workflow touches and which accounts it should use. Credentials need particular care. Shuffle stores app authentications encrypted in OpenSearch using the SHUFFLE_ENCRYPTION_MODIFIER secret, so that value must be backed up and kept stable from the first install, because changing it breaks every saved authentication. Confirm with the Shuffle configuration docs which apps in your inventory exist as premade apps, which need an app built from an OpenAPI specification, and which need a custom Python app. Webhooks and schedules are re-created in Shuffle, so each workflow should run in parallel with its Tines story and be tested before its trigger is moved.

The main risk is a workflow that works in testing but behaves differently under live events, particularly one that depends on a Tines feature with no direct Shuffle equivalent. Keep the Tines story live until the Shuffle version has processed representative events and its outputs match. Tines Free allows 3 live workflows and unlimited users, spaces and connectors, and its pricing page states that flexible hosting options are available on request, so confirm the hosting and edition terms your contract provides before you set a cutover date. For Shuffle, confirm the current release and minimum resource needs against the install guide, and plan for a second Orborus node if workflows must keep running through a single node failure.

Which Tines capabilities map to Shuffle, and which need rework

This table compares each Tines capability in a migration with its Shuffle counterpart and marks it as clean, needs rework or gap. Clean means the capability carries over without a structural change, needs rework means the logic moves but configuration must be recreated, and gap means you must confirm the feature in your target environment before planning the cutover. Most of the effort sits in credentials, triggers and rebuilding stories, while case and page features need explicit verification.

Tines capability	Shuffle equivalent and what changes	Status
Stories	Shuffle workflows, rebuilt step by step using exported story JSON as the specification	Needs rework
HTTP request actions	HTTP calls through a premade app or an app built from an OpenAPI specification in the App Creator	Needs rework
Credentials	Saved app authentication, re-entered in Shuffle and encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret; changing that secret breaks saved logins	Needs rework
Live workflow limits and run metering	Shuffle meters app runs; users, apps and workflows are unlimited under its pricing model	Clean
Webhooks	Webhook triggers with new endpoints on your Shuffle server; every upstream sender must be updated	Needs rework
Schedules	Schedule triggers in Shuffle; confirm time zone and run behavior against the Tines schedule before switching	Needs rework
Events and run history	Shuffle execution history covers new runs; Tines event history needs a separate export and retention plan	Gap
Cases	Confirm case handling in your Shuffle version and environment; do not assume parity with Tines	Gap
Pages	Confirm an equivalent in your target environment; plan another tool if no match exists	Gap

Using exported story JSON as the specification

Treat each exported Tines story file as the specification for its Shuffle rebuild. Before anyone opens the Shuffle editor, inventory every story and record its actions, the edges that connect them, the inputs each action reads, and every credential reference it uses. The file gives you the structure, so the team rebuilds from a fixed list rather than from memory of how each story behaves. Use the export steps in the sibling how-to-export guide to pull the files, and keep a copy of the originals under version control so the baseline stays unchanged while you work. The export is a design document, not a runnable import for Shuffle, so each action still needs to be mapped by hand to a Shuffle app action.

Plan on rebuilding some state by hand. A story file describes how a workflow is wired, but it does not carry the event history your stories produced, nor the live state of running stories, nor the values behind your credentials. Confirm the exact contents of the file against your own exports, then list what is missing: past event records you may need for audit or troubleshooting, any counters or cached values stories depend on, and each webhook URL or schedule that external systems call. Note that credentials must be re-entered in Shuffle. Saved app authentications are encrypted in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and the Shuffle configuration docs warn that losing or changing that value breaks all saved app authentications. Set this secret once, store it in your secrets manager, and back it up before the first credential is saved, because a later change will leave every saved app authentication unusable.

What data and integrations move, and what you rebuild

Moving a Tines estate means moving five distinct things, and only some have a documented export path. Stories are rebuilt from their exported definitions, while credentials, webhooks, schedules and audit history each need a separate cutover step. Work through the cards in order and get sign-off from each owner before any trigger switches.

Story definitions are rebuilt

Tines stories do not convert into Shuffle workflows automatically, so each story is a manual rebuild. Use the story files you export from Tines as the specification: list every action, its inputs, its branching and its error handling. Build the matching workflow in Shuffle's editor, then confirm with the story owner that each step does what the original did. Identify any Tines-specific logic early, because it will need an explicit equivalent in Shuffle.

Credentials and API keys re-enter

Saved Tines credentials do not move into Shuffle, so each connection is entered again under its Shuffle app. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Record that secret in your secrets store before the first start, because losing or changing it breaks every saved app authentication. Ask each tool owner to confirm the scope and rotation policy of any key issued for Shuffle.

Webhook endpoints and callers

Each webhook trigger gets a new endpoint in Shuffle, so the URL that callers hold will change. Inventory every caller of each Tines trigger, including SIEM rules, ticketing automations and partner integrations. Run the new endpoint alongside the old one for each caller and switch a caller only after its test passes. The hybrid model's local Orborus needs no inbound firewall ports, but the endpoint that callers hit must still be reachable from them. Confirm with each caller's owner whether they can change a URL, send a secret header or retry failed deliveries.

Schedules are recreated

Schedules are recreated as Shuffle triggers and do not move from Tines. Record each schedule's interval, time zone and the action it runs, using the story file as the source. Disable the original Tines schedule once its Shuffle replacement is live, so the same job does not run twice and open duplicate cases. Confirm with the team that consumes the output whether a missed or late run matters, and check the first few runs against a known input before relying on them.

Event history for audit

Tines event history is not Shuffle execution history, so decide what the audit trail must show before cutover. Pull the Tines events through its events API while the account is still active, and archive them with the story files. Review the paging and payload limits described in Tines's export documentation so the archive is complete. Shuffle keeps its own execution records in OpenSearch, so confirm with your audit or compliance owner how long each record must be retained and where it is stored.

The migration sequence from inventory to decommission

This sequence turns the Tines estate into a tested set of Shuffle workflows, moves triggers over one at a time, and ends with decommissioning only after evidence is captured. Each step produces an artifact that the next step depends on.

Build the story inventory from exports
Export every Tines story as a story file and record each one in a migration register: name, owner, trigger type, schedule, every HTTP request action, the credentials each action uses, and the downstream systems it writes to. Note which stories are live, paused or unused, since only live stories need an immediate rebuild. Use the story files as the specification, and confirm with each owner what the workflow is meant to do today rather than what the story happens to do. The output is a signed-off register with one row per story and a list of the credentials that must be re-entered in Shuffle.
Stand up a sized pilot instance
Install Shuffle on a non-production host using the Docker or Kubernetes path from the install guide. The install guide states a minimum of 4 GB of RAM, and its default Docker Compose setup is not scalable without changes, so size the pilot for the 4 GB minimum and plan the production topology separately. Set the SHUFFLE_ENCRYPTION_MODIFIER secret and store it in your secrets manager before adding any credential, because changing it breaks saved app authentications. The output is a running pilot with the backend, frontend and OpenSearch healthy and a documented encryption secret.
Pick a pilot workflow and rebuild it
Choose one low-risk live story that uses a small number of HTTP actions and a clear outcome, such as enrichment of a lookup value. Rebuild it in Shuffle as a workflow with the same trigger type, branching and output fields, and add the credentials as Shuffle app authentications. Where a required app is missing, check the premade apps first. Run the workflow against test data and compare each output field with the Tines run history. The output is a pilot workflow with a written note of every difference found and how it was resolved.
Generate HTTP actions from OpenAPI specifications
For each HTTP request action that calls a product with a published OpenAPI specification, use the App Creator to build a Shuffle app from that specification instead of hand-writing REST calls. Review each generated action against the Tines request, including method, path parameters, headers, body and authentication. Where no specification exists, write a custom app or use an HTTP action and document it as hand-built so the team knows its maintenance burden. The output is a list of apps, each marked generated, premade or custom, with the owner who reviewed it.
Run Shuffle and Tines in parallel
For each migrated workflow, keep the Tines story live and run the Shuffle version against the same inputs, either in a test queue or with write actions disabled. Compare outputs, error handling, timing and the records created in downstream systems over a period the security owner agrees in advance. Record each discrepancy, classify it as a defect or an accepted change, and fix defects before moving on. The output is a parallel-run log per workflow with a sign-off from the workflow owner.
Cut over triggers one workflow at a time
Move one trigger at a time from Tines to Shuffle, starting with the lowest-impact workflow. Re-create each webhook URL in Shuffle and update the sender, re-create each schedule, and pause the matching Tines story at the same moment so that no event is processed twice. Confirm that Orborus is picking up jobs and that the worker starts the expected app containers. Keep a documented rollback that re-enables the Tines story and reverts the sender. The output is a cutover record per trigger showing the time of change, the verification test and the rollback option.
Capture evidence and decommission Tines
Once every migrated workflow has run in production with its Tines counterpart paused, export the final story files, the run history you need for audit and the migration register, and store them in your own records system. Confirm with your compliance lead which records must be retained and for how long, since that requirement comes from your own obligations rather than from this guide. Revoke Tines API keys and connector credentials, then remove the stories or close the account according to your contract terms. The output is an evidence bundle and a decommission record that names the person who approved closing the Tines tenant.

What drives the cost and duration of the rebuild

This table lists the factors that move labor, infrastructure and testing effort when rebuilding Tines stories in Shuffle, with the reason each one matters and how to keep it down. Read it before requesting a quote, because the same story count can produce very different effort depending on integrations, callers and the hosting design chosen.

Driver	Why it moves effort	How to reduce it
Number of live stories	Each live story needs its own Shuffle workflow, trigger configuration, test run and sign-off. Effort scales roughly with the count of live stories, not with exports you no longer run.	Confirm which stories are live from the exported story files, retire unused ones before rebuilding, and rebuild in priority order.
Distinct HTTP integrations and credentials	Each unique API becomes a Shuffle app or an OpenAPI-based app built in the App Creator. Each credential must be re-entered, and saved authentications are encrypted with SHUFFLE_ENCRYPTION_MODIFIER, so credential handling needs a controlled process.	Inventory endpoints and credentials across all stories, reuse one app per service, and check first whether a premade app already covers the tool.
Custom code and transformation logic	Tines transforms and scripted steps do not carry over automatically. Each custom step must be re-expressed as Shuffle actions or Python app code, which takes design and review time.	Simplify transformations before migrating, move repeated logic into a shared app, and flag stories that depend on custom logic early.
Webhook callers that must be repointed	Every system that posts to a Tines webhook must be changed to the new Shuffle webhook URL. Callers owned by other teams add coordination time and may need change approval.	Build a caller list from logs or configuration before cutover, and agree a cutover date with each owning team.
Schedules and event sources	Scheduled runs and polling triggers must be recreated and their timing checked, since a missed or duplicated run can affect incident handling.	List every schedule in the exports, compare run history, and confirm the timing and time zone of each one in the new platform.
Team testing capacity	Each workflow needs test runs against realistic inputs and a review by someone who knows the expected outcome. Testing often takes longer than building, and it competes with the security team's day job.	Name a test owner per workflow, use sample payloads from event history, and schedule testing windows before switching triggers.
Shuffle hosting architecture	A single server with Docker Compose is a different effort profile from a Swarm, Kubernetes or hybrid design with several Orborus nodes. The Docker Compose default is not scalable without changes and needs at least 4 GB of RAM, according to the Shuffle install guide. High availability adds an OpenSearch cluster, shared files and multiple Orborus nodes.	Decide the architecture before rebuilding, size it against the story count, and avoid redesigning the platform mid-migration.
Infrastructure (recurring)	Servers, storage, OpenSearch capacity, backups and monitoring are paid every month or year and grow with execution volume and retention. This cost is typically owned by platform or infrastructure teams.	Ask for a sizing estimate based on your run volume and retention policy, and compare it with the Tines paid edition you would otherwise buy.
Implementation, support and retainers (mixed)	Rebuild labor is one-time, while ongoing support, upgrades and continuous testing recur. DeployOpen plans and implements under a written fixed scope, and ongoing support is available as a retainer. Shuffle's own licensing is priced on app runs, so check it separately.	Ask for a fixed-scope quote with deliverables listed per workflow, and separate one-time rebuild fees from recurring retainer and licensing lines.

How the migration differs by team size and starting point

A team on the Tines Free edition usually has a short list of live stories, capped at 3 live workflows under the Tines pricing page. The inventory is small enough to rebuild by hand, and the main effort goes into standing up a single Shuffle server and validating each story end to end. Because the Free edition has no paid support path to lean on, the rebuild is also a good moment to document what each story does.

Inventory: Export each story and treat the story JSON as the specification for its actions, edges and credentials.
Infrastructure: A single server with Docker Compose is the simplest of the documented architectures, and the install guide sets a minimum of 4 GB of RAM.
Scalability: The default Compose setup is not scalable without changes, which is acceptable for a few workflows but should be stated in the design record.
Cost driver: Shuffle's open-source edition includes all features, so the main recurring cost is the server and your staff time.
Cutover: Run both platforms in parallel for each story before moving its trigger.

Confirm the current live story count, the exact hosting model in your Tines contract, and whether any story depends on a feature you have not yet mapped.

What usually goes wrong and how to prevent it

Most failed Tines-to-Shuffle migrations break in predictable places: secrets, trigger wiring, branch coverage, runtime layout and the record of what ran. Each card names one failure, the signal that reveals it, and the check to run before switching triggers. Treat these as cutover gates, not clean-up tasks.

Lost app credentials after key change

Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, keyed by the SHUFFLE_ENCRYPTION_MODIFIER secret. If that value is changed or lost during a rebuild, every saved app authentication breaks at once, and a restored database can fail to decrypt. Set the value once in your environment file, store it in your secrets manager, and back it up together with the OpenSearch data. Confirm a restore on a copy before go-live.

Webhooks still pointing at Tines

Tines webhooks and schedules keep firing until someone disables them, so a Shuffle copy can run beside the Tines original and duplicate tickets or actions. Build a table of every trigger from the exported story files, recreate each one in Shuffle, then repoint source systems one at a time. Disable a Tines trigger only after its Shuffle counterpart has produced the expected output across a full cycle of real traffic.

Untested branch edge cases

Tines stories often depend on conditional paths that rarely fire, such as empty fields, missing lookups or an error response from an upstream API. The happy path can look correct in a demo while these branches route differently in Shuffle. Write a test input for each branch in the exported story, replay recorded payloads where you have them, and compare every step's output with the matching Tines run. Record which branch each test covers, and treat any uncovered branch as a blocker.

Production on default Compose

The install guide states that the default Docker Compose setup is not a scalable build without changes, and that Shuffle needs a minimum of 4 GB of RAM. Teams that copy the single-host file into production inherit one host with no spare capacity for workflow runs. Choose the architecture before the build (Compose, Docker Swarm, or Kubernetes with Helm charts), size the host for your peak execution volume, and load test with your heaviest stories.

Silent stalls on one Orborus

Orborus polls the backend for jobs and starts a worker for each workflow execution, so a single Orborus node is a single point of failure. If it stops, executions may queue without an obvious error, and a replacement can look healthy while security actions are delayed. Run more than one Orborus node as the configuration docs recommend, alert on queued or stalled executions, and rehearse a node failure before cutover. Confirm how your Shuffle version surfaces stalled runs.

Gaps in audit history

A story file shows how a workflow was built, but it does not carry the event history of what ran. That gap matters when an incident review asks what an automation did during a past case. Before shutdown, pull Tines event history through the events API and store it with the case records it touches. In Shuffle, confirm how long execution results are retained, then export them to your SIEM or an archive so the record survives the cutover.

Questions teams ask before moving from Tines to Shuffle

How much effort and cost should we expect moving from Tines to Shuffle?

Expect three cost groups: the platform licence, the infrastructure you run it on, and the labor to rebuild your stories. The Shuffle open source article states that all features are available in the open-source edition, and the paid tiers differ in feature limits, scaling and support. The install guide requires a minimum of 4 GB of RAM, and the default Docker Compose setup is not scalable without changes, so production sizing and high availability add infrastructure and operations work. The rebuild is usually a one-time cost that grows with the number of live stories, HTTP actions and credentials. Ongoing costs are hosting, upgrades, monitoring, and support time. Ask any quote to separate one-time migration work from recurring platform and operations costs, and to state the assumptions about story count and complexity.

How long does a Tines to Shuffle migration take?

The timeline depends mainly on how many stories you run, how complex each one is, and how many external systems and credentials they touch. Other drivers include whether you need a highly available layout, which the Shuffle configuration docs describe as an OpenSearch cluster, shared cache and files, and more than one Orborus node, and how much testing and sign-off your change process requires. Each workflow needs parallel runs against real payloads before any trigger moves, so testing often sets the pace more than the build does. No duration is fixed in the sources for this work. Ask for a timeline in the written scope, with milestones for inventory, build, testing, cutover and rollback, and confirm which items the quote assumes you will complete.

What does our team need to provide before a Shuffle migration starts?

Prepare an inventory, access and decisions before work begins. The inventory should list every story, its owner, its triggers and the external tools it calls. Provide story export files so the team can use the exported definitions as the specification. Grant access to the target hosting environment, such as Docker Compose, Docker Swarm, Kubernetes, or the hybrid model with a local Orborus, and document network rules, since the hybrid model needs no inbound firewall ports. Supply a credential owner for each connected system and an approved place to store secrets. Decide the single sign-on approach, noting that the Shuffle extensions docs describe OpenID Connect as the current option and SAML as being deprecated on Shuffle Cloud. Name a business sign-off owner for each workflow.

Can our own team migrate Tines stories to Shuffle without a partner?

A capable platform team can do the migration in-house if it has working knowledge of Docker or Kubernetes, OpenSearch, API authentication and the systems its stories call. Shuffle builds integrations in its App Creator from OpenAPI specifications, and it supports apps written in Python with the Shuffle app SDK, so teams with API documentation have a clear path. The risks are time pulled from on-call duties, uneven testing, and gaps in high availability and backup if no one owns them. Some organizations keep the platform and rebuild in-house but bring in outside help for hardening, backup design or test planning. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted platforms in the client's own infrastructure, under a fixed-scope written agreement.

Does Shuffle's app runs licensing change the cost picture?

Yes, because Shuffle's paid licensing is measured in a different unit than Tines. According to the Shuffle pricing article, the single metric is app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Since v2.1.1, the limits between the open-source and enterprise editions are actively enforced, so confirm the limits in the edition you choose. Tines Free allows 3 live workflows, and its paid editions offer unlimited workflows and flexible deployment options on request, per Tines pricing. To model Shuffle costs, estimate app runs per month from your current execution volume and confirm the figure with Shuffle. Have legal review licensing too: the backend is AGPLv3, while workflows, documentation, apps and app specifications are MIT.

What happens to our Tines data during the move?

Your Tines data stays in Tines until you decide otherwise, so keep the account active through validation and rollback. The story export files are the starting specification, not a live copy of your operations. Credentials do not carry over automatically: each one must be re-entered in Shuffle, where saved app credentials and API keys are encrypted in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. The Shuffle configuration docs warn that losing or changing that secret breaks all saved app authentications, so store it in your secrets manager and back it up with the rest of the platform. Decide the retention period for Tines history and any Shuffle execution records, and align both with your data policies before cutover.

How do we move Tines webhooks and schedules to Shuffle safely?

Run each workflow in parallel before switching any source system to Shuffle. Create the Shuffle trigger for the workflow, send it recorded or test payloads that match production shapes, and compare each action output against what Tines produced. Test schedules by confirming run times and time zones on a non-production instance, then check that scheduled runs do not duplicate work already done in Tines. Only after results match should you repoint the source system, such as a SIEM alert forwarder or ticketing webhook, to the new Shuffle endpoint. Keep the Tines story intact and disabled for a defined rollback window. Move one workflow at a time so a failure has a small blast radius, and log each cutover decision.

What usually breaks when HTTP actions move to Shuffle apps?

The most common failures come from authentication, base URLs, payload shape and error handling, not from the workflow logic itself. Tines HTTP requests often carry headers, token refresh logic or custom parameters that a generic request step does not reproduce automatically. Shuffle apps built from OpenAPI specifications only match the endpoints and parameters in that specification, so check its version against the API your tenant actually runs. Test authentication with each saved credential, confirm TLS certificate trust for internal hosts, and compare pagination and rate-limit behavior. Map every failure path explicitly, because a missing branch can stop an entire investigation silently. Document each app version you pin, since Shuffle apps run as versioned Docker containers.

How DeployOpen scopes and runs the Tines to Shuffle move

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted Shuffle inside your own infrastructure, whether that is your cloud accounts, data center or an isolated network. Most engagements are fixed-scope, which means the story inventory, the workflows in scope, the Shuffle deployment architecture, the integrations to rebuild and the acceptance tests are agreed in writing before work starts. A quote follows from that written scope. DeployOpen does not publish a price list, and it is not an official partner, reseller or certified provider of Shuffle or Tines. Ask for the scope document to name each exported story file, each credential owner and each trigger that will move, because those items drive the effort more than the total count of workflows.

The scope should settle a few decisions before the first build. Choose the deployment architecture from the options Shuffle documents, whether a single server with Docker Compose, Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus, or Kubernetes with Helm charts. High availability, meaning an OpenSearch cluster, more than one Orborus node and shared files for several backends, adds design and run work that a quote should itemize separately. Agree who holds the SHUFFLE_ENCRYPTION_MODIFIER secret, how it is backed up and how it is rotated, since changing it breaks every saved app authentication. Also confirm how SSO will be set up, either OpenID Connect or SAML, and who approves changes to production workflows.

Ongoing support is available as a retainer and typically covers Shuffle upgrades, backups, monitoring, app updates and workflow changes after handover. Ask the provider to show how an upgrade is tested against your workflows before the production tag changes, and which parts of the run book remain your team's responsibility. Independent auditors and certification bodies, not DeployOpen, issue any audit reports or attestations, so ask what control evidence the engagement produces for your assessor and how it maps to your own control framework. Keep the test results and the sign-off record for each switched trigger, because those records are what your reviewers will ask for.

Migrate from Tines to Shuffle