Migrate from ThreatConnect to OpenCTI

Migrate from ThreatConnect to OpenCTI: what the move involves

Moving from ThreatConnect to OpenCTI is a data model and integration project, not a file copy. Indicators, groups and their ownership move only once you have decided how ThreatConnect owners, tags and associations map to OpenCTI's STIX 2 objects, organizations and markings. Teams usually start this work when a renewal, a licensing change, a data residency requirement or a lock-in concern makes the current platform harder to justify, and the question becomes what the replacement must carry over. The work is normally run by an internal platform or cyber threat intelligence team, often with an implementation partner for the infrastructure, connector and migration scripting. Effort and risk depend mostly on how much logic lives in ThreatConnect playbooks and custom fields, and on how many feeds and SIEM or blocking integrations depend on the current exports. Confirm the exact export scope and data owners you are permitted to pull with your ThreatConnect administrator before estimating timelines, and confirm the OpenCTI version and connectors you plan to run against the vendor's current documentation. OpenCTI Community Edition is licensed under Apache 2.0, and its Enterprise Edition features, including audit logs, playbooks, organization-based segregation and SSO options, are licensed separately under the OpenCTI Enterprise Edition License. Decide early which of those features your access model requires, because segregation and playbooks determine how you rebuild ThreatConnect owners and automation. Review the OpenCTI Enterprise Edition documentation and get the license terms in writing before you design around them.

Which ThreatConnect capabilities map to OpenCTI, and where the gaps are

This table maps the main ThreatConnect capabilities to their closest OpenCTI equivalent and labels each as clean, needs rework or gap. Use it to decide which items move directly, which need reshaping, and which need a separate tool or an environment check before you commit to a cutover plan.

Capability	OpenCTI equivalent	Status and what to confirm
Indicators	STIX 2 indicators and observables in the knowledge graph, queryable through the GraphQL API	Clean for common types. Confirm that every indicator type and custom field you use has a STIX 2 counterpart in your export.
Groups (reports, incidents, campaigns)	Reports, incidents, campaigns and grouping objects linked to indicators	Needs rework. Map each ThreatConnect group type to a STIX object type and agree the mapping with analysts before import.
Owners (organizations, communities, sources)	Organizations and identities, with organization-based segregation in Enterprise Edition	Needs rework. Confirm which segregation features your license includes, since the Enterprise Edition documentation lists organization-based segregation.
Tags and sharing rules	Labels and marking definitions (TLP and custom markings)	Needs rework. Tags do not carry over as access controls by default, so define markings and check who can see which objects after import.
Associations and relationships	STIX relationships between objects in the knowledge graph	Clean for most links. Confirm that custom association types export cleanly and decide which ones become relationships and which become labels.
Playbooks and automation	Playbooks in OpenCTI Enterprise Edition, or a separate automation tool	Gap for complex logic. Confirm each playbook's triggers and actions in your environment and plan a separate tool where OpenCTI playbooks do not cover them.
Case management	Incident response objects, with case handling covered in a separate topic	Gap in scope. Confirm whether your cases, tasks and artifacts need a dedicated case management tool.
TAXII sharing	TAXII 2.1 server and STIX 2 export	Needs rework. Confirm that each partner's TAXII client, collection names and authentication work against your new server before retiring the old feed.
Integrations and dashboards	Connectors for MISP, TheHive and MITRE ATT&CK, plus dashboards in the web application	Needs rework. Each SIEM, firewall or blocking integration needs a separate connector or script, and dashboards must be rebuilt.

How ThreatConnect owners, tags and groups become OpenCTI organizations and markings

Document the owner-to-organization mapping before any import runs. ThreatConnect scopes data by owner, meaning the organization, community or source that created an indicator or group, and it uses tags and group membership to describe context. OpenCTI has no direct equivalent of that owner model. Its closest concepts are identities (the organizations and individuals recorded as creators or targets), marking definitions (the handling rules attached to each object, such as TLP levels or custom statements), and, in the Enterprise Edition, organization-based segregation, which controls which users can see which objects. Build a table with one row per ThreatConnect owner and columns for the OpenCTI identity, the marking definitions to apply, the segregation organization, and the owner's sharing rules. Tags should be split into two groups: those that become labels or taxonomy-style entries and those that should become markings. Review the table with your intelligence leads and compliance owner before writing any code.

