Threat intelligence is the one segment in this whole category where portability is genuinely designed in. STIX and TAXII are real standards with real adoption, and both ThreatConnect and OpenCTI speak them. That changes the character of the migration completely: instead of reimplementing logic that only exists in a vendor’s language, you are exporting a graph and importing it into a platform built on the same data model.
That does not make it trivial, but it does mean this is the security migration where “export your data” is an actual sentence rather than a euphemism.
Sort what is yours from what you rent
Start by separating the intel in the platform into two piles, because they migrate completely differently.
Rented intel is everything that arrived from a feed: commercial subscriptions, open feeds, ISAC and sector sharing, TAXII collections. It is in ThreatConnect because ThreatConnect subscribed on your behalf. Do not migrate it. Re-point those subscriptions at OpenCTI and the current data flows in continuously, which is strictly better than importing a snapshot that begins going stale the moment it lands.
Your intel is what your organisation produced: indicators extracted from incidents you handled, analysis your team wrote, attribution judgements, sector-specific observations, and the relationships an analyst drew between them. This is irreplaceable and it is what the STIX export is for.
The sorting exercise has a useful side effect. It surfaces which paid feeds anyone actually reads, and threat-intel feed subscriptions are among the easiest security spend to accumulate and never review.
The mapping
- ThreatConnect indicators and observables → OpenCTI observables and indicators (STIX 2.1 objects).
- Groups (adversaries, campaigns, incidents, documents) → OpenCTI entities (threat actors, campaigns, incidents, reports).
- Associations → OpenCTI relationships, which is the part OpenCTI models best.
- Tags → OpenCTI labels.
- TAXII subscriptions → OpenCTI TAXII connectors, re-subscribed at source.
- Feed integrations → OpenCTI connectors from the connector library.
- Playbooks (ingest and enrich) → OpenCTI connectors.
- Playbooks (respond and act) → an external automation platform triggered by OpenCTI events.
- Confidence and scoring → OpenCTI confidence and decay rules, which you configure rather than inherit.
- Reporting and dashboards → OpenCTI dashboards and the GraphQL API.
What the export genuinely does not carry
Be precise about this so nobody is surprised.
The STIX export carries objects and relationships faithfully. It does not carry ThreatConnect’s computed confidence and scoring, because that is the product’s own algorithm applied to your data. It does not carry annotations stored in proprietary fields outside the STIX model. It does not carry the change audit trail, so “who marked this indicator as false positive in 2023” is a question with no answer after cutover. And it does not carry playbook definitions or their execution state.
For most teams the practical impact is concentrated in scoring. You will arrive in OpenCTI with a rich graph and no inherited confidence values, and you will need to configure OpenCTI’s own scoring and decay rules to reflect how your team judges reliability. That is an opportunity as much as a loss, since inherited scores nobody understands are their own problem, but it is work and it should be in the plan.
Where the audit trail matters for a compliance or legal reason, export it separately as a flat record before cutover and keep it as an archive.
Decide OpenCTI versus MISP deliberately
These are adjacent tools and the choice is often made by accident. Make it on purpose.
MISP is a sharing platform. It is mature, extremely widely deployed across CERTs, ISACs, and national bodies, and it is the practical standard for exchanging indicators with peers. If your community shares through MISP, you need MISP, full stop.
OpenCTI is a knowledge platform. It models the graph, actors and campaigns and malware and techniques and the relationships between them, and it is designed for analysis rather than exchange. Its ATT&CK integration and relationship querying are considerably stronger.
Running both is common and coherent: MISP as the sharing endpoint, OpenCTI as the analysis layer, with a connector between them. If you are replacing ThreatConnect’s analysis and knowledge-management role, OpenCTI is the closer match, and adding MISP later for sharing is easy.
Run the platform seriously
OpenCTI is not a lightweight deployment. It needs Elasticsearch or OpenSearch, Redis, RabbitMQ, and object storage alongside the application, plus a worker process per connector. Connector workers at real feed volumes consume meaningful resources, and an under-provisioned deployment manifests as feeds silently falling behind, which is exactly the failure mode a threat-intel platform must not have.
Instrument connector lag and alert on it. A TAXII connector that stopped working three weeks ago looks identical, from the interface, to one that is working perfectly against a quiet feed.
Order of operations
- Sort rented intel from your own, and audit which paid feeds anyone reads.
- Export your own intel as STIX 2.1, plus a separate flat export of the audit trail if you need it for compliance.
- Deploy OpenCTI with its full dependency stack, sized for your connector count and feed volume.
- Re-subscribe feeds at source as OpenCTI connectors, rather than importing rented data.
- Import your own intel and verify that relationships, not just objects, arrived intact.
- Configure confidence and decay rules to express how your team judges reliability.
- Rebuild ingest and enrichment playbooks as connectors, and response playbooks in an external automation platform.
- Re-point downstream consumers (SIEM, EDR, firewall) at OpenCTI’s export and TAXII endpoints, one at a time.
- Run both platforms in parallel for one full feed cycle, comparing indicator counts and freshness.
- Cancel the ThreatConnect subscription once every downstream consumer is served by OpenCTI.
Clearing the bar before you cut over
The imported graph has relationships intact, not just isolated objects, verified by spot-checking real cases. Every feed that matters is subscribed at source and its connector lag is instrumented and alerting. Downstream consumers are receiving indicators from OpenCTI with the same freshness they had before. Confidence and decay rules are configured and reviewed by whoever owns intel quality. And the audit trail, if you need it, is archived somewhere outside both platforms.
The short version
ThreatConnect to OpenCTI is the most portable migration in this category, because STIX 2.1 is a real standard and OpenCTI is built on it natively. Re-subscribe rented feeds rather than importing stale copies, export only what your own team produced, and expect scoring and audit history to be the things that do not travel. Choose OpenCTI for analysis and MISP for sharing, or run both. Budget properly for a genuinely multi-component deployment, and instrument connector lag from day one. The calculator above gives illustrative economics; the feed subscriptions you stop paying for are often the larger saving.