Migrate from ThreatConnect to MISP

Migrate from ThreatConnect to MISP: what moves and what needs rebuilding

Moving from ThreatConnect to MISP is feasible when indicator sharing with communities is the core workload. The effort and risk depend on three things: how your sharing groups are structured, which feeds and sync partners you depend on, and how many SIEM and blocking integrations read from the platform today. Renewal timing, data residency requirements and lock-in concerns are common reasons to start, but they do not change the shape of the work. Plan the migration around the sharing model first, because that is where the two products differ most. The work is usually done by platform engineering (hosting, upgrades, backups and access), security engineering (SIEM, firewall and EDR integrations) and threat intelligence staff who know which communities and partners you exchange with. Many teams bring in an implementation partner for the MISP build and the integration work, but the people who decide sharing policy must stay in the room. Confirm your internal roles and the partner's written scope before any data moves.

ThreatConnect organizes intelligence around owners, communities and sources, with access following those owners. MISP organizes it around events and attributes, with distribution levels, sharing groups and sync connections that decide who sees what. A ThreatConnect owner rarely maps one to one to a MISP organization or sharing group, so copying the old structure usually carries its mistakes across. Inventory your communities, their agreements and the distribution each indicator needs, then rebuild the sharing groups and sync rules in MISP and test them with each partner. Before cutover, check three things. Confirm that each partner's sync settings and trust relationships are re-established in MISP, not assumed from ThreatConnect. Run a test export of a representative indicator set through the formats your SIEM and blocking tools consume, such as STIX, CSV or the Suricata, Snort and Zeek outputs, and verify the fields arrive intact. Finally, confirm which integrations need a rewritten connector and which can read MISP's REST API directly, using the MISP features page and the API documentation as your reference. Run both platforms in parallel until those checks pass.

Which ThreatConnect capabilities map to MISP and which need rework

This table compares the ThreatConnect capabilities that community sharing teams rely on with their closest MISP equivalents, and flags where the move is clean, needs rework or leaves a gap. Read each row against your own owners, feeds and integrations, because a clean mapping in MISP still depends on how your sharing groups were set up. The main takeaway is that indicator sharing and SIEM or blocking exports map well, while playbooks and case management need a separate plan.

ThreatConnect capability	MISP equivalent	Migration note
Indicator storage	Attributes within events, with types, categories and to-IDS flags	Clean for most indicator types. Confirm how your custom indicator types and extra fields map to MISP attributes and objects.
Sharing with communities	Distribution levels and sync with trusted MISP instances	Needs rework. Rebuild community membership and sync connections in MISP, then test that events arrive as expected.
Sharing groups and owners	Sharing groups and organisations, controlled per event or attribute	Needs rework. ThreatConnect owners do not map one to one, so design sharing groups before importing data.
TAXII exchange	MISP exports STIX 1 and 2 and offers a REST API; confirm TAXII 2.1 coverage in your own environment	Needs rework. Do not assume TAXII 2.1 parity. Test your partners' TAXII clients against a MISP instance before cutover.
Tagging and taxonomies	Tags from shareable taxonomies and galaxies, including MITRE ATT&CK	Clean for standard taxonomies. Custom ThreatConnect tags need a mapping table and a review of naming.
Correlation	MISP correlation engine with exact matches, fuzzy hashes and CIDR overlaps	Clean in principle. Compare match results on a sample set, since correlation rules are not the same as ThreatConnect's.
SIEM and blocking exports	Exports to Suricata, Snort, Zeek, RPZ, CSV, OpenIOC and STIX formats	Needs rework. Each consumer must be pointed at the MISP export or API and its output format re-verified.
REST API use	OpenAPI-described REST API with restSearch and the PyMISP library	Needs rework. Scripts written against ThreatConnect endpoints must be rewritten, though PyMISP covers common tasks.
Playbooks and case management	No built-in equivalent; MISP focuses on sharing and correlation	Gap. Plan a separate automation or case tool, or use OpenCTI or another platform for these workflows.

Which data, feeds and integrations to move and how

A ThreatConnect to MISP move breaks into five workstreams: indicator and event export, ownership mapping, feeds, sharing and SIEM or blocking connections. Each one depends on the others, so the export inventory should come first. Validate every export path against your own tenant and permissions before you rely on it.

Indicators and events export

Start by inventorying the indicators, groups and associations you hold in ThreatConnect and the API route you will use to pull them, either the v2 or v3 REST API. Confirm with your ThreatConnect administrator which owners your API user can read, because export rights often differ between your own organization, communities and imported sources. Record counts per owner and per indicator type so you can reconcile MISP attribute counts after import. Exports that omit tags or associations will lose context that analysts rely on, so test that fields survive the trip.