Access segregation is the point where the migration carries the most risk. Organization-based segregation is listed among the OpenCTI Enterprise Edition features, and the Community Edition does not provide it, so confirm the edition and license you will run before you rely on it for separating partner or community data. Do not copy ThreatConnect sharing decisions across. Each sharing permission has to be re-derived from the agreement that justifies it, such as a membership terms document, a TLP designation or a data sharing agreement, and then expressed as an OpenCTI marking and organization assignment. Where a ThreatConnect owner cannot be matched to a clear basis for sharing, mark the data as restricted and hold it back from the first import. Test the result with a small set of users from each organization and confirm that they see only what the mapping allows.

Treat the mapping as a controlled artifact with an owner, a version and a sign-off record. Record every ThreatConnect owner, tag and group that is exported, the target OpenCTI object for each, and any items that were excluded or deferred. This record also supports later audits of who could see which intelligence. Ask the vendor or implementation partner to show how the chosen OpenCTI version handles markings and segregation in your edition, and confirm this against your own test environment rather than relying on the product description alone.

What to export from ThreatConnect and what to rebuild in OpenCTI

Migration runs in two directions: pulling objects out of ThreatConnect and reconnecting everything that depends on them. The cards cover the documented export routes first, then the consumers, connectors and user identities that must be rebuilt in OpenCTI. Confirm each export path with ThreatConnect and each rebuilt component with OpenCTI before you agree on scope.

Indicators and groups through the v3 API

The ThreatConnect v3 API is the documented route for pulling indicators and groups out of your instance. Exports are paginated, so a full pull is a loop of requests, and you should record the last page and timestamp for each object type so an interrupted run resumes cleanly. Request associations and tags explicitly, since they are not always part of the default object. Confirm which owners your API user can read, because the export only covers what that user can see. Test with one owner before a full run.

TAXII 2.1 as the interoperable route

Where ThreatConnect exposes a TAXII 2.1 server, any TAXII client can read the collections it publishes, which makes it the standards-based path into OpenCTI. OpenCTI structures its data on STIX 2, so STIX 2 bundles are the natural payload. Confirm with ThreatConnect which collections your account can subscribe to, and whether each one carries relationships and markings. A feed that delivers objects without relationships will import as flat records.

Feeds for SIEM and blocking

Indicator feeds that drive SIEM rules, firewall blocklists and EDR watchlists sit outside the intelligence store, so they stop when ThreatConnect stops publishing them. Inventory every consumer, its input format and its refresh schedule before cutover. In OpenCTI, rebuild outbound feeds through export connectors or stream consumption, then test each consumer against a known indicator. Confirm which consumers accept STIX 2 directly and which need a converter.

MISP, TheHive and ATT&CK connectors

OpenCTI documents connectors for MISP, TheHive and the MITRE ATT&CK framework. Decide which of these you need on day one: MISP if community sharing continues there, TheHive if case work stays in that tool, and the ATT&CK connector if you want the framework loaded instead of maintained by hand. Check whether your ThreatConnect tags already carry ATT&CK technique IDs, and map them to the framework objects so detections keep their context.

User identities through SSO

Recreate users only where access is still needed, and connect sign-in before importing data. OpenCTI's Enterprise Edition documents SSO options for OpenID, LDAP, SAML, certificate and header authentication. Confirm with Filigran which of these are available under your edition and license. Map ThreatConnect roles and organization membership to OpenCTI groups and organizations, so access follows the same boundaries you had before.

Raw archive and reconciliation

Keep the raw JSON from every export as an archive, separate from the imported data, so you can re-run an import or answer a question about the source record later. Compare object counts per type and per owner between ThreatConnect and OpenCTI after each import, and document every gap you accept. Keep ThreatConnect read access until the reconciliation is signed off by the data owners, and confirm your retention obligations for the archive with your compliance lead.

The migration sequence, step by step

