How a ThreatStream to OpenCTI migration works in practice
Moving indicators from ThreatStream to OpenCTI is a well-trodden import task, while moving threat models, actor profiles and campaign analysis is a rebuild that needs analysts in the loop. The short answer on effort and risk is that the indicator side is the easier half and the analytic side carries most of the schedule risk. Security engineering usually owns the export, the OpenCTI deployment and the connector work. Threat intelligence analysts own the decision about which actor, campaign and malware objects must be recreated by hand. Platform engineers own the supporting stack that OpenCTI depends on, including Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO.
Indicators are plain observables with a few properties, so they map cleanly from a STIX 2.1 export into OpenCTI's STIX 2 based data model. Analytic objects are different. Relationships between a threat actor, the campaigns it runs, the malware families used and the indicators tied to each usually live in ThreatStream's own analytic context, and a STIX bundle does not carry that reasoning across intact. Before you start, confirm with Anomali exactly which export formats and fields your subscription supports, and check how the export handles relationships, tags and confidence. Then run a small sample import into a test OpenCTI instance and compare object counts and relationships against the source.
Plan the rebuild in two tracks. Import indicators in bulk and validate them against the sources, then rebuild the highest-value actor, campaign and malware entities manually, starting with the ones your detections and reports depend on. Replace integrations last, because each SIEM, firewall or enrichment feed that reads ThreatStream needs a matching OpenCTI connector or export path, and the OpenCTI GitHub repository is the place to check which connectors exist for your tools. Confirm connector coverage in your own environment before you retire anything, and keep ThreatStream running in read-only mode until detections have been checked against the new platform.
Which ThreatStream capabilities map to OpenCTI, and which need rework
This table maps the main ThreatStream capabilities to their OpenCTI equivalents and marks each as clean, needs rework or gap. Read the status column first, then the notes, and confirm every Enterprise-only feature against the OpenCTI Enterprise Edition documentation before you plan around it. Most indicator and STIX content moves across, while approval workflows, sharing agreements and custom feed logic usually need to be rebuilt.
| Capability | OpenCTI equivalent | Status | What to check before migrating |
|---|---|---|---|
| Indicators and observables | STIX 2 indicators and observables in the knowledge schema, searchable through the GraphQL API | Clean | Confirm that indicator patterns and observable types in your ThreatStream exports map to STIX 2.1 objects without loss |
| Threat models and analysis | Reports and notes linked to STIX objects, with relationships drawn in the graph | Needs rework | Narrative analysis must be restructured into reports and relationships; plan a review of each model |
| Actors, campaigns and malware | Threat actor, campaign and malware objects with relationships to indicators | Needs rework | Recreate relationships by hand or by script, since STIX imports may not preserve every link from ThreatStream |
| Reports | Report entities that reference the objects they describe | Needs rework | Attachments and formatting usually do not carry over; decide which reports are archived instead |
| Feeds and taxii collections | Connectors for import and enrichment, plus TAXII-based streams | Needs rework | Each ThreatStream feed must be matched to a connector or an external source; confirm availability for each provider |
| Approval workflow | Playbooks and organization-based segregation, which are Enterprise Edition features | Gap | Confirm playbook and segregation scope in the Enterprise documentation; plan manual review steps if they are not covered |
| Sharing with partners | Live streams and TAXII collections for distribution | Needs rework | Trust agreements with partners must be re-established and tested on the OpenCTI side |
| STIX export | STIX 2 export from the platform and its APIs | Clean | Validate exported bundles against your consuming tools, since STIX 2.1 output is the main interchange format |
| Integrations with SIEM and firewalls | Custom API calls and connectors, with MISP and TheHive connectors available | Needs rework | Each downstream integration must be rebuilt or re-pointed; test detections after cut-over |
| Audit logs and access control | Audit logs, SSO (OpenID, LDAP, SAML, certificate, header) in Enterprise Edition | Gap | Community Edition may not include these features; confirm license scope before you design access |
What data moves, what gets rebuilt and which integrations change
Indicators, threat models and integrations do not move the same way. The documented path is a STIX 2.1 export imported into OpenCTI, but the entities around those objects, and the connectors that feed your SIEM, firewall and enrichment tools, need deliberate reconciliation. Work through the cards in order so nothing is lost at cutover.
Confirm the STIX 2.1 export
Export your ThreatStream data in STIX 2.1 format and treat that file as the baseline for the migration. Check that object counts per type match what you see in ThreatStream, and that relationships between indicators, actors and malware survived the export. Ask the vendor to confirm which object types and relationship types the export includes for your subscription, because feed-sourced and analyst-created objects may be handled differently. Run a sample import into a test OpenCTI instance before any bulk load.
Rebuild actors, campaigns and malware
Threat actor, campaign and malware objects carry the analytic judgment your team made over time, and an import will not always reproduce that context. Reconcile duplicates where the same group appears under different names, and confirm that aliases, first-seen and last-seen dates and attribution confidence came across. Assign ownership for each high-value actor so someone is accountable for its accuracy after cutover.
Recreate threat models and analytic notes
Threat models, analyst write-ups and investigation notes are often stored as free text or as attached reports, not as structured STIX objects. Decide which ones stay as archived documents, which become OpenCTI reports linked to the relevant entities, and which are retired. Keep a register of what was moved, what was rewritten and what was left in the old system, and retain read access to ThreatStream for the period your retention policy requires.
Replace the MITRE ATT&CK, MISP and TheHive links
OpenCTI documents a dedicated connector for MITRE ATT&CK, along with integrations for MISP and TheHive. Enable the ATT&CK connector so technique mappings update from the framework rather than from manual entries. If your team shares indicators through MISP or hands cases to TheHive, configure those connectors and test a round trip with a known sample object before relying on them in operations.
Audit SIEM, firewall and enrichment feeds
Every SIEM rule, firewall blocklist and enrichment lookup that pulls from ThreatStream needs a new source. Inventory each one, record its format and update method, and check whether an OpenCTI connector or a STIX or TAXII output can serve it. Where no connector fits, plan a script or an intermediate export. Confirm each integration with its owner, since a silently stale blocklist is one of the most common cutover failures.
Plan identity and access on the new platform
Users, groups and organization-based access rules must be rebuilt in OpenCTI. Community Edition and Enterprise Edition differ here: the Enterprise documentation lists organization-based segregation, audit logs and SSO options such as OpenID, LDAP, SAML and header authentication. Map each ThreatStream role to an OpenCTI role or group, decide which features need Enterprise licensing, and confirm with Filigran which edition covers your requirements before you design access.
Migration sequence from inventory to decommission
This sequence moves ThreatStream's indicators, analytic objects and integrations into OpenCTI in controlled stages, so each consumer switches only after its data and detections have been checked. Each step produces a written artifact that gates the next one.
Inventory indicators, analytic objects and integrations
Your threat intelligence lead and the analysts who own investigations list every data source feeding ThreatStream, every analytic object they rely on (threat models, actor, campaign and malware write-ups, and reports) and every consumer that pulls from it, including SIEM rules, firewall and proxy blocklists, EDR feeds and partner sharing. Record the export format and any per-export limits for each source. The output is a single inventory with one owner per consumer. It is complete when the analysts confirm that no active investigation depends on an object missing from the list.
Map ThreatStream objects to STIX 2.1 in OpenCTI
Before importing anything, the team decides how each ThreatStream object type maps to OpenCTI's STIX 2 knowledge schema. Indicators, observables, actors, campaigns, malware and reports each need a target entity, and the team confirms how ThreatStream's exports represent them by reviewing sample files. Confirm with the vendor and your own export samples which fields survive, since not every ThreatStream attribute will have a direct equivalent. The output is a field mapping document approved by the analysts who use these objects. It gates the pilot import.
Run a pilot import into a non-production OpenCTI
Deploy a non-production OpenCTI instance using the platform, worker, RabbitMQ, Redis, Elasticsearch or OpenSearch and S3-compatible storage components described in the deployment overview. Import a representative sample of STIX 2.1 exports, covering each object type from the inventory. Compare counts, relationships and timestamps against the source, then have analysts open a set of known actors and campaigns to confirm the context survived. The output is a signed-off pilot report listing discrepancies and how each was resolved. Do not proceed until the discrepancies that affect detections are closed.
Rebuild connectors and run both platforms in parallel
Install the OpenCTI connectors that replace ThreatStream's feeds and integrations, such as the MISP and MITRE ATT&CK connectors where they apply, and confirm which feeds have no connector and need a custom or manual route. Point the same feeds at ThreatStream and OpenCTI during the parallel run, and compare the indicators each platform produces for the same inputs. Track the differences per consumer. The output is a parallel-run log with an agreed list of accepted differences. Confirm with your security operations lead that every difference is understood before any consumer moves.
Cut over consumers one at a time
Move consumers to OpenCTI in the order set by the inventory, starting with the lowest-risk ones such as analyst reference views, then SIEM and blocklist consumers. For each consumer, repoint the integration, verify that the expected indicators arrive and that alerts fire as before, and keep the ThreatStream path available for rollback until the consumer is stable. The output is a signed cutover record per consumer. The next consumer moves only after the previous one has run through its normal review cycle without a missed or unexpected detection.
Move sharing relationships and analyst workflows
Recreate partner and community sharing in OpenCTI, including any TAXII collections or live streams your partners use, and confirm each partner can read what they need under their own agreements. Train analysts on OpenCTI's investigation views and document the workflows that replace ThreatStream's. Confirm with each partner and with your legal or compliance team that the new sharing terms match existing agreements. The output is a sharing register and an analyst runbook. It gates decommissioning, because partners cannot be cut off until they have confirmed access.
Decommission ThreatStream after retention obligations
Once every consumer and partner runs on OpenCTI, export a final archive of ThreatStream data in the formats your retention policy requires, and confirm with legal, compliance and records owners which records must be kept and for how long. Then cancel or shut down ThreatStream access according to your contract terms, and remove its credentials from integrations and the secrets store. The output is a retention record and a decommission checklist signed by the data owner. Confirm the notice period and archive requirements with your Anomali contract and counsel before cancelling.
What drives migration cost and duration
This table breaks the OpenCTI migration into its cost components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build the scope you request in a written quote and to see where your own effort will concentrate.
| Cost component | Who carries it | One-time or recurring | What drives it |
|---|---|---|---|
| OpenCTI infrastructure | Your team or cloud budget, with DeployOpen if engaged for build | Recurring hosting, one-time build | Platform nodes (2 cores and at least 8 GB RAM per documented sizing), one platform node per 3 workers, and storage growth in Elasticsearch or OpenSearch (documented at 2 cores, 8 GB RAM, 16 GB SSD minimum) |
| Supporting services | Your team or cloud budget | Recurring | Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage such as MinIO; high availability design and backup scope add to this |
| Connector setup and maintenance | Your team, DeployOpen, or both | One-time setup, recurring upkeep | Number of feeds, MISP and TheHive links, MITRE ATT&CK import, and how often connector versions are updated |
| Data mapping and cleanup | Analysts and engineers, plus DeployOpen if scoped | One-time | Share of ThreatStream data that is STIX 2.1 clean, how many tags and custom fields need mapping, and how much stale or duplicate indicator data you keep |
| Rebuilding actors, campaigns and malware | Threat intelligence analysts | One-time | Number of threat models and reports to rebuild as linked STIX objects, and whether analysts reuse existing relationships or start new |
| Integration rework | Platform and SIEM or firewall engineers | One-time, then recurring change | Count of SIEM, firewall and EDR pulls that switch from ThreatStream APIs to OpenCTI connectors or GraphQL queries |
| Enterprise Edition licensing | Filigran, through a license agreement | Recurring if required | Whether you need audit logs, playbooks, organization segregation, full text indexing, AI insights or SSO options; confirm the terms directly with Filigran |
| LTS license key and upgrades | Your team, with DeployOpen if retained | Recurring | LTS releases need a specific license key, get only critical and security fixes after stabilization, and move on a roughly six-month cycle; plan the upgrade window and test effort |
How the migration differs by team size and starting point
Teams that use ThreatStream mainly as an indicator store and feed consumer have the smallest migration. The work centers on moving observables, their scores, tags and expiry rules, and confirming that downstream consumers still receive the same indicators. Because the data is largely flat, a short proof of concept with a sample export is usually enough to test field mapping before committing to a full load.
- Export scope: Confirm which observable types, tags and confidence values must survive, and check the per-format result caps in the ThreatStream export before planning batches.
- Mapping decisions: Decide whether each indicator becomes a STIX 2.1 indicator object in OpenCTI or an attribute in MISP, since expiry and scoring rules do not map one to one.
- Feed replacement: List every open or commercial feed still in use and decide whether a connector or a TAXII source replaces it.
- Deduplication: Plan how duplicate indicators from overlapping feeds will be merged after import.
- Verification: Compare counts and sample records per indicator type before cutting off the old source.
Before you start, ask your team to list every consumer of ThreatStream indicators, since a missed consumer is the most common gap in indicator-only moves.
Teams that also use ThreatStream for threat models, actor profiles, campaigns and malware analysis face a larger job. These objects carry relationships, such as an actor using a campaign that deploys a malware family against a sector, and those relationships must be rebuilt in OpenCTI's STIX 2 model rather than copied as flat fields. Expect manual review, because an export of objects does not guarantee that every relationship and narrative field arrives intact.
- Object inventory: Count actors, campaigns, malware and reports by type, and identify which ones analysts still open each month.
- Relationship rebuild: Recreate the links between objects in OpenCTI, starting with the most used actors and campaigns.
- Reports and narrative: Decide whether free-text analysis is imported as report objects, attached as files or archived outside the platform.
- Taxonomy alignment: Map ThreatStream labels to OpenCTI's ATT&CK-based structure, where the MITRE ATT&CK connector can add technique context.
- Analyst training: Plan time for analysts to learn the OpenCTI interface and query model before they rely on it.
Ask the vendor or your own analysts which relationships they rely on most, so the rebuild starts where the operational value sits.
Teams whose SIEM rules, firewall blocklists and EDR policies pull from ThreatStream usually have the most sensitive part of the migration. The effort depends on how many integrations exist, how each one authenticates and whether it expects a specific format or API call. A missed integration can leave a detection or block list silently empty, so the inventory must come from configuration, not memory.
- Integration inventory: Record every product that queries or receives ThreatStream data, including the API calls, schedules and output formats it uses.
- Connector options: Check whether OpenCTI connectors or MISP's export formats (such as NIDS rules for Suricata, Snort and Zeek) cover each consumer, and mark the gaps.
- Custom glue code: Identify scripts and middleware that call ThreatStream APIs, since these need rewriting against OpenCTI's GraphQL API or MISP's REST API and PyMISP.
- Parallel running: Feed both sources for a period and compare what each consumer receives.
- Cutover order: Move low-risk consumers first and leave blocking controls for last.
Confirm with each product owner which fields and formats their integration depends on, and whether the vendor supports the new feed source.
Teams that exchange intelligence with ISACs, customers, peers or government partners must rebuild trust relationships as well as data. In ThreatStream, sharing rules and partner access live in that platform, so the new arrangement needs its own agreements, identities and sharing controls. This work involves people and legal terms as much as technical configuration, and it cannot be finished by an export alone.
- Partner list: Record each partner, what they receive, what they send and the legal basis for the exchange.
- Sharing model: Choose between MISP's sharing groups and synchronization or OpenCTI's TAXII collections and live streams, and confirm that the model fits each partner's tooling.
- Agreement review: Check whether existing data sharing agreements name the platform or only the data, since a change of platform may need legal review.
- Onboarding sequence: Bring partners onto the new channel in small groups, and keep the old channel running until each partner confirms receipt.
- Identity and access: Plan how partner accounts are created and what OpenCTI Enterprise Edition features, such as organization-based segregation or SSO, your team needs.
Ask each partner which format and transport they can accept, because the answer decides whether a partner can move in the same window as your own systems.
What usually goes wrong and how to prevent it
Most failed ThreatStream to OpenCTI migrations lose meaning, history or connectivity rather than data volume. The cards below cover the mapping, governance, integration and sharing risks that tend to surface after cutover, each with a check to run before the old platform is switched off.
Lossy mapping of analytic objects
ThreatStream analytic objects such as threat models, observables tied to investigations and custom tags do not always map one to one onto STIX 2.1 objects. Relationships and free-text analyst notes can be flattened or dropped during export and import. Take a sample of threat models and actor records, import them into a staging OpenCTI instance, and compare each field against the source before you accept the mapping.
Lost approval and tagging history
Who approved an indicator, when it was tagged and why a score changed are often stored as platform state rather than as exported content. A STIX file usually carries the object, not its review trail. Ask the vendor which of these fields appear in your export, decide which history must be kept in an archive, and store that archive in your own evidence system before decommissioning.
Connector gaps found after cutover
Each feed, SIEM push or firewall integration that depended on ThreatStream needs an equivalent in OpenCTI, either a connector or a custom import. Gaps often appear only when a feed silently stops updating. Build a register of every inbound and outbound integration, mark its OpenCTI replacement, and confirm data flows in a parallel run with the old platform still live.
Sharing agreements not recreated
Trust relationships with partners, ISACs and peer organizations are configured in the source platform and are not part of a STIX file. Without them, data may stop flowing to partners on the first day of operation. List every sharing group, its members and its data restrictions, and agree the new sharing model with each partner in writing before the old group is retired.
Untested rollback path
Teams often plan the forward migration in detail and leave the way back undefined. If OpenCTI fails under production load, the old platform must still be able to receive and serve indicators. Define a rollback window, keep ThreatStream feeds and exports running until the window closes, and rehearse switching SIEM and firewall consumers back to the old source.
LTS licensing and upgrade cadence
OpenCTI Community Edition is Apache 2.0, but LTS releases are distributed as container images that require a specific LTS license key. Regular releases ship often, while LTS releases get only critical and security fixes after stabilization. Confirm with Filigran which edition and key your team needs, choose a release line, and budget the upgrade work each cycle as a recurring task.
Questions buyers ask before moving from ThreatStream to OpenCTI
What does it cost to move from ThreatStream to self-hosted OpenCTI?
The cost comes from four places: the infrastructure to run OpenCTI, the staff time to migrate and maintain it, the connectors and feeds you still need, and any paid edition or support you choose. Infrastructure is recurring and scales with data volume and the number of workers, since OpenCTI's documented sizing starts at 2 cores and at least 8 GB RAM for the platform, plus 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch. The Community Edition is Apache 2.0 licensed, so the software itself carries no license fee, while the Enterprise Edition uses a separate license. Ask any implementation partner for a quote built from a written scope that separates one-time migration work from recurring operations. Compare that quote with your current ThreatStream subscription and premium feed costs, which you should confirm from your own contract.
How long does a ThreatStream to OpenCTI migration take?
Duration depends on how much ThreatStream content you hold, how many integrations depend on it, and how many analysts must be retrained. No timeline figure is supplied for this migration, so ask for one in the written scope rather than relying on a generic estimate. Teams with a small set of indicators and few integrations usually finish faster than teams with years of analytic objects, custom feeds and many SIEM or firewall connections. Plan a parallel run in which both platforms receive the same indicators while you validate matches and reports. Fixed-scope engagements, which DeployOpen typically uses, put deliverables and timelines in writing before work starts.
What does the client team need to provide for the migration?
You need an owner for the threat intelligence program, administrators for the hosting environment, and analysts who can confirm which data is still relevant. Engineering staff must be able to manage the network, storage and identity components that OpenCTI depends on, including Redis, RabbitMQ, S3-compatible storage such as MinIO, and Elasticsearch or OpenSearch. Your team should also supply a current inventory of ThreatStream exports, TAXII subscriptions, SIEM and firewall integrations, and the people who rely on each one. Legal or partnership staff must review any sharing agreements before data moves. Confirm these responsibilities with the partner in writing before work starts.
Can our own team migrate from ThreatStream to OpenCTI without a partner?
Yes, a capable team can do the migration internally, but the work is broader than moving files. The main tasks are deploying the OpenCTI platform and workers, importing STIX 2.1 exports, rebuilding actor, campaign and malware entities, replacing integrations with OpenCTI connectors, and hardening the deployment. Teams without recent experience running containerized, multi-service platforms often find the dependency stack and upgrade routine the hardest part. Working through the migration with an implementation partner can cover planning, hardening, backup and documentation, while your team keeps ownership of the data. Compare the internal effort with a written scope before deciding.
Do indicators and analytic objects both move to OpenCTI?
Indicators usually move more cleanly than analytic objects, and the gap depends on how you exported them. ThreatStream's STIX output can be imported into OpenCTI, since OpenCTI structures its data on the STIX 2 standard. Actors, campaigns, malware and threat models, however, need to be checked after import and often rebuilt or relinked by hand so that relationships, confidence levels and sources are correct. Test a sample of each object type end to end before cutover. Ask the partner to document which fields map directly, which need transformation, and which must be recreated manually.
What happens to our sharing partners and trust groups after the move?
Sharing partners do not move automatically, so each trust relationship needs a deliberate re-establishment. OpenCTI covers the STIX and TAXII side through its connectors and streams, while MISP provides community sharing with granular sharing controls and synchronization between instances. Many teams run MISP as the sharing companion to OpenCTI, so confirm which partners exchange data over MISP and which use TAXII or other channels. Agree on the new exchange method, test it with each partner, and keep the old feed running until every partner has confirmed receipt. Existing ISAC or community agreements may also require approval before any data changes hands.
How are OpenCTI upgrades handled after go-live?
OpenCTI uses date-based version numbers, and you choose between two release tracks. Regular releases ship when ready, from daily to weekly, while LTS releases occur every 6 months and are each supported for 1 year, giving a 6-month overlap between consecutive LTS versions. LTS releases require a specific LTS license key and, after a one-month stabilization, receive only critical bug and security fixes. For example, the 7.260309.0 LTS line had reached hotfix lts.8 by October 2026. Plan a maintenance routine that tests each upgrade in a staging environment, keeps backups of Elasticsearch or OpenSearch and MinIO, and budgets for upgrade time at each cycle. Confirm the release track and license terms with Filigran before you commit.
What security controls should we check before OpenCTI holds our intelligence?
Check authentication, access segregation, audit logging and backups before loading production data. OpenCTI supports SSO through OpenID, LDAP, SAML, certificate and header authentication, but those options are part of the Enterprise Edition documentation, so confirm which ones your license covers. Audit logs, playbooks and organization-based segregation are also listed as Enterprise Edition features. Restrict network access to the platform and its dependencies, and document who can export or share intelligence. Security testing of the deployed platform is a sensible step before cutover.
How DeployOpen scopes and runs this migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted OpenCTI inside your own infrastructure, whether that is your cloud accounts, your data center or an air-gapped network. The work is scoped before any migration begins. In practice, the scope should name which ThreatStream content moves (indicators, threat models, actor, campaign and malware objects, and analyst notes), which OpenCTI connectors replace each current integration, and where the platform and its dependencies will run. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so each item in this list becomes a deliverable you can check.
A quote follows from that written scope rather than from a published price list, and DeployOpen does not publish one. To compare quotes, ask each provider to itemize the platform build, the STIX import and entity rebuild, connector replacement, hardening, backup and documentation, and any parallel-run period. Confirm who supplies the OpenCTI Enterprise Edition license if you need features such as SSO or audit logs, because that license is separate from the Community Edition under Apache 2.0 and changes the cost picture. Ask which OpenCTI release line the deployment will target and how upgrades will be handled, since LTS releases require a specific license key according to the product life cycle documentation.
Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes. Decide early whether your team will operate OpenCTI itself or whether a retainer will cover upgrades, backup verification and connector maintenance. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; your independent auditor or certification body does that work. Ask for the acceptance criteria in writing, including how migrated indicators and relationships will be checked against the ThreatStream source before the old platform is retired.