Owner and source mapping

ThreatConnect owners and sources do not map one to one onto MISP organizations and sharing groups. Decide which ThreatConnect owner becomes your local MISP organization, which becomes a sharing group, and which should be kept as a tag for provenance. Use MISP distribution levels and sharing groups to set who receives each event, down to individual attributes where needed. Write this mapping down and have legal or information sharing staff approve it before any community sync is enabled, since a wrong distribution setting cannot be undone once data has left your instance.

Feeds, taxonomies and warning lists

MISP ships with default intelligence feeds, shareable taxonomies, warning lists and galaxies for threat actors, malware, ransomware, tools and MITRE ATT&CK. Review which of these you actually used in ThreatConnect and enable only those, then rebuild any custom feeds you relied on as MISP feeds or as scheduled imports. Taxonomies and galaxies carry their own licenses, CC0 1.0 or BSD 2-clause, which are separate from the AGPL-3.0 software license, so note them in your compliance records. Confirm each feed's source terms before redistributing its content to partners.

Sharing and community exchange

If your ThreatConnect use centers on communities, MISP sync is the core of the rebuild. MISP synchronizes events and attributes between instances with granular sharing controls, so each trusted partner must be configured with a matching connection and agreed distribution rules. Export data over TAXII where a partner still consumes STIX over that transport, then validate what arrives on the MISP side, since STIX 1 and STIX 2 mappings may not carry every ThreatConnect field. Ask each community which format and transport it expects before you cut over.

SIEM feed reconnection

Your SIEM probably pulls indicators from ThreatConnect through a connector or scheduled export. MISP offers several export formats that cover common detection stacks, including CSV, text, and NIDS rules for Suricata, Snort and Zeek. Choose the format that matches each consumer, and rebuild the pull job with a filter on the tags or distribution levels you intend to publish. Compare alert volume for one week before and after the switch, since different formats can change how matches are generated.

Blocking and list integrations

Firewalls, DNS filters and proxies that consume ThreatConnect lists need a MISP equivalent. MISP can export RPZ zone data for DNS resolvers and list-style outputs such as CSV or text, which many blocking tools can ingest. Confirm each consumer's expected list format, update cadence and authentication method with its vendor, and test the path in a staging environment first. Keep the old ThreatConnect feed running in parallel until blocking behavior matches, so a gap in coverage does not go unnoticed.

How the migration sequence runs from inventory to decommission

The sequence moves ThreatConnect indicators, sharing groups and integrations into MISP one consumer at a time, with a parallel run that proves sharing works before anything is switched off. Each step ends with a written output that the next step depends on.

Inventory owners, groups, feeds and consumers
Your threat intelligence lead and an integration owner list every ThreatConnect owner, community, source and feed you publish or consume, along with each SIEM, firewall, EDR or blocklist that pulls from the platform. Record who receives each feed, the sharing terms that apply, and any retention obligations for indicators and their associations. The output is an inventory register that names every consumer and the owner of each one. The step is complete when the register is reviewed by the people who run each consumer, and nothing is left unassigned.
Stand up a pilot MISP instance
Your platform engineers deploy a pilot MISP instance inside your own infrastructure, using MISP 2.5 rather than 2.4, since the project recommends 2.5 for new deployments and advises against new 2.4 installs. The MISP download page recommends Ubuntu 24.04 with the provided installer, and Docker images, RPM packages, an Ansible role and a Puppet module are also listed as options, so choose the one your team can patch and back up. Confirm authentication, backups and the sharing groups you mapped in step one. The output is a validated pilot with a test import from an exported ThreatConnect dataset.
Run a parallel sync with trusted communities
Your threat intelligence team keeps ThreatConnect in production while publishing the same events from the pilot to a small set of trusted communities through MISP synchronization. Compare what each community receives against what ThreatConnect sent, checking distribution levels, sharing groups and attribute counts. Review how correlation and tagging behave on real indicators and adjust taxonomies or galaxies where needed. The output is a sync log that shows which events reached which partners, along with a list of discrepancies and how each was resolved.
Cut over feeds and integrations one consumer at a time
Your integration owners move one SIEM, blocklist or NIDS consumer at a time from ThreatConnect to MISP exports, such as the Suricata, Snort or Zeek formats, the STIX outputs or the restSearch API. Each change is tested against a known indicator and checked for expected detections and blocks before the next consumer moves. Keep the rollback path for each consumer until it has run cleanly. The output is a signed-off cutover checklist per consumer, approved by the team that owns that system.
Decommission ThreatConnect after retention is met
Your compliance lead confirms that every retention obligation for indicators, associations and sharing records is satisfied, and that any data that must be kept is archived in a format you can read later. Your contract owner then confirms with Dataminr or your ThreatConnect account team how data is returned or deleted at the end of the subscription, and what the export terms are. Revoke API keys and integration accounts, then close the platform. The output is a decommission record that lists archived datasets, revoked credentials and the confirmed end date.