The sequence moves ThreatConnect indicators, groups and playbook logic into OpenCTI in controlled stages, with each stage closing on a written deliverable that both sides can check before the next one starts.

Inventory ThreatConnect data and owners
The provider's team catalogs indicators, groups, tags, owners, associations, sources and active playbooks in your ThreatConnect tenant, and you confirm which owners your API credentials are permitted to export. The step closes with a data inventory that lists volumes by object type, owner and sharing status, plus a list of playbooks and integrations that depend on the platform. Ask the vendor to name every object type that will be excluded and the reason for each exclusion.
Define the target OpenCTI environment
Your infrastructure team and the provider agree on where OpenCTI runs and how it is sized against the documented dependencies: Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO. The team also decides which release line to use, regular or LTS, and confirms the LTS license requirement if LTS is chosen. The step closes with a signed architecture note and an installed, empty OpenCTI instance with SSO configured, so pilot imports land in a platform your identity controls already govern.
Run a pilot import
The provider exports a bounded subset, such as one owner's indicators and one group, through the ThreatConnect API and loads it into OpenCTI using the agreed transformation scripts. Analysts check that object counts, relationships and timestamps arrived as expected. The step closes with a pilot report that records errors, skipped objects, rejected fields and the effort needed to fix each issue, which becomes the basis for changing the mapping.
Validate the mapping specification
Using the pilot findings, the team finalizes the mapping spec that links ThreatConnect owners to OpenCTI organizations, ThreatConnect tags and sharing settings to OpenCTI labels and markings, and ThreatConnect indicator types to STIX 2 objects. Data owners sign off on each rule, including which markings restrict access and who may view each organization's data. The step closes with an approved mapping specification that any later import must follow, with no ad hoc changes.
Execute the parallel run and reconcile
Full imports run into OpenCTI while ThreatConnect stays live, and feeds, connectors and analyst workflows continue on both platforms for a period agreed in the scope. The provider compares counts, sample records and enrichment results between the two systems and logs every difference. The step closes with reconciliation results that classify each mismatch as fixed, accepted with a documented reason, or still open, so the cutover decision rests on evidence rather than assumption.
Rebuild playbooks and sign the cutover checklist
Playbook logic that ThreatConnect ran is either rebuilt with OpenCTI playbooks or moved to a separate automation tool, then tested against the parallel-run data. Your team repoints SIEM, blocking and sharing integrations to the new platform and confirms each one in a test window. The step closes with a signed cutover checklist that lists every integration, its owner, its test result and the named approver who accepts the switch.
Decommission and archive the ThreatConnect export
After cutover, the final full export from ThreatConnect is stored in encrypted storage under your retention policy, with its hash and the export log recorded. Read-only access is kept only as long as your records obligations require, and API credentials and integrations on the old platform are revoked. The step closes with an archived export, a decommission record signed by the data owner, and a handover document covering OpenCTI operations, upgrades and support.

Replacing ThreatConnect playbooks with OpenCTI or a separate automation tool

Treat playbook replacement as a separate workstream, because OpenCTI does not automatically take over what ThreatConnect playbooks do. OpenCTI Enterprise Edition includes playbooks, and OpenCTI has connectors for enrichment, import and export, so some ThreatConnect automations will map cleanly. Many others chain steps across a SIEM, a ticketing system, an EDR console or a blocking device. Start by exporting the list of playbooks from ThreatConnect and recording, for each one, its trigger, every action it takes, the external systems it calls, and who owns it. Playbooks that only enrich indicators or push them to a feed are usually the easiest to move. Playbooks that open tickets, isolate hosts or update blocklists need an owner in the target system before they can be retired.

For each playbook, choose one of three outcomes: an OpenCTI playbook, a connector or a separate SOAR tool. Use an OpenCTI playbook when every step operates on STIX objects inside OpenCTI and the Enterprise Edition features in your license cover it. Use an existing or new connector when the job is a scheduled import, enrichment or export to a defined target. Choose a separate SOAR platform, covered on the SOAR pillar, when the workflow needs branching logic, human approval or actions in systems outside the intelligence platform. Record the decision in a table so the security operations team can see which automations moved, which were rebuilt and which were dropped on purpose.

