Migrate from ThreatQ to MISP

Migrating from ThreatQ to MISP: what the move involves

If a ThreatQ renewal, a licensing change, a data residency rule or lock-in concern has brought you here, the short answer is that MISP can hold indicators, events, context and sharing in a self-hosted instance you run yourself. The harder part is not the storage. It is exporting what ThreatQ holds, mapping it onto MISP events, attributes, taxonomies and galaxies, and re-pointing every detection tool that currently receives ThreatQ pushes. This page is about planning that work, not a verdict on ThreatQ, which many teams run successfully for their own reasons.

In most organizations the move is led by security engineering, usually with an implementation partner for the export scripts, the MISP deployment and the integrations. Start by inventorying what ThreatQ does for you: which feeds are ingested, which indicator scores drive blocking decisions, which SIEM and EDR integrations receive data, and which intelligence is shared with peers. Each of these needs an owner in MISP. Confirm with your ThreatQ administrator which fields are exportable in your version, since the export format determines how much context survives. Ask the vendor how bulk export of indicators and their relationships is handled in your contract, and check whether any export is limited by license terms.

Plan for the recurring costs as well as the one-time work. Standing up MISP 2.5 on Ubuntu 24.04 with the provided installer is the currently recommended path, and the MISP download page lists Docker, RPM, Ansible and Puppet options if your platform team prefers them. Ongoing effort covers patching, feed curation, sharing agreements and the scripts that keep detection tools fed. The risk to manage most closely is a gap in detection during cutover, so run both platforms in parallel for a defined period, and treat each re-pointed integration as a change with a rollback plan. Written scope and a fixed deliverable list make these trade-offs easier to compare with a quote.

Which ThreatQ capabilities map to MISP, and what needs rework

This table maps common ThreatQ capabilities to their nearest MISP equivalents and marks each as clean, needs rework or gap. Read the rework and gap rows first, since they determine the migration effort. Confirm any ThreatQ-specific feature against the vendor's current documentation before you plan around it.

ThreatQ capability	MISP equivalent	Status
Indicator storage	Attributes within events, typed by category and type (for example, ip-dst or sha256), with comments and tags	Clean
Adversary and malware objects	Galaxy clusters for threat actors, malware and tools, plus object templates for structured context	Needs rework
Feed aggregation	Feeds ingested through MISP's feed settings, including default feeds; custom ThreatQ feeds must be re-created as MISP feeds or scripted imports	Needs rework
Indicator scoring and decay	No direct equivalent. MISP uses to_ids flags, warning lists and correlation, but has no native score that decays over time	Gap
Sharing and distribution	Distribution levels and sharing groups down to individual attributes, plus synchronization between MISP instances	Clean
Detection tool exports	NIDS exports for Suricata, Snort and Zeek, plus CSV, text and RPZ; SIEM and EDR pushes must be rebuilt as scheduled exports or API calls	Needs rework
Correlation and relationships	Correlation engine using exact matches and advanced patterns such as fuzzy hashes and CIDR overlaps	Clean
Integrations and automation	REST API with OpenAPI description and PyMISP; existing ThreatQ connectors and custom scripts must be rewritten against MISP	Needs rework

What data moves and which integrations must be rebuilt

A ThreatQ to MISP move has two halves: the intelligence itself, which can be exported and re-imported as MISP events and attributes, and the outbound pushes to detection tools, which must be rebuilt as MISP exports or API consumers. Each card below covers one data class or integration path, and each needs a check against the ThreatQ export options in your own version before work starts.

Indicators with types and sources

Indicators are the core of the move: IP addresses, domains, URLs, file hashes, email addresses and similar values, each with a type, a source feed and a first and last seen date. In MISP these become attributes inside events, so each ThreatQ type must map to a MISP attribute type, and unmapped types need a decision. Confirm which fields your ThreatQ version exports with each indicator, and whether source and status fields survive the export.

Adversaries, malware and reports

Adversaries, malware families and reports in ThreatQ usually carry descriptions, aliases and linked indicators. MISP represents them through event context, threat actor and malware galaxies, and tags from taxonomies. Expect manual reconciliation for aliases, because MISP galaxy names may not match your ThreatQ naming. Decide early whether a ThreatQ report becomes one MISP event or several, since the event is the unit of sharing in MISP.

Relationships and tags

Relationships between indicators, adversaries and reports are where ThreatQ's context lives. MISP links attributes to events and objects, and it can relate events to each other, but the relationship model differs from ThreatQ's. Export the relationship table or equivalent edges from your instance, and test that a sample of linked objects still shows the same associations after import. Tags are easier: map each ThreatQ tag to a MISP tag or a taxonomy entry.