Why sharing groups and communities need rebuilding, not copying

Community agreements from ThreatConnect cannot be carried over as a file. Each one has to be re-established in MISP as its own sync relationship with its own trust and permissions. MISP applies distribution levels and custom sharing groups down to individual attributes, so the sharing decision is made per attribute rather than per feed or per owner. Before any import, list every ThreatConnect community, source and owner you currently publish to or receive from, then record for each one who must see the data, which attributes may leave your organization, and whether the partner has a MISP instance or will consume exports. Synchronization between MISP instances and trusted communities is configured separately, so a partner who was reachable in ThreatConnect is not automatically reachable in MISP. Confirm the partner's technical contact, their MISP version and their acceptance of your sharing terms in writing before you create the connection.

The correlation engine, taxonomies and galaxies are separate MISP capabilities, and none of them turns on because events were imported. Correlation runs across events on your instance and needs its own review of exact matches, fuzzy hashes and CIDR overlaps, so test it on a sample of migrated events before relying on its output. Taxonomies and warning lists give events a shared vocabulary, and galaxies cover threat actors, malware, ransomware, tools and MITRE ATT&CK. Map the tags your analysts use in ThreatConnect to these vocabularies deliberately, because a tag that matches nothing in MISP will not be searched or shared as you expect. Note that MISP taxonomies and galaxy data are licensed under CC0 1.0 Universal or the 2-clause BSD license, separate from the AGPL version 3 license that covers the MISP software. Your legal team should review both licenses if you plan to redistribute this content to partners, and the MISP download page is the place to check the current license terms.

How to run both platforms in parallel and cut over safely

Detection teams usually consume indicators as lookup lists, enrichment fields or scheduled searches inside the SIEM. During the parallel period, MISP should feed the same detection content while ThreatConnect remains the source of record, so you can see whether the new feed produces comparable alerts. Compare indicator volumes per feed, the share of SIEM hits that resolve to an indicator in both systems, and how quickly new MISP attributes appear in the SIEM after publication. Check that MISP exports, such as the text or CSV output or the STIX feed, parse correctly in the SIEM connector you already run.

Volume parity: Count indicators per type and per feed in both platforms and document each gap before you rely on MISP.
Match rate: Replay a fixed window of SIEM events against both lookups and compare which hits each system produces.
Freshness: Measure the delay between an event being published in MISP and its appearance in the SIEM lookup.
Parsing errors: Log failed imports and attribute types the SIEM ignores, such as fields the connector does not map.
Rule ownership: Record which detection rules reference ThreatConnect owners or tags, because those references will need new logic.

Cut over only when the match rate and freshness are acceptable to the detection lead and no open parsing errors affect high-priority rules. Confirm the exact export options and SIEM connector support in your environment before you start.

What drives migration cost and duration

This table lists the factors that move the effort of a ThreatConnect to MISP migration up or down, with how each one changes cost or time and what to do about it. Read it before requesting a scoped quote, because the largest drivers are usually sharing agreements and the number of downstream consumers rather than raw indicator volume.

Driver	Why it moves cost or time	How to reduce it
Communities and sync agreements	Each community needs its own MISP sharing group, sync configuration and trust arrangement, and each agreement must be renegotiated with its members.	Inventory every community and its terms first, retire inactive ones, and confirm which agreements allow re-sharing into MISP.
Volume and age of indicators	Large or old indicator sets take longer to export, transform and validate, and stale data adds review work without adding value.	Migrate active, recently seen indicators first and archive the rest in read-only form with a documented retention rule.
Owners and permission rules	Each ThreatConnect owner, organization and source must map to a MISP organization, sharing group or distribution level, and mismatches create access errors.	Build a written mapping table of owners to MISP organizations and distribution levels before any import begins.
SIEM and blocking consumers	Each SIEM rule, firewall, proxy or DNS feed that reads from ThreatConnect must be repointed and tested, and blocking consumers need the most validation.	List every consumer with its data format, update cadence and owner, then reconnect them in order of business risk.
Custom taxonomies and playbooks	Custom fields, tags and playbooks have no direct equivalent, so each one needs a MISP taxonomy, galaxy, script or separate automation tool.	Count custom objects and playbooks early, reuse MISP taxonomies and galaxies where they fit, and drop logic that no longer serves a purpose.
Hosting and backup design	A self-hosted MISP needs a supported Ubuntu 24.04 host or container setup, database, Redis, backups and recurring patching, which are paid as infrastructure and staff time.	Standardize on the installer or Docker images, automate backups and restore tests, and budget patching as a recurring task.
Staff time for validation	Analysts must confirm that imported events, correlations and exports match the source data, and this review often takes the longest share of the project.	Agree on sample sets and acceptance criteria in advance, and ask the implementation partner for a fixed validation step in the written scope.