Confirm feature coverage against the current OpenCTI Enterprise Edition documentation and the connector catalog before you commit to a design, since both change between releases. Check the playbook trigger types, the actions available, and whether the connectors you need are maintained for the OpenCTI version you will run. Ask Filigran or your implementation partner to demonstrate each playbook you intend to rebuild using test data, and run the old and new versions side by side for a defined period. Any playbook that cannot be reproduced with confidence should go into a written risk register with a named owner, rather than being left running on the ThreatConnect side without a plan.

What drives cost and duration in this migration

This table lists the cost components of moving from ThreatConnect to a self-hosted OpenCTI platform, who is paid for each, and what pushes effort up or down. Use it to structure a written scope and to check that each quote covers the same components.

Driver	Why it changes cost or effort	What to ask for in a quote
Owners, sharing communities and sources	Each ThreatConnect owner maps to an OpenCTI organization, marking or group, and each sharing relationship needs its own access design and testing.	A written owner-to-organization mapping, the marking definitions used, and the testing plan for segregation.
Indicator volume and history	Large indicator sets and multi-year history take longer to export through the v3 API or TAXII 2.1, transform into STIX 2 objects and validate in the graph.	The export method, batch sizes, the number of record types to convert, and how deduplication and rejected records are reported.
Playbooks to rebuild	Each ThreatConnect playbook must be redesigned in OpenCTI playbooks or in a separate automation tool, and playbook logic is often the largest unknown.	An inventory of playbooks with the decision for each: rebuild in OpenCTI, move to another tool, or retire.
Integrations and connectors	SIEM, blocking, enrichment and ticketing feeds that read from ThreatConnect must be repointed. OpenCTI has connectors for MISP, TheHive and MITRE ATT&CK, and other integrations may need custom work.	A list of every consuming system, the connector or API method for each, and who tests the output.
OpenCTI infrastructure	The platform, Elasticsearch or OpenSearch, Redis, RabbitMQ, MinIO and Python workers each need hosting, storage and patching. Documented minimums are 2 cores and at least 8 GB RAM for the platform, 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch, and at least one platform node for every 3 workers (OpenCTI deployment overview).	Sizing for your expected indicator volume, the hosting model, backup and high availability design, and who operates each component after handover.
LTS license and upgrade cadence	OpenCTI LTS releases need a specific LTS license key, appear every 6 months and are supported for 1 year (OpenCTI product life cycle docs). Staying current is a recurring task that needs a named owner.	Whether the license key is included, the LTS line you will run, and the cost and effort of planned upgrades each year.
Enterprise features	Audit logs, playbooks, organization segregation, SSO and AI insights are Enterprise Edition features under a separate license, while Community Edition is Apache 2.0 (OpenCTI Enterprise Edition docs).	Which edition each feature requires, the license terms, and whether the quote separates Community and Enterprise costs.
Analyst retraining	Analysts used to ThreatConnect workflows need time to learn the OpenCTI knowledge graph, case handling and new query methods, which affects productivity during cutover.	A training plan with hours per role, cutover support, and a parallel-run period agreed in writing.

How the migration differs by team size and starting point

A small team with one ThreatConnect owner and a handful of playbooks usually has a narrow export and a short list of integrations to rebuild. The main risk is losing a few automations that quietly run in the background, so the inventory matters more than the data volume. Illustrative example: a team with one owner, a single organization and five playbooks would likely export indicators and groups once, then rebuild the playbooks as OpenCTI connectors or as a separate automation tool.

Export scope: Pull indicators and groups from the one owner, then confirm nothing sits in a second owner you have forgotten.
Playbook inventory: List each playbook, its trigger and its output, and decide per item whether OpenCTI covers it or a separate tool is needed.
Tag mapping: Map a short set of ThreatConnect tags to OpenCTI labels, markings and organizations so searches still return the same records.
Parallel run: Keep ThreatConnect read-only for a short overlap while analysts check results in OpenCTI.
Hosting choice: A single-node OpenCTI deployment may be enough, but confirm the sizing guidance in the OpenCTI deployment overview for your expected load.