Import paths: MISP JSON, STIX and CSV

MISP imports MISP JSON natively and can ingest STIX 1 and 2 and CSV, so the import path depends on what ThreatQ can export. Structured STIX export keeps more context, while CSV is simpler but flattens relationships and tags. Run a small test import of each indicator type and each report type into a non-production MISP instance, then compare counts and fields before the full load. Keep the source export files as an archive.

Taxonomies and galaxies for tagging

Taxonomies and galaxies replace ThreatQ's local tagging scheme with shared vocabularies. MISP ships taxonomies and galaxies for threat actors, malware, ransomware, tools and MITRE ATT&CK, and these are licensed separately from the AGPL software under CC0 or BSD terms. Map your ThreatQ tags to these where possible, and keep a local taxonomy for internal labels that have no public equivalent, so imported data stays searchable.

Feeds and sharing rules

ThreatQ feeds and TAXII or vendor connectors do not move on their own. In MISP, feeds are configured separately, including default intelligence feeds that ship with the platform, and each feed needs its own schedule, credentials and distribution setting. Review sharing groups and distribution levels before enabling any sync, because MISP can share down to individual attributes and a wrong default can publish internal data to a community.

Replacing SIEM and EDR pushes

ThreatQ pushes indicators to SIEM and EDR tools through its own integrations. MISP covers this with exports for Suricata, Snort, Zeek, RPZ, CSV and text, and with the REST API and PyMISP for scheduled pulls. Inventory every destination, record the format and frequency each one uses today, and confirm that the MISP export or API call returns the same fields and expiry logic. Detection tools often need a small transform step, which should be tested end to end.

How the migration runs in sequence

The sequence moves ThreatQ intelligence into MISP in controlled stages, so each feed and detection output is proven on MISP before any consumer depends on it. It ends with a documented cutover and an archive that can answer questions about past decisions.

Inventory ThreatQ objects, feeds and consumers
Your team lists every ThreatQ data type in use, including indicators, adversaries, malware, campaigns, reports, scores and tags. The same inventory covers each active feed and connector, each sharing partner or ISAC exchange, and each downstream consumer such as SIEM rules, EDR block lists, firewall feeds and ticketing workflows. Confirm the export options available in your ThreatQ version with your administrator or vendor, since the export path depends on your deployment. The step is complete when every object type and consumer has an owner and a written mapping target in MISP, such as an event, attribute, taxonomy, galaxy or export format.
Import one feed into a pilot MISP 2.5 instance
Install MISP 2.5 on a test host, using the installer on Ubuntu 24.04 that the MISP download page recommends for this version. Select one low-risk feed and import its indicators as MISP events, then apply taxonomies and galaxies such as threat actors, malware and MITRE ATT&CK so the data carries context. Check that attribute types, timestamps, tags and sharing distribution levels match what ThreatQ held. The step is complete when a sample of imported events has been reviewed by an analyst and the field mapping is signed off.
Build exports and test them against detection tools
Configure the MISP exports your detection tools need, such as CSV, text, STIX, Suricata, Snort, Zeek or RPZ, and test each output in a non-production copy of the consumer. Use the MISP API and the bundled PyMISP library where a pull model is needed, and confirm authentication and automation scripts on the test host. Record which ThreatQ scores or expiry rules have no direct MISP equivalent, so they can be rebuilt as tags, warninglists or local logic. The step is complete when each consumer ingests the test output and the team has a written list of gaps.
Run both platforms in parallel
Feed the same sources into ThreatQ and MISP for a period your security leadership agrees in writing, and keep the production consumers on ThreatQ. Compare what each platform produces for the same indicators, including volume, duplicates, false positives, expiry behavior and alerts generated in the SIEM and EDR. Review differences with the analysts who own detections and log each one as accepted, fixed or deferred. The step is complete when the differences are documented and the owners have approved the MISP outputs for each consumer.
Cut over consumers to MISP exports
Repoint each downstream consumer, one at a time, from ThreatQ feeds to MISP exports or API pulls, starting with the lowest-impact consumers. Keep the rollback path for each change until the consumer has run through a full normal cycle without incident. Update runbooks, service accounts and monitoring so that alerts reflect the new source. The step is complete when every consumer reads from MISP, ThreatQ is no longer the source for any production feed, and the change records are filed.
Decommission ThreatQ and retain archives
Disable ThreatQ feeds and connectors, then export a final archive of indicators, adversaries, reports, scores and audit history in a format your records and legal teams accept. Store the archive under your retention policy, with access controls that match the sensitivity of the data. Confirm with your vendor or contract owner the terms for ending the subscription and for any data return or deletion obligations. The step is complete when the archive is verified as readable, the retention owner has accepted it, and the ThreatQ service is switched off.