What usually goes wrong and how to prevent it

Most failed ThreatConnect to MISP moves do not fail on the software itself. They fail where ThreatConnect owner logic, distribution settings, enrichment data and live integrations meet MISP's own sharing model. Each card below names one risk and the check that catches it before cutover.

Copying owner logic into sharing groups

ThreatConnect owners, communities and sources do not map one to one onto MISP organisations and sharing groups. Teams that create a sharing group for every ThreatConnect owner often end up with groups that no trusted partner actually belongs to, or with partners who can see events they should not. Before importing, write down which community each owner feeds, which MISP organisations represent those partners, and who approves membership. Then test sync with one partner instance before moving the rest. Ask your community operator how they expect sharing groups to be set up.

Wrong distribution levels on import

MISP distribution levels decide who receives an event or attribute, and they can be set at both event and attribute level. A bulk import that defaults to a wide distribution can push internal indicators to external synchronization partners within minutes of going live. Review the distribution value that every import job uses, and confirm that internal-only data is set to the narrowest level before any sync is enabled. Run a test import of a sample that includes restricted items and check what leaves the instance.

Losing tags and enrichment in export

Many ThreatConnect records carry tags, associations, confidence scores and analyst notes that a basic indicator export does not preserve. Tags that MISP does not recognise may be dropped, and taxonomy names can differ from the ones your SIEM expects. Compare a sample of records across both platforms field by field, including tags and associations. Decide early which ThreatConnect tags map to MISP taxonomies or galaxies, and document any field that has no equivalent so the gap is a decision, not a surprise.

Breaking SIEM and blocking feeds at cutover

Firewalls, SIEM rules and blocklists often pull indicators from ThreatConnect through a fixed endpoint, a scheduled export or a custom script. Those consumers stop receiving data the moment the old feed is turned off, and nothing alerts until someone notices a gap. Inventory every consumer and the format it expects, including Suricata, Snort, Zeek and RPZ outputs that MISP can generate. Run the MISP feed in parallel for a defined period, compare outputs, and switch consumers one at a time with a rollback step ready.

Deploying MISP 2.4 for new instances

MISP 2.4 is end of life and receives security fixes only, and the project strongly advises against installing new 2.4 instances. Teams that build from an older guide, a cached container image or an internal template can start a new deployment on a version that will not receive feature work. Deploy MISP 2.5 for any new instance, and check the version on every server before loading production data. Plan the upgrade path for any existing 2.4 instance, using the upgrade script the project provides for Ubuntu.

Underestimating playbook and case gaps

MISP stores and shares indicators and events well, but it is not a playbook engine or a full case management tool. ThreatConnect playbooks that enrich, route and act on indicators, and case workflows with tasks and artifacts, need a separate plan. Map each playbook and case type to a replacement, whether that is OpenCTI, a SOAR tool or a documented manual step, before retiring ThreatConnect. Ask the team that owns those workflows to sign off on the list, because analysts often discover these dependencies only after the licence ends.

How the migration differs by team size and starting point

A single team usually uses ThreatConnect to gather indicators from a small set of feeds, push a curated list to a few partners and feed a SIEM or blocking device. The MISP rebuild is mostly a matter of one instance, one set of distribution levels and a handful of sync or export jobs. Because the sharing circle is small, the main risk is losing the informal rules that decide what gets published and to whom.

Feed inventory: List every feed ThreatConnect ingests today, including the ones that run through playbooks, and decide which MISP default feeds or custom feeds replace each one.
Sharing rules: Write down who receives which indicators now, then map those audiences to MISP distribution levels or a small set of sharing groups.
Integration count: Count the SIEM, firewall and blocking consumers. Most can read MISP exports such as CSV, Suricata, Snort or Zeek output, but confirm each consumer's supported format.
Single administrator: Confirm who will own patching and upgrades, since a one-person instance has no second operator.

Confirm with your team lead which indicators are published externally, because those decisions are often undocumented in ThreatConnect.

Questions buyers ask before moving from ThreatConnect to MISP

