Migrate from FortiSOAR to Shuffle: what the move involves
The move from FortiSOAR to Shuffle is a rebuild of playbooks and integrations followed by a controlled cutover, not a file import. FortiSOAR playbooks, module logic and connector configurations do not translate one to one into Shuffle workflows and apps, so each playbook has to be redesigned, tested and then switched over alert source by alert source. This usually matters most when the renewal, a FortiGuard-tied licence or a data residency requirement is forcing the timeline, because the rebuild, not the software installation, sets the pace.
Most teams carry this out with internal platform or SOC engineering, often with an implementation partner for the first wave of workflows and for the hardening of the Shuffle deployment. Your engineers will know which playbooks are business critical and which are dead code, so they should own the inventory and the acceptance tests. Before committing to a plan, confirm with your team how many playbooks, connectors and custom modules are in use, which of them FortiSOAR connectors have no ready Shuffle app, and who will maintain the resulting apps after go-live. Ask any partner to show how they will test each rebuilt workflow against the same alert before the old one is retired.
On licensing, Shuffle states that all features are available in the open-source edition, and that its paid tiers differ in feature limits, scaling and support, with limits enforced since version 2.1.1. Confirm which of those limits, if any, your planned workflow volume would reach before you design around the open-source edition, and check the current edition terms directly with Shuffle. Plan for the risk that matters most: losing or changing the SHUFFLE_ENCRYPTION_MODIFIER secret breaks every saved app credential, so record and protect it from the first day of the pilot.
Which FortiSOAR capabilities map cleanly to Shuffle
This table maps the main FortiSOAR capabilities to their closest Shuffle equivalents and labels each as clean, needs rework or gap. Read the third column before planning work, since a gap or rework label means you must confirm the behavior in your own environment. The main takeaway is that API-based integrations and SSO map cleanly, while playbook logic, case records, role-based access and multi-tenant layouts need a check against your current FortiSOAR setup.
| FortiSOAR capability | Shuffle equivalent | Fit and what to check |
|---|---|---|
| Playbook building | Visual workflows with triggers, actions and conditional logic | Needs rework. Each playbook is rebuilt as a Shuffle workflow and tested against the same alert samples. |
| Connector catalog | Premade apps for security tools, plus apps you build | Needs rework. Confirm that every connector you use has a Shuffle app or an API you can wrap. |
| OpenAPI-based integrations | App Creator builds apps from OpenAPI specifications, run as versioned Docker containers | Clean for REST APIs that publish a usable OpenAPI specification. Custom code may need the Python app SDK. |
| Case and incident handling | Workflows update external case systems through apps | Gap, confirm. Shuffle does not mirror FortiSOAR record types, so confirm how your incidents and related records will be stored. |
| Multi-tenancy for MSSPs | Per-tenant SSO enforcement and tenant-scoped configuration | Needs rework. Confirm the tenant isolation model in your version against your current FortiSOAR tenant layout. |
| Single sign-on | SAML support since 0.9.16 and OpenID Connect since 1.0.0, on premises and in the cloud | Clean. Confirm that your identity provider and attribute mapping match what FortiSOAR uses today. |
| Role-based access control | Not covered in the documentation reviewed for this page | Gap, confirm. Ask the Shuffle maintainers or test in a lab which roles and permissions your teams need. |
| Scheduled exports and backups | Workflows and settings stored in OpenSearch, backed up with your own tooling | Needs rework. Plan OpenSearch snapshots and workflow exports as your backup routine. |
| Stored credentials and API keys | AES-256 encryption using the SHUFFLE_ENCRYPTION_MODIFIER secret | Clean, with an operational rule. Losing or changing the modifier breaks every saved app authentication, so store it securely. |
What data and integrations move, and what you rebuild
A FortiSOAR to Shuffle move carries the inventory across cleanly but rebuilds most of the logic. The cards below separate what the Configuration Export gives you as a starting point from what must be authored again, reconfigured or exported separately.
Configuration Export as the inventory
The FortiSOAR Configuration Export wizard is your starting list of playbooks, modules and connector settings. Treat it as the source of truth for scope, not as a file you can import into Shuffle. Each playbook, module and connector in the export should map to a line in your migration inventory with an owner, an alert source and a target Shuffle workflow or app. Check the export against a live review of what is actually triggered in production, since some playbooks may be dormant and others may be called only by other playbooks.
Playbooks rebuilt as Shuffle workflows
Each FortiSOAR playbook is re-authored as a Shuffle workflow. The step logic, branching, loops and variable handling do not transfer as a direct file conversion, so each workflow needs a test run against sample alerts. Plan for playbooks that call other playbooks, since those chains must be rebuilt in a deliberate order. Record the expected output of each step before you rebuild it, so the Shuffle version can be compared against the FortiSOAR run.
Connector settings become Shuffle apps
FortiSOAR connectors do not carry over as-is. Each one needs a matching Shuffle app, either a premade app or one built in the App Creator from an OpenAPI specification, or written in Python with the app SDK. Confirm that every connector action your playbooks use exists in the target app, and that the app version you pin is the one you tested. Where a connector has no premade app, the build effort becomes part of the migration scope and should be priced in the written plan.
Saved credentials and the encryption modifier
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the value of SHUFFLE_ENCRYPTION_MODIFIER. Losing or changing that value breaks every saved app authentication. Do not copy FortiSOAR credential values across, and do not attempt to decrypt anything from FortiSOAR. Generate the modifier in your target environment, store it in your secrets manager, back it up with the database, and plan to re-enter each credential against the rebuilt apps.
Records and case history stay behind
Incident records, case history, comments and attachments are not part of the Configuration Export. Decide per record type whether it is archived read-only, exported through a separate process and reloaded into a case store, or left in FortiSOAR until its retention period ends. Confirm with your compliance owner which records must remain retrievable and for how long. Test any reload with a sample set first, because linked records and timestamps often break in transit.
Licensing, SSO and access roles
Shuffle has no per-user licensing that follows you across the move, but its feature limits and app run metering depend on the edition you run, so confirm them before the design is locked. Access controls also need rebuilding. FortiSOAR roles and permission sets do not map one to one, so define the Shuffle roles and configure SSO with SAML or OpenID Connect against your identity provider. Confirm which SSO method your deployment version supports before you plan the cutover.
The migration sequence from inventory to decommission
This sequence moves FortiSOAR playbooks, connectors and case handling onto Shuffle in controlled stages, so each alert source changes over only after the replacement workflows have been tested. Each step produces a written artifact that the next step depends on.
Export and inventory the FortiSOAR configuration
Run the Configuration Export wizard in FortiSOAR to capture playbooks, modules and connector settings, then store the export as a versioned backup. Your security engineering lead builds a migration inventory from it, listing every playbook, the connectors each one calls, the trigger that starts it and the owner who relies on it. Records and case data are not part of this export, so list them separately with their volumes and retention needs. The step is done when every playbook and connector appears in the inventory with a named owner and a priority label.
Stand up a pilot Shuffle deployment
Deploy Shuffle in a non-production environment using Docker or Kubernetes, following the install guide. The default Docker Compose setup is not a scalable build without changes, and Shuffle needs a minimum of 4 GB of RAM, so size the host with headroom for OpenSearch and worker containers. Configure the SHUFFLE_ENCRYPTION_MODIFIER secret and record it in your secrets store before saving any app credentials, because losing or changing it breaks every saved app authentication. The step is done when the pilot runs a test workflow end to end and the deployment record, including the chosen architecture and version tag, is approved.
Build connectors as Shuffle apps
For each FortiSOAR connector in the inventory, check whether Shuffle ships a premade app for that tool. Where none exists, generate one from the vendor's OpenAPI specification in the App Creator, or write it with the Shuffle app SDK. Test each app against a sandbox or read-only account of the target system, and store the credentials under the pilot's encryption setting. Connectors that cannot be reproduced are logged as gaps with an agreed compensating process. The step is done when every inventory connector maps to a tested app or a documented gap.
Rebuild and test priority playbooks
Rebuild the highest-priority playbooks as Shuffle workflows, starting with those that handle the most alert volume or carry the most compliance weight. Replay historical alerts or sample events through each workflow, then compare the actions taken, the case updates and the outputs with what FortiSOAR produced for the same input. Record every difference and decide whether it is an improvement, an accepted change or a defect to fix. The step is done when the priority workflow set has passed the agreed replay comparison and a named approver has signed off each one.
Move case data and run both platforms in parallel
Export the open and recent cases you need from FortiSOAR and load the relevant history into your chosen case store, keeping an archive of the originals for retention. Then connect the same alert sources to both FortiSOAR and Shuffle so each receives identical events. Compare the workflow runs, ticket creation and enrichment results daily, and track any alert that one platform handled and the other missed. Keep Orborus and backend health under watch, and plan a second Orborus node if workflow continuity matters during failures, as the configuration docs recommend. The step is done when a defined run period passes with no unexplained divergence between the two platforms.
Cut over one alert source at a time
Switch each alert source from FortiSOAR to Shuffle individually, starting with the lowest-risk source, and disable the matching FortiSOAR trigger only after the Shuffle trigger is confirmed working. Keep a rollback path for each source by leaving the FortiSOAR trigger documented and recoverable until the source has run cleanly on Shuffle. Update runbooks, on-call contacts and escalation paths for each switched source. The step is done when a signed cutover checklist exists for every source, showing the change date, the test evidence, the rollback option and the approver.
Decommission FortiSOAR and retain evidence
After every source has run on Shuffle through your agreed observation period, take a final export and archive of FortiSOAR configuration, playbooks and case records under your retention policy. Confirm with your procurement and licensing contacts how the FortiSOAR subscription or license ends, and remove access for users, integrations and service accounts. Check with your auditors which evidence they expect to see for the change, such as the cutover checklists and archived exports. The step is done when the FortiSOAR environment is shut down, its archive is verified, and the decommissioning record is filed.
How to run FortiSOAR and Shuffle side by side
Keep FortiSOAR live and Shuffle live at the same time, but give each alert source exactly one owner at any moment. The single most common overlap failure is two platforms acting on the same alert: both create a ticket, both block the same indicator, or both send the same notification. Before you enable any Shuffle workflow against a live source, record which FortiSOAR playbooks currently trigger from that source, then disable the matching FortiSOAR trigger only when the Shuffle workflow is confirmed for that source. Where a destructive action such as account disablement or host isolation is involved, keep it behind a manual approval step in one platform until the other has been proven on the same alerts.
Compare outcomes on the same alert rather than trusting that a workflow runs. Replay a sample of historical alerts through the Shuffle workflow in a test tenant, or mirror a source into a non-production Shuffle workspace, and compare the action taken, the enrichment fields returned by each connector or app, the case or ticket created and the timestamps. Shuffle's architecture has a frontend, a Go backend API listening on port 5001, an OpenSearch document database, and Orborus, which polls the backend for jobs and starts a worker for each workflow execution that then launches app containers. During the overlap, watch the backend and OpenSearch health, the Orborus nodes (the configuration docs recommend more than one for resilience), queued or failed executions, and the disk and memory of the host running app containers. Confirm the SHUFFLE_ENCRYPTION_MODIFIER value is backed up in both environments before any credentials are re-entered, because changing it breaks saved app authentications.
Keep FortiSOAR read-only once its alert sources are cut over, but do not decommission it yet. Disable new playbook execution and scheduled jobs, remove or disable integrations that could write to downstream systems, and restrict write access to administrators, so incident history stays intact for investigations and audits. Confirm with your compliance and legal teams how long FortiSOAR records must remain retrievable and whether a final export is required before any licence or subscription ends. Record the cutover date for each source in your migration log so that any alert can be traced to the platform that handled it.
How the migration differs by starting point
A single SOC with a small playbook set usually has the shortest path. The inventory from the Configuration Export is short enough to review line by line, and most effort goes into rebuilding a handful of playbooks as Shuffle workflows and replacing the connectors they call with Shuffle apps. Because there is one tenant and one set of analysts, the main question is which playbooks justify rebuilding and which can be retired.
- Playbook triage: Sort playbooks into active, rarely used and obsolete before rebuilding anything.
- Connector mapping: Check each FortiSOAR connector against a Shuffle app, and note gaps that need an app built from an OpenAPI specification.
- Credentials: Plan to re-enter app credentials in Shuffle, since saved authentications are encrypted with the
SHUFFLE_ENCRYPTION_MODIFIERsecret. - Parallel running: Keep FortiSOAR active until each alert source is switched to Shuffle.
- Confirm with your team: Ask who owns each workflow after cutover and whether analysts can maintain Shuffle workflows without DeployOpen or a vendor.
Confirm the number of live playbooks and connectors in your own export before estimating any effort.
An MSSP moves customer-specific playbooks, connector settings and case data for many tenants, so the inventory multiplies. Each customer's playbooks may share common logic but differ in credentials, endpoints and approval steps. Shuffle's app and workflow model does not map one-to-one to FortiSOAR's multi-tenant structure, so the design of tenant separation must be settled before rebuilding begins.
- Tenant model: Decide how customer separation will work in Shuffle and how SSO enforcement per tenant will be configured, using the OpenID Connect path the docs describe.
- Shared templates: Identify common playbooks that can become reusable workflows, and avoid copying them customer by customer.
- Credential isolation: Verify how saved app credentials are scoped per customer before importing any of them.
- Licensing: Confirm with Shuffle how app runs are counted across tenants, since the pricing article ties licensing to executed actions.
- Operational ownership: Agree in writing which team maintains each customer's workflows after cutover.
Treat tenant separation as a design decision to verify, not an assumption carried over from FortiSOAR.
In a restricted network, the migration depends on what can be brought in and how updates arrive. Shuffle runs from container images, and the apps and workflows that depend on external services need to be checked against the network rules. A FortiSOAR move also changes how licensing is handled, so the export and transfer process must respect the approval rules of the environment.
- Image mirroring: Plan how Shuffle container images and app containers reach the closed network, and who approves each transfer.
- Outbound calls: List every playbook step that calls an external API, since those steps will fail offline unless the target is internal.
- Updates: Define how Shuffle releases, such as those tagged in its GitHub releases, are reviewed and imported.
- Hybrid option: Confirm whether the hybrid architecture, which needs no inbound firewall ports, is permitted, because it still depends on a cloud component.
- Data handling: Confirm where exported FortiSOAR data is stored during transfer and who can access it.
Confirm with your security and network teams which Shuffle architecture and update path are permitted before planning cutover dates.
The deployment shape sets the effort and the operating burden. Shuffle documents a single server with Docker Compose, distributed Docker Swarm, a hybrid model and Kubernetes with Helm charts. The install guide notes that the default Docker Compose setup is not a scalable build without changes and needs a minimum of 4 GB of RAM. Choosing a high availability design adds OpenSearch clustering, shared cache and file storage, and several Orborus nodes.
- Single Compose server: Lowest setup effort for a pilot, but it needs changes before it can be considered scalable.
- Swarm or Kubernetes: Adds orchestration work, and your team must operate the cluster after cutover.
- OpenSearch cluster: Plan for a clustered document database, which the configuration docs recommend for high availability.
- Shared services: Account for Memcached and NFS if several backends run, along with the storage design they require.
- Multiple Orborus nodes: Run more than one node so workflows keep executing if one fails, and size each node for its workload.
Confirm your expected alert volume, uptime needs and in-house container skills before choosing the architecture, and review the architecture documentation against them.
What drives the cost and duration of the move
This table lists the factors that change the effort of moving FortiSOAR playbooks and records to Shuffle, why each one matters, and how to keep it manageable. Use it to shape a written scope before comparing quotes, since most of the cost sits in rebuilding and testing rather than in the software itself.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of playbooks | Each playbook is rebuilt as a Shuffle workflow and tested, so effort grows with the count and with branching logic. | Retire unused playbooks during the export inventory and rebuild only what is still in use. |
| Number of connectors | Each FortiSOAR connector must be matched to a Shuffle app, either a premade app or one built from an OpenAPI specification. | Map connectors to existing Shuffle apps first and list only the gaps for custom work. |
| Custom connector code | Custom code needs a Python app built with the Shuffle SDK or an OpenAPI-based app, plus security review of its credentials. | Confirm early which custom integrations are essential and whether an OpenAPI description already exists. |
| Case history volume | Moving old incident records is a data mapping and validation exercise, and volume drives import time and reconciliation work. | Decide with stakeholders which closed cases must move, and archive the rest in the FortiSOAR export. |
| Alert sources to repoint | Each SIEM, mail or ticket source must be switched to Shuffle triggers, and each switch needs its own test window. | Group sources by owner and cut them over in batches, with rollback steps written for each. |
| SSO and access requirements | Shuffle supports SAML and OpenID Connect, but configuring identity provider trust, group mapping and per-tenant enforcement adds design work. | Agree the identity model before rebuilding, and confirm which SSO method your identity provider supports. |
| High availability requirements | Shuffle recommends an OpenSearch cluster, shared files for several backends, and more than one Orborus node, which adds build and test effort. | Define the availability target in writing and confirm whether a single-server design is acceptable for the first phase. |
| Encryption key handling | Saved app credentials are encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing it breaks every saved authentication. | Store the secret in your approved secrets manager and include re-entry of credentials in the test plan. |
| Staff familiarity | Analysts who know FortiSOAR playbook logic need time to learn Shuffle's workflow model, which affects review speed and defect rates. | Pair analysts with the rebuild team and include training and sign-off in the scope. |
| Recurring costs after cutover | Infrastructure, OpenSearch and backend upkeep, Shuffle version upgrades, app updates and workflow maintenance continue after go-live. | Ask for a written upgrade and maintenance plan, and confirm who owns workflow changes after handover. |
What usually goes wrong and how to prevent it
Most failed FortiSOAR-to-Shuffle moves fail in predictable places: secrets, runtime design, parallel running and ownership. The cards below pair each risk with a prevention step you can check before cutover, so the migration does not stall after the first alert source is switched.
Losing the encryption modifier
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. If that value is lost or changed during a redeploy, every saved app authentication breaks at once. Store the value in your secrets manager before the first install, keep it identical across every backend and Orborus node, and test one authenticated app action after each restart or upgrade.
Duplicate actions during parallel running
While FortiSOAR and Shuffle both receive the same alerts, a ticket block, containment action or notification can run twice. This is most dangerous when both platforms call the same firewall, EDR or ticketing API. Before enabling any shared source, list which actions are side-effecting, disable them in one platform, and confirm which system owns each alert type during the overlap window.
Docker Compose as a production build
The default Docker Compose setup is not a scalable build without changes, so a single-server install can look fine in testing and fail under real alert volume. Decide early between Docker Swarm, Kubernetes with Helm, or the hybrid architecture with a local Orborus, and size the host against the stated minimum of 4 GB of RAM. Ask for a written load test on the chosen layout before any production alert source is connected.
Single Orborus node failure
Orborus polls the backend for jobs and starts a worker for each workflow execution. With one Orborus node, a crash or host failure stops every running workflow, including containment steps that were midway through. The Shuffle docs recommend more than one Orborus node, along with an OpenSearch cluster and shared storage for multi-backend setups. Test a forced node stop during a live workflow and confirm that the surviving node picks up the work.
Missing logic found after cutover
FortiSOAR playbooks often contain branches, error handlers and timing rules that no one wrote down, and these surface only when a rare alert arrives after the switch. Compare each rebuilt Shuffle workflow against the exported FortiSOAR playbook step by step, including conditions that were never triggered in the last year. Keep the FortiSOAR playbook readable and reachable until each alert type has run correctly in Shuffle for a full operating cycle.
Unowned workflow maintenance
A migrated workflow library with no named owner drifts quickly: app versions change, API tokens expire and nobody knows which workflow depends on which app. Assign an owner to each workflow and each app, record the source of every custom app built in the App Creator, and agree who reviews changes before they reach production. Ask your implementation partner to document this ownership model as part of the handover, not after it.
Questions teams ask before moving from FortiSOAR to Shuffle
How much effort does a FortiSOAR to Shuffle migration take?
Effort depends mostly on how many playbooks you run, how many connectors they call, and how much custom logic sits inside them. Each playbook has to be rebuilt as a Shuffle workflow, and each FortiSOAR connector needs a matching Shuffle app, either a premade app or one built from an OpenAPI specification in the App Creator. Playbooks that only call a few common security tools are usually the quickest to move. Playbooks with heavy scripting, many branches or unusual data mapping take longer to re-test. Ask for a written inventory from the Configuration Export before any estimate, because the count of playbooks, modules and connector settings is what turns into a scoped plan.
How long does the migration take and what sets the timeline?
The timeline is set by the inventory, the number of alert sources to switch, and how much testing your SOC requires before cutover. Running FortiSOAR and Shuffle side by side is normal, so the switch of each alert source can happen in stages rather than all at once. Connector gaps, approval steps for production changes and the availability of your own staff for testing are the usual delays. No duration is fixed here, so ask for a fixed-scope plan with milestones and a written list of assumptions before committing to dates.
What does the work require from our team?
Your team needs people who understand your current playbooks, your alert sources and your incident response process, plus someone who can own Shuffle after go-live. On the platform side, Shuffle runs on Docker or Kubernetes, and its install guide says the default Docker Compose setup is not a scalable build without changes and needs a minimum of 4 GB of RAM. Planning for OpenSearch, backups and the encryption modifier secret is also part of the work. Confirm who will approve test runs, who signs off on the new workflows and who receives alerts during the parallel period.
Can we migrate FortiSOAR to Shuffle ourselves?
Some teams can do parts of the work in-house, especially the inventory and simple playbooks, but the rebuild of complex playbooks, connector replacement and secure configuration usually require experienced automation engineers. DeployOpen plans, implements, customizes, integrates and hardens self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. A useful first step is to score your playbooks by complexity and connector use, then decide which ones your team can rebuild and which need outside help.
Do our incident records and case data move to Shuffle?
Playbooks and configuration are the parts you rebuild, but historical incident records are a separate question that needs its own decision. The FortiSOAR Configuration Export captures playbooks, modules and connector settings, and it does not treat records as part of the same migration path. Decide early whether closed records stay read-only in FortiSOAR for an agreed retention period, or whether selected fields are exported to another store. Confirm that retention, legal hold and access rules are covered before you decommission FortiSOAR.
What happens to our FortiSOAR licensing and Shuffle app runs?
FortiSOAR licensing is tied to FortiGuard entitlements and sized by users and nodes, so it should be reviewed against your renewal date before you plan the cutover. Shuffle's open-source edition includes all features, and its paid tiers differ in feature limits, scaling and support. Shuffle's pricing article says licensing is measured on app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted, and that users, apps and workflows are unlimited. Ask Shuffle to confirm how your expected volume maps to the enterprise limits, and check whether your use needs those paid tiers at all.
How do we confirm Shuffle covers our FortiSOAR connectors?
Map each FortiSOAR connector your playbooks call to a Shuffle app, then mark it as premade, built from an OpenAPI specification, or missing. Shuffle ships premade apps for many security tools and its App Creator builds integrations from OpenAPI specifications, while custom apps can be written in Python with the app SDK and run as versioned Docker containers. Check the exact app versions, the authentication methods each app supports and the actions your playbooks use, not just the product name. Any connector without a clear match becomes a build item in the plan, and its owner and test cases should be recorded before cutover.
How DeployOpen scopes and runs a FortiSOAR to Shuffle migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a FortiSOAR to Shuffle migration, that means DeployOpen works in your environment on the Shuffle deployment you choose, whether that is a single server with Docker Compose, Docker Swarm, a hybrid with a local Orborus, or Kubernetes with Helm charts. Most engagements are fixed-scope, so the systems in scope, the deliverables and the timeline are agreed in writing before any work starts. A quote follows from that written scope, and DeployOpen does not publish a price list. Ask for the scope to name the specific FortiSOAR playbooks, modules, connectors and alert sources included, since those drive most of the effort.
The work usually runs in phases. An inventory phase takes the Configuration Export from FortiSOAR and turns it into a list of playbooks, connectors and modules, with a decision recorded for each: rebuild as a Shuffle workflow, replace with a Shuffle app built from an OpenAPI specification in the App Creator, or retire. A pilot phase rebuilds a small set of representative playbooks and proves the Shuffle app credentials and the SHUFFLE_ENCRYPTION_MODIFIER secret are handled correctly, because losing or changing that secret breaks every saved app authentication. The parallel-run phase keeps FortiSOAR active while alert sources are switched to Shuffle one at a time, with DeployOpen supporting the cutover and the rollback plan for each source.
Once the migration closes, the operating model matters more than the build. Ask for the hardening, backup and documentation deliverables to be listed explicitly, including OpenSearch backups, the secret handling procedure and the runbook for adding Orborus nodes for high availability. Retainers cover ongoing upgrades, such as moving between Shuffle releases, and continuous testing of the workflows and apps your team depends on. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, so any audit evidence needs to come from your independent auditor or certification body.