What does not move cleanly from ThreatQ to MISP

ThreatQ's scoring and decay logic will not transfer as a live calculation. MISP does not run a ThreatQ-style reputation score that decays indicators over time on the same model. Its closest native mechanisms are the to_ids flag on attributes, distribution and sharing levels, tags, and the decay and expiration concepts that depend on how you configure them and which tools consume the data. Before cutover, export the score values and their timestamps from ThreatQ, then decide per indicator class whether the score becomes a tag (for example, a confidence or priority tag from a taxonomy), an attribute comment, or a value your SIEM or EDR pipeline uses for thresholds. Confirm the exact decay behavior of your MISP version and of each downstream exporter in your own environment before you rely on it.

Custom object types, workflows and lifecycle state need an explicit mapping. ThreatQ custom object types and their relationships have no one-to-one equivalent in MISP, which models data as events, objects built from object templates, attributes and tags. Inventory every custom type in use, check whether a MISP object template or a custom template covers it, and record which relationships survive. ThreatQ-driven workflows, such as automatic triage, enrichment and push rules, must be rebuilt in external tooling or MISP automation, and lifecycle states such as active, expired or whitelisted need a documented tag scheme. Anything you cannot map should go on a loss register with an owner and a decision date.

Document accepted losses before cutover and get sign-off. For each gap, record the ThreatQ source, the replacement (warning list, tag, galaxy, object template, or external tool), the detection impact, and the people who accept the residual risk. Warning lists help flag known values such as public resolvers, but they are advisory and do not replace scoring. Ask your MISP administrators and detection engineers to test a sample of indicators through the actual export paths, and compare alert volume before and after. Keep the ThreatQ export as an archived record for audit and for any indicator that later needs historical context.

What drives the cost and duration of the move

This table lists the factors that change the effort and cost of moving ThreatQ intelligence into MISP, with the reason each matters and how to keep it under control. No duration or fee is given here, so use it to shape the questions you put to a written scope.

Driver	Why it changes effort	How to keep it down
Volume of indicators and events	Export, transformation and import time grows with record count, and large attribute sets need batch imports and validation passes.	Migrate by source or age, drop expired indicators before export, and agree which history must move versus stay archived.
Number of feeds and sharing communities	Each feed needs a MISP feed or fetch configuration, a mapping, and a check that duplicates and distribution levels are right.	Rank feeds by use, retire unused ones, and re-create only the feeds that still feed detection or sharing.
Downstream detection integrations	Every SIEM, EDR or firewall that ThreatQ pushes to must be repointed to MISP exports, taxonomies or API calls and then tested.	Inventory each integration first, map its data format (STIX, CSV, Suricata, Snort, Zeek or RPZ), and move the simplest ones first.
Depth of custom ThreatQ objects	Custom object types and fields have no direct MISP equivalent, so they need mapping to attributes, objects, tags, taxonomies or galaxies.	Document custom fields before migration, limit the mapping to fields used in decisions, and store the rest as tagged context.
Need for a parallel run	Running ThreatQ and MISP side by side means two sets of feeds, two sets of exports and reconciliation of conflicting scores.	Define a short overlap window with clear cut-over criteria and a named owner for each detection consumer.
Hosting and database choice	MISP 2.5 is recommended on Ubuntu 24.04 with the provided installer, and Docker, Ansible, Puppet and RPM options exist. The MISP 2.5.47 release, dated 17 September 2026, added a new database migration system with PostgreSQL support, so the choice of MySQL/MariaDB or PostgreSQL affects testing and upgrade planning.	Pick one supported database and install method early, build a test instance, and confirm the choice against the MISP 2.5 release notes before committing.
Staff who curate feeds	Someone must review imported events, correct tags and distribution, and keep feeds healthy after the move. This work recurs.	Assign named owners for feeds and taxonomies before cut-over, and write down curation rules so the workload is shared.

How the move differs by starting point

Teams that mostly collect feeds, score indicators and push them to SIEM and EDR tools have the most direct path to MISP. The core data is a large set of indicators with source, first and last seen dates, tags and any score or expiry values the team relies on. MISP stores these as attributes inside events, so the work is mostly mapping indicator types and deciding how to group them into events. The larger effort usually sits in the integrations, because each SIEM or EDR connection was built around ThreatQ's output and must be rebuilt around MISP exports or its API.