Before you start, confirm with your ThreatConnect administrator which playbooks are still in use, because retired playbooks often stay listed.

What usually goes wrong and how to prevent it

Most ThreatConnect to OpenCTI migrations fail in the handoff rather than the import itself. The risks below cover ownership, duplicates, feeds, sharing scope, automation logic and release timing, and each one has a check to run before cutover.

Lost ownership and marking context

ThreatConnect owners, sources and communities do not map one to one onto OpenCTI organizations and markings, so intelligence can arrive without the context that decided who may see it. Before importing, build a written table that maps every ThreatConnect owner to an OpenCTI organization and every handling rule to a marking definition. Then sample records from each owner after import and confirm that creator, source and marking survived the move.

Duplicate objects after re-import

Running an import more than once, or importing the same indicators through both the v3 API and a TAXII 2.1 pull, can create copies of the same observables and reports. Duplicates distort scores, counts and relationships in the knowledge graph. Set a single source of truth for each object type, run a test import into a non-production instance, and check for duplicate indicator values before you open the platform to analysts.

Broken SIEM and blocking feeds

Detection and blocking tools often pull from ThreatConnect on a schedule, using its own export formats and endpoints. When those pulls stop at cutover, the gap is silent: blocklists age and rules match nothing. Inventory every consumer of ThreatConnect output, decide which ones move to OpenCTI connectors or exports, and run old and new feeds side by side until the new output matches expected volumes.

Over-sharing from unmapped markings

If an intelligence object arrives without a marking, OpenCTI may treat it as broadly visible inside the platform. This is most likely for records that ThreatConnect restricted by community or by a sharing agreement. Map each restricted ThreatConnect group to a marking before import, set the default marking for new objects, and test with a non-privileged user account that should not see restricted items.

Playbook logic lost in translation

ThreatConnect playbooks carry branching, enrichment calls and approval steps that rarely exist as one-to-one features elsewhere. OpenCTI offers playbooks in its Enterprise Edition, but the logic must be rebuilt and tested, and a separate automation tool may be needed for steps outside the platform. Document each playbook's trigger, inputs, outputs and failure path, then run both versions on the same sample set and compare results.

LTS license and upgrade timing

OpenCTI LTS releases need a specific LTS license key, and they receive only critical bug and security fixes after the first month of stabilization. Choosing a non-LTS release for production means more frequent upgrades, while an LTS line has a fixed support window. Confirm the license terms with Filigran before deployment, record which line you run, and plan upgrades to land inside the support window of your chosen line.

Questions buyers ask before moving from ThreatConnect to OpenCTI

How much effort and cost should we expect when moving from ThreatConnect to OpenCTI?

The cost is mostly people time and infrastructure, and the size of the bill depends on what you move and how you run it. The cost components are the infrastructure to host OpenCTI, the time to export and map ThreatConnect data, the rebuild of playbooks in OpenCTI or a separate automation tool, analyst retraining, and support. Infrastructure is recurring: OpenCTI needs a platform, Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO. Migration work is largely one-time. Costs rise with the number of indicators, groups and playbooks, the number of connectors, and the volume of custom mapping. Ask any implementation partner for a quote built from a written scope that lists these components separately, and compare it with your current ThreatConnect subscription by component.

How long does a ThreatConnect to OpenCTI migration take?

The timeline depends on data volume, the number of owners and sharing rules to map, and how many playbooks you need to replace. No fixed duration applies to every environment, so treat any single figure with caution and confirm it against your own inventory. The main drivers are the export pass through the ThreatConnect v3 API or the TAXII 2.1 server, the decisions about how owners and tags become OpenCTI organizations and markings, and the testing of connectors against a staging instance. Parallel running of both platforms for a validation period adds time but reduces cutover risk. Ask for a timeline tied to phases with named exit criteria in the written scope.

What does the migration need from our internal team?

