Migrate from ThreatQ to OpenCTI: what the move involves
The move is a data model, feed and integration project, not a file copy. If your ThreatQ renewal, pricing change or residency requirement has put the platform under review, plan for the work to be done in four parts: moving indicators and adversaries into a different schema, rebuilding each feed as an OpenCTI connector, repointing every SIEM and EDR integration, and proving that scores and sightings still mean what your analysts expect. OpenCTI structures its knowledge on the STIX 2 standard and exposes a GraphQL API, so most of the mapping work is about translating ThreatQ's objects, relationships and score logic into STIX 2 objects and OpenCTI's own scoring, not about moving rows between databases.
In most organizations the work is done by the internal platform engineering team and the CTI team that owns the feeds, with an implementation partner handling the deployment, connector configuration, mapping scripts and hardening. The CTI team decides which indicators stay active, which are retired and how confidence is set, because those choices change detection behavior. The platform team owns the Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage layers, along with backups and upgrades. Effort and risk depend mainly on how many feeds you run, how heavily ThreatQ's scores drive automated blocking, and how many downstream tools read from it. Ask for a written inventory of each of these before agreeing on scope, and do not accept an effort estimate that has not been tied to that inventory.
Before you export anything, confirm which export paths your ThreatQ version actually supports for indicators, adversaries, attributes, relationships and score history, because these vary by release and deployment type. Check with ThreatQuotient or your Securonix contact, and test a sample export in a non-production copy. Also confirm the exact connector list for the OpenCTI release you plan to deploy, and whether you need an OpenCTI Enterprise Edition license for features such as SSO or audit logs, which are documented in the OpenCTI Enterprise Edition documentation. Any gap in the connector list becomes engineering work on your side, so record it early.
Which ThreatQ capabilities map to OpenCTI, and which need rework
This table maps ThreatQ's main capabilities to OpenCTI's STIX 2 objects, scoring, connectors, case management and API, and marks each as clean, needs rework or gap. Read the status as a starting point: confirm how your ThreatQ version exports each item before you plan the import, because export options and object types vary by release and configuration.
| Capability | OpenCTI equivalent | Status and what to confirm |
|---|---|---|
| Indicators (IOCs) | STIX 2 Indicator objects with observables and patterns | Clean for IPs, domains, hashes and URLs. Confirm each indicator type maps to a STIX pattern and that your ThreatQ export keeps expiration and source fields. |
| Adversaries | Intrusion Set and Threat Actor objects with aliases | Needs rework. Confirm how ThreatQ links adversaries to indicators and whether aliases export as separate records that must be merged. |
| Threat Library objects (malware, campaigns, TTPs, reports) | Malware, Campaign, Attack Pattern, Report and Note objects | Needs rework. Custom ThreatQ object types have no direct STIX type and need a documented mapping to a standard type or a custom attribute. |
| Relationships between objects | STIX relationship objects shown in the knowledge graph | Needs rework. Confirm which ThreatQ relationship types export and recreate them as STIX relationships with the correct direction. |
| Dynamic scoring and decay | Indicator score and OpenCTI scoring rules | Needs rework. ThreatQ's scoring logic does not transfer as a formula. Plan to recalculate scores in OpenCTI and confirm the scoring rules with your team before go-live. |
| Feeds and ingestion | OpenCTI connectors for import, enrichment and export | Gap until rebuilt. Each ThreatQ feed needs a connector, a custom script or a TAXII or MISP source. Confirm which feeds you use and which vendor licenses permit reuse. |
| Investigations | Cases and incident response objects in OpenCTI case management | Needs rework. Confirm how investigation notes, tasks and attachments export from ThreatQ and map to OpenCTI cases and notes. |
| Pushes to SIEM and EDR | Stream connectors, export connectors and the OpenCTI API | Needs rework. Each push must be rebuilt against your SIEM or EDR API. Confirm the target tool version and the indicator fields it expects. |
| Automation and API | GraphQL API and Python client | Needs rework. Confirm which ThreatQ API calls your scripts and playbooks use, then rewrite them against the GraphQL schema. |
Which data and integrations move, and through which export paths
Migrating from ThreatQ to OpenCTI means moving four kinds of content: indicators with their context, adversaries and related objects, source attribution and tags, and the feeds and outbound pushes that feed detection tools. Each one follows a different export path, so confirm the exact formats for your deployed ThreatQ version with ThreatQuotient documentation before you plan the cutover.
Indicators and their context
Indicators are the observables your SIEM and EDR tools act on, such as file hashes, domains, IP addresses and URLs, along with status, type and first and last seen dates. Export them from ThreatQ through its documented export or API paths, and map each indicator type to a STIX 2 Indicator or Observable. Check that status and expiration survive the move, because OpenCTI scores and expires data differently from ThreatQ's Threat Library. Confirm the export formats for your version with ThreatQuotient.
Adversaries and related objects
Adversaries, campaigns, malware families, tools and the relationships between them carry most of the analytical value in ThreatQ. Export these objects with their links to indicators, then recreate them as STIX 2 objects such as Intrusion Set, Campaign, Malware and Tool, with relationships between them. Relationship types that ThreatQ uses may have no one-to-one STIX equivalent, so list each one and decide how it will be represented before import.
Source attribution and tags
Each indicator in ThreatQ records the feed or source that supplied it, and analysts add tags for campaign, sector or confidence. In OpenCTI these become created_by identities, labels and marking definitions, which control who can see the data. Export source names and tags in full, then build an identity and label list before loading, so provenance and sharing restrictions are not lost in transit.
Feeds re-created as connectors
ThreatQ ingests external feeds through its own feed configuration. In OpenCTI, the same sources run as import connectors, which may be community-maintained, vendor-supplied or written in-house. Inventory every active feed, its schedule and its credentials, then confirm for each one whether an OpenCTI connector exists for that source or whether your team must build and operate one. Plan the connector runtime, since each connector is a service you maintain.
Repointing SIEM and EDR integrations
Detection tools currently receive ThreatQ pushes or pull from its API. Replace each one with an OpenCTI export, stream or API call, and test each rule with known indicators before turning off the ThreatQ push. Record each SIEM and EDR integration with its owner, data format and schedule, because a missed indicator type can leave a gap that no one notices until an incident. Confirm each target's supported indicator formats with its vendor.
The migration sequence from inventory to decommission
The sequence moves ThreatQ intelligence into OpenCTI in controlled stages, so each feed and detection push is proven on the new platform before the old one is switched off. Each step produces a named artifact that the next step depends on.
Inventory ThreatQ feeds, objects and pushes
Name the owner of the migration and list every ThreatQ data feed, custom object type, adversary and campaign record, scoring rule, workflow, and outbound push to SIEM, EDR, firewalls or ticketing. Record the volume of indicators per source and which teams consume each output. Confirm the export options available in your ThreatQ version with your administrator or ThreatQuotient documentation, since export formats and API endpoints vary by release. The step is done when the inventory lists every consumer, and the business owner of each one has signed off on it.
Map ThreatQ data model to STIX 2
Build a mapping document that links each ThreatQ object type, attribute, and score to a STIX 2 object, relationship, or OpenCTI custom attribute. Decide how ThreatQ scores and expiration rules translate into OpenCTI indicator scores, valid-from and valid-until dates, and labels, and note where ThreatQ concepts such as the Threat Library have no direct equivalent. Review the mapping with analysts and the SIEM and EDR owners who depend on those fields. The output is an approved mapping document with worked examples, and it is done when every inventory item maps to a target or is marked as deliberately retired.
Pilot with a subset of feeds
Stand up a non-production OpenCTI instance with its dependencies in your own infrastructure, then load a small set of feeds and one or two detection pushes chosen for low risk and clear ownership. Build the connectors needed for those feeds and run the ThreatQ export through the mapping. Compare what arrives in OpenCTI against ThreatQ for the same sources, and record gaps, scoring differences, and performance issues. The output is a pilot report listing accepted mappings, open defects, and a decision on whether the design holds for the full set.
Run both platforms in parallel
Feed the same production sources into ThreatQ and OpenCTI at the same time, and keep ThreatQ's detection pushes active so existing controls do not change. Schedule regular reconciliation runs that compare indicator counts, relationships, scores, and expiry state across both platforms for each source. Investigate every mismatch and classify it as a mapping error, a source difference, or an expected change. The output is a set of reconciliation results with a written explanation for each category of difference, and the step is done when mismatches are explained and the agreed tolerance is met for a sustained period you define.
Cut over detection pushes
Repoint each SIEM, EDR, and ticketing integration from ThreatQ to OpenCTI connectors or exports, one consumer at a time, starting with the lowest-impact one. Confirm with the detection engineers that rules, watchlists, and enrichment lookups return the same results after each change, and keep a tested rollback path to the ThreatQ push for each consumer. The output is a cutover runbook with the change record, validation checks, and rollback steps for every integration, and the step is done when all consumers read from OpenCTI and the owners have accepted the result.
Decommission ThreatQ and archive its data
Once all consumers have been running on OpenCTI through an agreed observation period, disable ThreatQ feeds and pushes and stop its scheduled jobs. Export a complete, read-only archive of ThreatQ data, including indicators, adversaries, audit history, and configuration, and store it under your retention and legal hold policies. Confirm the archive can be read before shutting down the instance, and check with your contract owner the terms for the end of the subscription and any data return or deletion obligations. The output is an archive record and a decommission sign-off, and the step is done when the archive has been verified and access to ThreatQ is closed.
What drives migration cost and duration, and how to keep each down
This table lists the main drivers of a ThreatQ to OpenCTI migration and the effort each one adds. Read each row as a question to answer in your own environment before you request a quote. The main takeaway is that feed count, scoring reconciliation and stack sizing usually matter more than the data import itself.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of feeds and connectors | Each ThreatQ feed or pushed integration must be re-created as an OpenCTI import, enrichment or export connector, and each one needs testing and monitoring. | Inventory every feed and push target first, retire unused ones, and reuse existing OpenCTI connectors such as MISP or MITRE ATT&CK where they fit. |
| Custom integrations and SIEM or EDR pushes | Indicator pushes to detection tools must be rebuilt against OpenCTI exports or connectors, and each target has its own format and authentication to validate. | Map each push to a single target system, prioritize the high-volume ones, and confirm which connector or export format each detection tool accepts. |
| Scoring rules to reconcile | ThreatQ dynamic scores and decay rules do not map one to one onto OpenCTI scoring, so thresholds and rules need written decisions and analyst sign-off. | Document current scoring thresholds, agree target OpenCTI score values with analysts, and test them on a sample of indicators before bulk import. |
| Volume and age of history | More historical indicators and related objects mean longer mapping runs, more data cleansing and more validation of STIX 2 object relationships. | Decide which history must move (for example, active indicators only), archive the rest, and agree the cutoff in the written scope. |
| Elasticsearch or OpenSearch sizing | The documented baseline is 2 cores and 8 GB RAM for Elasticsearch or OpenSearch, with 16 GB SSD, and index size grows with imported data. | Size from your actual object count and retention, and ask the implementer to show the sizing assumptions in the quote. |
| Platform and worker sizing | The documented baseline is 2 cores and at least 8 GB RAM for the platform, with at least one platform node for every 3 workers, so connector count drives node count. | Start from the documented minimum, measure worker queue depth during the pilot, and add nodes only where the measurements show a need. |
| LTS licensing and upgrade cadence | LTS releases require a specific LTS license key, and LTS lines receive only critical and security fixes after stabilization, so upgrades are recurring work. | Confirm the license terms with Filigran before you commit, choose an LTS line, and schedule upgrades within each one-year support window. |
| Analyst training and workflow change | Analysts moving from the ThreatQ Threat Library to OpenCTI's STIX 2 knowledge graph and case handling need time to learn the new workflow, which is a one-time cost with ongoing support needs. | Train on live migrated data, write short runbooks for common tasks, and budget refresher sessions after each major upgrade. |
How the move differs by team size and starting point
A small team with a handful of feeds and a limited set of consumers usually has a narrow migration. The main work is deciding which indicators and adversary records are still active, then rebuilding the few feed sources as OpenCTI connectors. Because the data volume is modest, the platform can often run on a single node, but the stack still includes Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, so the operating load is larger than the feed count suggests.
- Feed inventory: List every feed, its license terms and its refresh cadence before exporting anything.
- Active data only: Export only indicators that are still relevant, and decide whether expired ThreatQ scores carry over.
- Connector count: Confirm which feeds have an existing OpenCTI connector and which need a custom build.
- Operator capacity: Identify who will run upgrades, since OpenCTI releases arrive on a rolling basis and LTS lines need a license key.
- Single node sizing: Check the documented minimum resources against the hardware you intend to use.
Confirm first whether anyone on the team has time to maintain the stack after cutover, because a small team usually has no spare capacity for on-call platform work.
A large SOC often has ThreatQ pushing indicators to several SIEM and EDR tools on a schedule, with each push tuned to a different consumer. The migration scope is driven by the number of outbound integrations, not by the size of the library. Each push has to be mapped to an OpenCTI export, a stream consumer or a connector, and each consumer has to be tested against the new format before ThreatQ is switched off.
- Integration inventory: Record every push, its schedule, its filter logic and its destination.
- Score translation: Map ThreatQ score thresholds to the confidence and score fields that drive your detection rules.
- Parallel running: Plan a period where both systems publish so detections can be compared.
- Scaling workers: Size the Python workers and RabbitMQ queues for peak enrichment load, using the platform-to-worker ratio in the deployment guidance.
- Change control: Route each integration cutover through your change process with a named rollback.
Confirm first which SIEM and EDR consumers depend on exact ThreatQ field names, because those fields will need a mapping layer or a rewrite on the consumer side.
In an air-gapped or regulated environment, the first question is how updates, feeds and container images reach the platform. OpenCTI is self-hosted, but its connectors, container images and LTS license keys must be brought across the boundary through an approved process. Access control, audit logging and data segregation also shape the design, and some of these controls sit in the Enterprise Edition rather than the Community Edition, so the edition choice belongs in the early discussion.
- Edition decision: Compare the Community and Enterprise Edition feature lists against your audit log, SSO and segregation requirements.
- Authentication: Confirm which identity method your directory supports, such as OpenID, LDAP or SAML.
- Update path: Define how release packages and feed updates move across the boundary and who approves them.
- Evidence: Decide which configuration, access and change records your assessors will ask for, and where they will be stored.
- Data residency: Confirm where indicators, enrichment results and backups are kept.
Confirm first whether your assessors or your security policy accept the connector and feed sources you plan to use, because an unapproved connector can block the whole design.
Some teams already exchange intelligence through MISP, either with sector peers or with other instances they synchronize with. In this case the migration is less about moving data and more about deciding where each kind of intelligence lives. OpenCTI and MISP both use STIX 2 concepts, but they structure sharing differently, so a team that runs both needs a clear rule for what is authored in which platform and what flows between them.
- Source of truth: Decide whether MISP stays the sharing hub and OpenCTI becomes the analysis graph, or the reverse.
- Connector reuse: Check whether an existing OpenCTI MISP connector can carry data in both directions without duplicating events.
- Duplicate control: Set rules so the same indicator does not appear twice with different scores.
- Sharing permissions: Review the sharing groups and distribution levels that govern what partners receive.
- Synchronization load: Confirm how often sync runs and whether it affects detection timing.
Confirm first which partners depend on receiving data from your ThreatQ instance today, since changing the outbound route can break a sharing relationship that no one has documented.
What usually goes wrong in a ThreatQ to OpenCTI migration
Most failed threat intelligence migrations fail quietly: scores drift, context disappears, and detections stop matching before anyone notices. The cards below cover the failure modes that recur when indicators, adversaries and feeds move from ThreatQ into OpenCTI, with the check that prevents each one.
Scoring and expiry drift
ThreatQ's dynamic scores and expiry rules do not map one-to-one onto OpenCTI's scoring and indicator validity fields. If scores are copied as static values, indicators that should have decayed stay active and feed detections with stale data. Before cutover, document each ThreatQ scoring rule and expiry policy, then reproduce it as an explicit OpenCTI rule and compare sample indicators from both systems side by side.
Dropped context and relationships
Indicators exported without their linked adversaries, campaigns, malware and reports arrive in OpenCTI as bare observables. The analyst sees a value with no story, and the knowledge graph is thinner than the source. Export relationships explicitly, then check a representative sample of adversaries and their linked indicators after import, counting relationships on both sides rather than trusting that the import succeeded.
Duplicate indicators from parallel feeds
Running ThreatQ and OpenCTI connectors against the same commercial feeds during the overlap period creates duplicate observables with different scores and sources. Deduplication then depends on STIX identifiers that differ between imports. Choose one system as the authoritative source per feed, disable the other feed's ingest, and run a duplicate count query on observable values before retiring ThreatQ.
Detections breaking at cutover
SIEM and EDR rules often depend on ThreatQ's push format, field names or scheduled exports. When the feed moves to OpenCTI, those pushes stop and some detections quietly lose their indicators. Inventory every integration that consumes ThreatQ output, map each to an OpenCTI stream or export, and run both paths in parallel with alert comparison for a defined period before disabling the ThreatQ push.
Under-sized Elasticsearch or OpenSearch
OpenCTI relies on Elasticsearch 8.0 or OpenSearch 2.9 or later for indexing. Teams that size the search tier only for the platform node often find imports slow or fail once the historical ThreatQ dataset arrives. Size the index tier against the full migrated volume, not the steady-state feed rate, and confirm the documented minimums in the OpenCTI deployment overview before loading production data.
LTS license and upgrade lapses
OpenCTI LTS releases require a specific LTS license key and receive only critical bug and security fixes after a one-month stabilization period. A platform left on an LTS line past its support window, or deployed without a valid key, can miss security patches. Record the release line, the license key owner and the support end date in your operations runbook, and schedule upgrades against the product life cycle published by the vendor.
Questions buyers ask before moving from ThreatQ to OpenCTI
How much does it cost to move from ThreatQ to OpenCTI?
No single figure applies, because the cost is set by components rather than by a list price. OpenCTI Community Edition is licensed under Apache License 2.0, so the software itself carries no license fee. The recurring costs are the infrastructure (the platform, Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO), the staff who run it, the connectors and feeds you keep, and any support contract. The one-time costs are planning, data mapping, connector rebuilds and integration changes. Ask ThreatQ for the exact terms of your current contract, including any Securonix bundling, so you can compare the license you would stop paying against the components you would start running.
How long does a ThreatQ to OpenCTI migration take?
The duration depends on how many feeds, workflows and integrations you run, how much history you keep, and how clean your existing indicator data is. No timeline is supplied for this migration, so treat any estimate you receive as a planning input rather than a commitment. The main drivers are the number of ThreatQ objects that must map to STIX 2 objects, the number of feeds that must be rebuilt as OpenCTI connectors, and the number of SIEM and EDR integrations you must repoint and test. A fixed-scope written plan from DeployOpen would set scope, deliverables and timelines before work starts.
What does our team need to provide for the migration?
The work goes faster when your team supplies accurate inputs early. Typically that means:
- An export of ThreatQ indicators, adversaries, campaigns and related objects, with their scores and sources
- A list of every feed, its owner and how often it runs
- A list of every SIEM, EDR and ticketing integration that consumes ThreatQ output, with the owner of each
- Your data retention and sharing rules, including any tagging or TLP conventions
- Named people who can approve scoring decisions and test detections
Confirm with ThreatQ which export formats and API endpoints your version supports before you start.
Can our own team migrate from ThreatQ to OpenCTI without a partner?
Yes, if you have people who can run Linux servers, container platforms and the OpenCTI stack, and who understand STIX 2 modeling. OpenCTI's documentation covers deployment, and the GraphQL API and connector framework give your engineers the tools to rebuild feeds. The harder parts are usually the score mapping, the scoring rules you need to reproduce, and the integration testing with detection teams. Many teams split the work: internal staff own feeds and day-to-day operations, while an implementation partner handles deployment, hardening and the migration plan. DeployOpen plans, implements and supports self-hosted platforms in your environment, under fixed-scope written agreements.
Does OpenCTI Community Edition cover what we use in ThreatQ?
Community Edition is licensed under Apache License 2.0 and provides the core platform, STIX 2 knowledge schema, GraphQL API and connectors for tools such as MISP, TheHive and MITRE ATT&CK. The Enterprise Edition, under the OpenCTI Enterprise Edition License, adds features including audit logs, playbooks, organization-based segregation, full text indexing, AI insights and SSO options for OpenID, LDAP, SAML, certificate and header authentication. Check each ThreatQ capability you rely on against the feature list in the Enterprise Edition documentation. Confirm with Filigran which features are included in each edition and what the Enterprise license terms require for your deployment.
What does the OpenCTI release cycle mean for operations?
OpenCTI ships non-LTS releases from daily to weekly and publishes LTS releases every 6 months, each supported for 1 year. 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. For a production deployment, you should decide early whether you will follow LTS or regular releases, budget staff time for upgrades, and confirm with Filigran how the LTS license key is issued and renewed. The OpenCTI product life cycle page documents the version format, which uses a date-based scheme.
How do we run ThreatQ and OpenCTI in parallel during cutover?
Run both platforms side by side for a defined period, with ThreatQ remaining the system of record until each feed and integration is verified. Start by feeding the same sources into both platforms and comparing indicator counts, scores and matches. Repoint one low-risk SIEM or EDR integration at a time, and keep the ThreatQ push active until detection teams confirm equivalent results. Record every difference, decide whether it is a mapping gap or an intended change, and only switch off ThreatQ feeds once the exit criteria in your written plan are met. Agree the rollback steps before the first cutover.
How DeployOpen scopes and runs a ThreatQ to OpenCTI migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so an OpenCTI deployment and its data move stay under your control. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory ThreatQ objects, feeds, scores, playbooks and the SIEM and EDR pushes that depend on them.
- Agree in writing which data types, history and sharing groups move to OpenCTI and which stay archived.
- Confirm the hosting target, sizing and authentication model with your infrastructure and identity teams before build starts.
How we build
- Map ThreatQ indicator, adversary and score fields to STIX 2 objects and OpenCTI scoring, documenting every decision.
- Deploy the OpenCTI platform, workers, connectors and dependencies in your environment, then hardening it to your standards.
- Re-create feed ingestion as OpenCTI connectors and test imports against a reconciled sample of ThreatQ records.
How we hand over
- Repoint SIEM and EDR integrations to OpenCTI outputs, and test each indicator flow end to end with your detection teams.
- Deliver runbooks for deployment, backup, upgrades and connector maintenance, plus the mapping and validation records.
- Run a handover session with the people who will curate feeds and own the platform after the engagement ends.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the migration.
- Plan upgrades around OpenCTI's release and LTS cadence, which your team will need to license for LTS builds.
- Ask any provider, including DeployOpen, to confirm in writing which tasks recur and who pays for each.