Indicator volume and types: Confirm how many indicators, and which types, feed each detection tool, since this sets the import size and the mapping work.
Scoring logic: ThreatQ scores and decay rules do not carry over automatically. Document the rules and decide whether MISP tags, warning lists or your SIEM logic will reproduce them.
Detection exports: Rebuild pushes using MISP's Suricata, Snort, Zeek, CSV and text exports or the REST API, then test each one against the detection tool it feeds.
Feed re-creation: Move each feed source into MISP feeds or a fetching job, and confirm that each feed's license terms allow the sharing you plan.

Before cutover, check that each detection tool receives the same indicator set from MISP that it received from ThreatQ over a comparable period.

What usually goes wrong and how to prevent it

Most failed ThreatQ to MISP moves fail at the seams: the data that crosses over, the tools that consume it, and the feeds that keep running during cutover. The cards below cover the risks we see most often and a check to run before each one can cause harm. Each risk ties back to the same discipline: decide the target version first, then prove each data path end to end.

Sharing and handling markings lost on import

ThreatQ records carry handling and sharing restrictions that teams often treat as metadata. When events are imported into MISP, those markings must be mapped onto MISP distribution levels, sharing groups and tags, or indicators can be shared wider than they were intended. Before loading production data, export a sample of restricted records and confirm each lands with the distribution level and sharing group your policy requires. Keep the original ThreatQ export as the reference copy.

Duplicate and mis-typed indicators

Indicators that were deduplicated in ThreatQ may be created several times in MISP if values are normalized differently, such as domains with trailing dots or hashes in mixed case. Wrong attribute types, for example a URL stored as a domain, also break correlation and detection exports. Run a type-and-value audit on a sample after each import batch, and compare counts per type between the two systems before you retire the old source.

Detection tools silently dropping updates

After you repoint SIEM and EDR integrations from ThreatQ pushes to MISP exports, the consuming tools may keep old lists, reject new formats or skip records that fail parsing. Nothing alerts you by default. Choose the export format each tool actually ingests, such as Suricata, Snort, Zeek, CSV or STIX, and confirm with a known test indicator that appears in the tool, is updated when changed, and is removed when expired.

Feeds stopping during cutover

Feeds that ran in ThreatQ often have no equivalent schedule in MISP until someone recreates them. A gap between the last ThreatQ pull and the first MISP pull can leave detections blind for a period nobody tracked. Build a feed inventory with owner, source, schedule and last successful run, then run both systems in parallel for a defined window and record the overlap before switching off the old feeds.

Adversary and context links left unmapped

Relationships between indicators, adversaries, campaigns and malware are where much of ThreatQ's value sits. A flat import keeps the indicators and loses the links, so analysts cannot pivot the way they did before. Map each ThreatQ object type to MISP events, attributes, objects and galaxy clusters, and test three known investigations end to end. Where a link has no clear MISP equivalent, document the gap and decide whether to recreate it manually.

Running MISP 2.4 or an unsupported version

Standing up a new MISP instance on 2.4 creates an environment that is already end of life and receives security fixes only. The MISP download page recommends MISP 2.5 for new deployments and advises against installing new 2.4 instances. Set the target version in the written plan, confirm the operating system and install method against the download page, and schedule the upgrade path before go-live rather than after the first incident.

Questions buyers ask before moving from ThreatQ to MISP

How much effort and cost should we expect for a move from ThreatQ to MISP?

The cost depends mostly on how much of your ThreatQ estate you intend to carry over, and no fixed figure is given here. The main components are the people who plan and run the migration, the servers or cloud capacity for a MISP instance and its supporting services, and the time your analysts spend validating imported data. Costs that are one-time include the export and mapping work, the import runs and the rebuild of feeds and detection exports. Recurring costs include hosting, patching and upgrades, and curation of feeds. Effort rises with the number of custom fields, the number of detection tools you push to, and how many feeds you re-create rather than retire. Ask any implementation partner for a quote built from a written scope that lists each of these components separately.

How long does a ThreatQ to MISP migration take?

The timeline is set by scope and by how many people can validate results, so it should be agreed in writing rather than assumed. Duration is driven by the volume and age of the indicators you keep, how cleanly ThreatQ's data model maps onto MISP events, attributes, taxonomies and galaxies, and how many SIEM and EDR integrations must be repointed. A common sequence is a short inventory, a pilot import of one feed or team, then staged cutover with a parallel run. Each stage has an approval point. Ask for a plan that shows which stages depend on your change windows and on approvals from detection engineering.