Your team needs to own the decisions that only your organization can make, and a platform engineer needs to provide access to infrastructure. Analysts should confirm which indicators, groups and cases still matter, because migrating everything is rarely the right outcome. Security owners should approve the mapping of ThreatConnect owners, communities and sources to OpenCTI organizations and markings, since these affect who can see what. Automation owners should list every playbook and the systems each one touches. Plan for named contacts in SIEM, blocking and SOAR teams, because downstream integrations often break at cutover.

Can our own team migrate from ThreatConnect to OpenCTI without a partner?

A capable platform team can run a migration without an outside partner, provided it has the skills and time. The work includes deploying OpenCTI with its dependencies, writing export scripts against the ThreatConnect APIs, mapping STIX objects, configuring authentication, testing connectors, and rebuilding playbooks. Teams with little Kubernetes, Elasticsearch or STIX experience usually find the upkeep harder than the first deployment. Before deciding, check whether your staff can carry the work after go-live, including upgrades and backups. A fixed-scope engagement from DeployOpen can cover planning, implementation, hardening, backup and documentation, with ongoing support available as a retainer.

Is OpenCTI Community Edition enough, or do we need Enterprise features?

Community Edition, licensed under Apache 2.0, covers the core data model, the GraphQL API and the open connectors. Enterprise Edition, under the OpenCTI Enterprise Edition License, adds features such as audit logs, playbooks, organization-based segregation, full text indexing, AI insights and SSO for OpenID, LDAP, SAML, certificate and header authentication. If you need organization segregation to match ThreatConnect owners, or audit logs for compliance evidence, Enterprise features matter. Confirm current feature availability and license terms directly with Filigran before deciding, since the documentation may change between releases.

How do LTS licenses and release cycles affect OpenCTI upgrades?

OpenCTI publishes regular releases with date-based version numbers and LTS releases on a separate track. LTS releases come out every 6 months, each supported for 1 year, which gives a 6-month overlap between consecutive LTS versions. LTS releases are distributed as container images but require a specific LTS license key to use. After a one-month stabilization period, they receive only critical bug and security fixes. Plan upgrades around these windows, and confirm with Filigran which license tier you need and whether your key covers the LTS line you intend to run. Budget time for regular testing of each upgrade in a staging environment.

What risks should we check before cutting over from ThreatConnect?

The main risks are incomplete exports, lost sharing context, and broken downstream integrations. Confirm that every indicator, group and tag you rely on exports correctly, including extra fields such as associations. Check that owner-based access rules are reproduced in OpenCTI markings and organizations, so that no one gains access to intelligence they should not see. Test every SIEM, blocking and SOAR connection against OpenCTI before turning off ThreatConnect. Keep a read-only ThreatConnect archive for an agreed period so you can answer questions about historical decisions.

How DeployOpen scopes and runs the migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from ThreatConnect to OpenCTI, we start with a written scope that covers which data, owners and playbooks are in play, then build and hand over the deployment.

How we scope

Inventory the ThreatConnect indicators, groups, owners, tags and integrations that must move to OpenCTI.
Agree in writing which owners map to OpenCTI organizations and which markings control access to each dataset.
Define which ThreatConnect playbooks are replaced by OpenCTI connectors, which need a separate automation tool, and which are retired.

How we build

Deploy OpenCTI with its platform, workers, connectors, Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO in your environment.
Configure the export and import path, whether through the ThreatConnect v3 API or a TAXII 2.1 feed, and test it on a sample before full load.
Set up authentication, organization segregation and the connectors your analysts rely on, such as MISP and MITRE ATT&CK, as agreed in scope.

How we hand over

Document the data mapping, marking rules, connector configuration and playbook replacements so your team can operate them.
Provide reconciliation reports that compare object counts and sample records between ThreatConnect and OpenCTI before cutover.
Hand over runbooks for backups, upgrades and the OpenCTI LTS or regular release cadence your team chooses to follow.

How we support

Support after handover is available as a retainer, covering upgrades, patching and connector maintenance on your schedule.
Ask for a clear list of which support tasks are included and which need a separate scope before work begins.
Confirm with us how license keys for OpenCTI LTS releases and Enterprise features will be handled within the agreed scope.

Migrate from ThreatConnect to OpenCTI