How much effort and cost should we expect to move from ThreatConnect to MISP?

The cost depends mostly on how much of ThreatConnect your team uses and how much history you need to keep. MISP's software is licensed under AGPL-3.0, so there is no license fee for the platform itself. The recurring costs are servers, storage, backups, patching time, and the people who run the instance. One-time costs include exporting and mapping data, rebuilding sharing groups and feeds, and reconnecting SIEM and blocking integrations. Ask any implementation partner to price these as separate line items in a written scope, and ask them to state which ThreatConnect owners, communities and sources are in scope, since that changes the export and mapping work more than anything else.

How long does a ThreatConnect to MISP migration take?

Timing varies with the number of communities and sharing groups you run, the volume of indicators you need to carry over, and how many integrations depend on ThreatConnect outputs. Teams that only move active indicators and a small set of feeds usually finish faster than teams that must keep years of historical groups and cross-community relationships. Ask for a timeline that separates export, MISP build, sharing group rebuild, integration testing and cutover, and confirm which of those steps depend on your change windows and the approval of your community partners.

What does the migration need from our internal staff?

Your staff need to own the decisions that only your organization can make. These include which indicators are still valid, which sharing agreements and TLP-style handling rules apply, who may see which events, and which SIEM or blocking rules must keep working on day one. Platform engineers need to run the MISP install, configure authentication and backups, and manage sync with partner instances. Analysts need to review mapped data and confirm that correlation and tagging behave as expected. Plan for these people to be available during testing, because most delays come from waiting on those decisions rather than from the technical work.

Can our own team migrate from ThreatConnect to MISP without outside help?

A team with Linux administration, API scripting and threat intelligence experience can do much of the work in-house. MISP's documentation describes an installer for Ubuntu 24.04 and other install options, and its REST API and PyMISP library support scripted exports and imports. The harder parts are rebuilding sharing groups correctly, testing SIEM and blocking integrations, and building a repeatable backup and upgrade routine. If your team lacks those skills or bandwidth, a fixed-scope engagement from DeployOpen can plan, implement, integrate, harden and document the platform inside your own infrastructure. Keep in mind that DeployOpen does not issue audit reports or certifications, so compliance evidence still goes to your independent assessors.

Does MISP cover ThreatConnect playbooks and case management?

No, not in the same way. MISP is built for collecting, storing, correlating and sharing indicators and events, with correlation, taxonomies, galaxies and synchronization as its core features. It does not provide ThreatConnect-style playbooks or full case management out of the box. Teams that rely on playbooks need a separate automation tool, and teams that run cases need either a case management tool or a platform such as OpenCTI for linking cases to intelligence objects. Map each playbook and case workflow you use today before you commit, and treat any gap as a separate scope item with its own owner and cost.

What should we ask for in a fixed-scope quote for this migration?

Ask for a written scope that lists each deliverable, the ThreatConnect owners and communities in and out of scope, the MISP version and install method, and the integrations to be reconnected. Request a separate line for data export and mapping, sharing group and feed rebuild, SIEM and blocking tests, backup and restore validation, and documentation. Ask how cutover and rollback will work, what your staff must provide and by when, and which post-migration support is included or offered as a retainer. Ask which items depend on decisions outside the engagement, since those drive both the timeline and the final cost.

How DeployOpen scopes, runs and supports the MISP migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a ThreatConnect to MISP move, we start with a written scope that names the communities, sharing groups, feeds and integrations to be rebuilt before any data moves.

How we scope

Inventory the ThreatConnect owners, communities and sources you export, and confirm which ones you are permitted to move.
Map each sharing community to MISP sharing groups, distribution levels and sync partners in the written scope.
List every SIEM, blocking and TAXII consumer that depends on ThreatConnect, with the MISP export format each one will read.

How we build

Deploy MISP 2.5 on your infrastructure using the provided installer on Ubuntu 24.04 or another install method you choose.
Rebuild sharing groups, feeds and sync connections, then test them with a restricted pilot community before wider use.
Reconnect SIEM and blocking integrations through MISP exports and the REST API, and test each indicator feed end to end.

How we hand over

Document the deployment, sharing group configuration, feed definitions and integration runbooks in your own environment.
Walk your analysts and community administrators through correlation, taxonomies, galaxies and the sharing controls they will use.
Deliver a cutover checklist and rollback plan so your team can confirm each integration before ThreatConnect access ends.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
Upgrades follow the MISP release line, so retainer work covers version changes and security fixes on your schedule.
Confirm with us in the quote which support hours, response paths and upgrade windows apply to your environment.

Migrate from ThreatConnect to MISP