What does the migration need from our own team?

The work needs named owners on your side, because a migration cannot be completed from the outside alone. Expect requirements in four areas:

Threat intelligence analysts who define which indicators, tags and confidence levels must survive the move.
Detection engineers who own the SIEM and EDR integrations that currently consume ThreatQ exports.
Infrastructure staff who provide hosting, network access, backups and identity integration.
Compliance or records owners who confirm retention rules for historical intelligence.

Also plan for review time, since analysts must spot-check imported events before anyone relies on them.

Can our own staff run a ThreatQ to MISP migration without outside help?

Yes, a capable internal team can do it, but the decision depends on skills you already have. The work draws on several skills: exporting data from ThreatQ, mapping objects to MISP's model, running the MISP installer on Ubuntu 24.04 or another supported method, writing scripts against the REST API and PyMISP, and operating the instance afterward. Teams with prior MISP experience and spare capacity for a parallel run usually manage this in-house. Teams without that experience often bring in outside help for the mapping and integration work, and keep ownership of the data and detection content. Confirm your skill gaps before committing, and ask for a written split of responsibilities if you engage a partner.

Can MISP sharing replace the ThreatQ community feeds we rely on?

MISP can replace the sharing role of ThreatQ feeds, but only for sources that publish in a format MISP can ingest, and only with partners who choose to share with you. MISP synchronizes events and attributes between instances with distribution levels and sharing groups set down to the attribute level, and it ships with default intelligence feeds. Coverage will differ from a commercial feed set, so list every feed you currently consume and check each one for a MISP-compatible source, a community you already belong to, or a need to keep a feed connector. Sharing agreements, trust decisions and the quality of what partners send are your responsibility to confirm.

What happens to our ThreatQ data retention and licensing during the move?

Your ThreatQ licence governs how long you may use and export its data, so read the agreement and confirm the export rights and end dates with your vendor before cutover. Keep ThreatQ read-only through a defined parallel period so that historical lookups remain possible. Retention in MISP should be set by policy, since MISP stores what you import and applies its own sharing settings. Confirm with your legal and records teams which indicators, context and audit trails must be kept, and in what form. MISP's software is licensed under AGPL-3.0, while its taxonomies and galaxies carry separate CC0 1.0 or BSD terms, which your legal team should review.

What are the security and operational risks when we move to MISP?

The main risks are data loss during export, false confidence in imported data, and an unpatched instance exposed to the network. Mitigate them with:

Reconciliation counts and sample checks between ThreatQ and MISP before each cutover step.
Access control through your identity provider, with sharing groups that match your confidentiality rules.
A patching and upgrade routine, since MISP 2.4 is end of life with security fixes only and new 2.4 installs are advised against, so deploy MISP 2.5.
Tested backups of the MISP database and configuration.

Record each control so your security team can review it.

How DeployOpen scopes and runs the move

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a move from ThreatQ to MISP, we start from a written scope that covers which intelligence, feeds and detection integrations must carry over, then build and hand over the MISP environment in your own cloud accounts, data centers or air-gapped network.

How we scope

Inventory ThreatQ indicators, adversaries, feeds, scores and the detection tools that receive pushes from it
Agree in writing which data moves into MISP events, attributes, taxonomies and galaxies, and what is retired
Confirm sharing groups, distribution levels and any trusted communities that must receive MISP data
Fix deliverables, timelines and responsibilities in a fixed-scope agreement before any work begins

How we build

Deploy MISP on infrastructure you choose, using the installer, Docker, Ansible or Puppet options your team prefers
Map ThreatQ exports to MISP formats and test imports against a non-production instance first
Recreate feeds and replace ThreatQ pushes with MISP exports such as Suricata, Snort, Zeek and STIX
Test correlation, exports and API access with PyMISP before any detection tool is repointed

How we hand over

Document the architecture, data mapping, feed configuration, export jobs and integration endpoints
Provide runbooks for user and sharing group administration, updates and backup and restore
Walk operators through daily triage, indicator review and the decommissioning steps for ThreatQ
Deliver evidence of configuration and test results that your auditors or internal reviewers can examine

How we support

Cover upgrades between MISP releases, including the migration from MISP 2.4 where it still runs
Keep feeds, exports and integrations tested after changes to your detection stack
Offer ongoing support, upgrades and continuous testing as a retainer after the handover
Confirm with the MISP project and your own environment which features your deployment requires