Migrate from EclecticIQ to MISP

Migrate from EclecticIQ to MISP: what the move involves

Most teams arrive here because an EclecticIQ renewal is due, a data residency rule now requires intelligence to stay on their own hosts, or the sharing model with partners has changed. In each case the move is a re-platforming of indicators, events, sharing groups and feeds, not a lift-and-shift. EclecticIQ is built around STIX objects and relationships, while MISP is built around the *event*: a container that holds attributes, objects, tags, galaxies and a distribution level that decides who receives it. Data can be exported and imported, but the grouping, provenance and sharing decisions have to be re-expressed in MISP terms. Plan to review each sharing relationship rather than copy it across unchanged.

The work is usually shared between the platform team (hosts, database, backups, upgrades), security engineering (authentication, connectors into SIEM and SOAR, NIDS rule exports for Suricata, Snort and Zeek) and the threat intelligence team, which owns the taxonomy choices, event structure and the decision on which communities receive which data. Start on MISP 2.5, which the MISP download page recommends for new deployments, and avoid building on 2.4, which is end of life. Confirm with the vendor and your own environment which operating system, installer or container option your platform standard supports, since the download page lists several.

The effort depends mostly on how much of the EclecticIQ estate is live. Historical data is often a bulk export and import exercise. Active feeds, partner sharing and automated enrichment need to be rebuilt and tested one at a time, and that is where the risk sits: a sharing group set up with the wrong distribution level can expose intelligence to parties who should not see it. Ask any implementation partner for a written scope that lists each feed and sharing relationship, the mapping rules for object types with no direct MISP equivalent, and a count reconciliation against the source before cutover.

Which EclecticIQ capabilities map to MISP, and where the gaps are

This table compares the main EclecticIQ capabilities a migration touches with what MISP documents, marking each as clean, needs rework or gap. Confirm each row against your own EclecticIQ configuration, because custom objects, outgoing feed settings and authentication setups vary by deployment and the gap column is where most migration effort goes.

Capability	MISP position	Status and what to confirm in EclecticIQ
Indicator storage	MISP stores events and attributes, with attribute types for indicators such as IPs, domains, hashes and URLs	Clean for common observables. Confirm which entity types your EclecticIQ instance holds, since non-indicator entities need a mapping decision
STIX export	MISP exports STIX 1 and STIX 2 documents, and imports from STIX formats	Needs rework. Confirm STIX version and whether relationships, observables and custom objects survive the round trip before you rely on it
Export formats	MISP JSON, CSV, text, OpenIOC, Suricata, Snort, Zeek and RPZ formats are documented	Clean for detection feeds. Confirm which EclecticIQ outgoing feed formats your consumers depend on, since each downstream tool may need a rebuilt feed
Sharing and distribution	Distribution levels and custom sharing groups apply down to individual attributes	Needs rework. Map each EclecticIQ feed recipient and access group to a MISP sharing group and distribution level before importing
Synchronization	MISP synchronizes events and attributes between instances with granular controls	Needs rework. Confirm which partners were on EclecticIQ feeds and whether each has a MISP instance or only a TAXII or file-based path
Correlation	MISP's correlation engine links attributes by exact match and advanced patterns such as fuzzy hashes and CIDR overlaps	Clean for matching. Confirm whether your analysts rely on EclecticIQ relationship graphs, which MISP represents differently
Taxonomies and galaxies	MISP includes shareable taxonomies, warning lists and galaxies for threat actors, malware, ransomware, tools and MITRE ATT&CK	Needs rework. Confirm your EclecticIQ tagging scheme and map custom labels to existing taxonomies or new local ones
REST API access	MISP provides an OpenAPI-described API with restSearch and the PyMISP library	Needs rework. Confirm every integration that calls EclecticIQ's API, since each call needs a MISP equivalent or a rewritten client
Authentication	MISP supports OIDC authentication through the OidcAuth plugin, documented in its README	Needs rework. Confirm your identity provider and group claims, and whether EclecticIQ role mappings can be reproduced in MISP roles
Custom objects and non-indicator intelligence	MISP has objects and galaxies for many structured types, but no one-to-one copy of every EclecticIQ entity model	Gap. List every custom entity type and relationship in your EclecticIQ instance and decide per type whether to map, flatten or retain in an archive

The migration sequence from inventory to decommission

This sequence moves EclecticIQ intelligence, sharing relationships and consumers into MISP in controlled stages, so each step produces evidence that the next one can rely on. Nothing is decommissioned until counts, sharing rules and downstream tools have been checked against the source.

Inventory feeds, partners and data volumes
Start by listing every incoming and outgoing feed, every sharing partner or community that receives or sends indicators, and every tool that consumes EclecticIQ output, such as firewalls, SIEM rules or SOAR playbooks. For each item, record the format, the sharing scope and the approximate object counts by type, and the owner who can confirm them. The output is a written inventory signed off by the threat intelligence lead and the platform owner, with each consumer marked as in scope or out of scope for the move.
Export a representative sample
Export a bounded set of intelligence from EclecticIQ in STIX or CSV, covering each object type and each sharing level present in the inventory. Keep the export files in a restricted location on your own infrastructure, since they contain live indicators and possibly sensitive reporting. The output is a sample set with a manifest that lists the object types, the record counts from the source and the export method used, so that later comparisons have a fixed baseline.
Pilot import into a MISP test instance
Install a MISP test instance on your own servers using the installer for the MISP version you have chosen, then import the sample set as MISP events. Check how STIX fields map to MISP attributes and objects, and record every field that lands in a generic attribute, a comment or nothing at all. The output is an import log and a field mapping sheet that shows which EclecticIQ properties map cleanly, which need a custom object or galaxy tag, and which need a decision on whether to keep them.
Reconcile counts and sharing rules
Compare the number of events, attributes and relationships in MISP against the sample manifest, object type by object type, and investigate every difference before continuing. Recreate the sharing groups and distribution levels from the inventory, then test that a record marked for one partner is not visible to others. The output is a count reconciliation report and a sharing matrix that the data owner has reviewed and accepted.
Run both platforms in parallel
Keep EclecticIQ as the system of record while MISP receives the same intelligence through a defined daily or batch load, and set up MISP synchronization or feeds with the partners agreed in the inventory. Compare what each platform publishes for a fixed set of indicators and alerts, and log any gap in timing, content or distribution. The output is a parallel run log with discrepancies, their causes and their fixes, reviewed on a fixed cadence until they are closed.
Cut over feeds and consumers
Repoint each consumer in the inventory to the MISP export or feed endpoint, one group at a time, starting with the lowest-risk consumers. Confirm that each one receives data in the expected format and that detections or blocks still fire on a known test value. The output is a list of repointed consumers, each with the date of change, the person who verified it and the test result, plus a rollback note for each.
Decommission EclecticIQ
Once every consumer has run on MISP through an agreed observation period, take a final export from EclecticIQ and archive it under your retention policy, then remove partner feeds and API credentials from the old platform. Confirm with your contract owner which data must be retained for legal or regulatory reasons before deletion. The output is a decommission record that lists the final export checksum, the revoked credentials, the archive location and the sign-off from the platform owner and compliance lead.

Which data and integrations to move, and by which export path

Intelligence in EclecticIQ reaches MISP through a small set of export paths, and each one carries different fields. Map every data type and every downstream consumer to a path before you export, and confirm what your EclecticIQ version can produce.

Indicators as STIX or CSV

Export indicators from EclecticIQ as STIX or CSV, then import them into MISP as events and attributes. STIX keeps more context such as observables, confidence and labels, while CSV is flat and loses relationships. Confirm which export formats and fields your EclecticIQ version offers, and compare counts per type in MISP against the source before you retire anything. Use STIX where context matters and CSV only for simple IOC lists.

Events and attributes in MISP

Group imported indicators into MISP events by campaign, report or source, because MISP attaches sharing rules and tags at the event level. Each observable becomes an attribute with a type, category and to_ids flag that controls whether detection tools consume it. Decide early which EclecticIQ reports become events, and which indicators are attributes inside them. Test a sample import first to confirm that types map cleanly.

Outgoing feeds rebuilt as MISP feeds

EclecticIQ outgoing feeds distribute intelligence to partners and tools. In MISP, rebuild them as synchronization connections with trusted instances, or as feeds that MISP pulls from a URL or file. Document each feed's consumer, format and refresh expectation before cutover, because a consumer that changes format will fail silently. Confirm the feed formats your partners need, since MISP's supported exports differ from EclecticIQ's.

Sharing groups and distribution levels

Recreate the sharing relationships that EclecticIQ enforces through its access and sharing model as MISP distribution levels and custom sharing groups. MISP applies these down to individual attributes, which lets you preserve restrictions that were applied per indicator. Map each partner community to one sharing group, and confirm that each group's members and sync permissions match the agreements in force. Do not assume the old model maps one to one.

SIEM and enrichment consumers

Point SIEM, SOAR and enrichment tools at MISP's REST API, using restSearch for queries and PyMISP for scripted pulls, or at NIDS exports for Suricata, Snort and Zeek. Each consumer that pulled from EclecticIQ needs its own endpoint, credentials and query logic tested against MISP data. Inventory every consumer before cutover, since an unlisted integration is the most common reason an alert pipeline breaks after migration.

Data without a direct MISP equivalent

Some EclecticIQ objects, such as custom entity types, analyst workflow states and certain relationship types, have no direct MISP counterpart. Decide whether to flatten them into attributes, carry them as tags or galaxies, or keep them in an archive export. Record each decision in a mapping document that analysts and auditors can review. Ask your EclecticIQ contact which custom objects your deployment uses before you design the mapping.

How to handle EclecticIQ data with no direct MISP equivalent

Every EclecticIQ object that lacks a clean MISP counterpart needs a written mapping decision before any bulk import starts. Custom STIX objects, relationships between entities and analyst notes do not map one to one onto MISP's model of events, attributes, objects, tags and galaxies. For each source type, decide whether it becomes a MISP attribute (for a single observable or value), a MISP object (for a grouped set of related attributes, such as a campaign or infrastructure cluster), a tag from a taxonomy, or a galaxy reference. Record the decision in a mapping table with the EclecticIQ source type, the MISP target, the fields that are kept, the fields that are dropped and who approved the choice. Analyst notes often fit best in an attribute comment or an event discussion field, but confirm the field limits and how they appear in exports with a test instance before relying on them.

Use MISP taxonomies and galaxies as the shareable vocabulary wherever EclecticIQ used local labels. The taxonomies and galaxies bundled with MISP cover threat actors, malware, ransomware, tools and MITRE ATT&CK, and they carry their own licenses, so check that your partners accept the terms before you tag shared events with them. Local labels that have no shared equivalent should stay as internal tags that are not distributed, or be dropped from outgoing sharing. Keep a list of every label you retire so analysts can still find older material.

Validate the mapping with sample records before migrating the full dataset. Pick a representative set that covers each custom object type, multi-hop relationships, notes with formatting and records with sharing restrictions, export them from EclecticIQ, import them into a MISP test instance and compare each field against the source. Confirm that relationships survive, that sharing levels are applied as intended and that exports to STIX or CSV from MISP carry what your partners need. Keep the source platform read-only as an archive for anything that cannot be carried over exactly, and state that archive scope in your migration record. Exact fidelity is a claim to prove through testing, not an assumption.

How the migration differs by team size and starting point

A team whose main job is exchanging indicators with partners, sector peers or an information sharing community usually finds MISP closest to its existing workflow, because MISP was built around distribution levels, sharing groups and synchronization between instances. The migration centers on rebuilding who receives what, not on the data model. Start by listing every outgoing feed, every partner account and every sharing agreement, then decide which of these map to MISP sharing groups and which need a conversation with the partner first.

Sharing groups: Recreate each outgoing feed as a sharing group with explicit members, and confirm the distribution level for each event before importing.
Synchronization: Plan synchronization links with each partner instance, and agree on the sync user and the filters that limit what leaves your instance.
Feed consumers: Identify partners who pull from EclecticIQ feeds directly, since their tooling will need repointing to MISP.
Install path: A single MISP instance for one community can follow the Ubuntu 24.04 installer that the MISP download page recommends for MISP 2.5, while Docker images or RPM packages suit teams that standardize on containers or Red Hat-family hosts.

Confirm with the team which partners must receive data during the overlap period and whether each agreement permits the new sharing channel.

What drives migration cost and duration, and how to keep each down

This table lists the main factors that raise or lower the effort of moving from EclecticIQ to MISP, with the reason each matters and how to reduce it. Read it before requesting a quote, since the same drivers should appear as line items in any written scope.

Driver	Why it changes cost or effort	How to keep it down
Volume of indicators and events	Larger stores take longer to export, transform, import and verify, and import jobs on MISP need capacity planning on the host.	Export in batches by date or collection, run a pilot on a subset, and confirm counts per batch against the EclecticIQ source.
Number of sharing partners and feeds	Each partner needs its sharing group, distribution level and sync connection rebuilt, and each one requires testing.	Inventory every partner and feed first, retire inactive ones, and group partners with identical sharing rules into shared groups.
Custom object complexity	EclecticIQ entities without a direct MISP equivalent need a mapping decision, custom attribute types or taxonomy tags, and each mapping must be reviewed by an analyst.	Build a written mapping table before any import, limit custom objects to those analysts actively use, and keep unmapped data in an archived export.
Number of downstream integrations	Every SIEM, SOAR, firewall or enrichment tool that reads from EclecticIQ must be repointed to MISP feeds, the REST API or PyMISP scripts, and tested.	List each consumer and its input format, such as STIX, CSV, Suricata or Zeek output, then repoint them one at a time.
Team familiarity with MISP and PyMISP	Teams new to MISP need time to learn events, attributes, tags, galaxies and the sync model, and scripts for bulk work need PyMISP skills.	Assign an owner with MISP experience, use the MISP project documentation and support channels, and plan training before cutover.
Length of the parallel run	Running EclecticIQ and MISP side by side keeps two sets of hosts, licenses and feed jobs active, which adds recurring cost until the last consumer moves.	Set exit criteria for each consumer, track which feeds still come from EclecticIQ, and end the parallel run as soon as the criteria are met.
One-time migration work	Export, mapping, import, validation, sharing group rebuild and integration changes are paid once, usually through a fixed-scope project or internal staff time.	Request an itemized written scope with deliverables, acceptance checks and who performs each task.
Recurring operating cost	MISP hosts, database and backups, patching, feed maintenance and any retained support contract continue after cutover and scale with use.	Ask the quote to separate hosting and staff effort per year from project fees, and confirm the MISP upgrade path, for example the 2.5 installer on Ubuntu 24.04.

What usually goes wrong in this migration

Most failed EclecticIQ to MISP moves fail in the same few places: sharing controls, data context, counts, partner connections and software versions. Each card below names one of these failure points and a check to run before cutover.

Sharing groups rebuilt with wrong distribution

EclecticIQ access rules rarely map one to one onto MISP. Teams often default imported events to organisation-only or community distribution, which silently stops sharing with partners, or they set everything to all communities, which exposes sensitive material. MISP supports distribution levels and custom sharing groups down to individual attributes, so each source access rule needs an explicit decision. Prevention: write a mapping table from every EclecticIQ group to a MISP sharing group and distribution level, then have the data owner sign off on it before any import runs.

Indicators imported without context

Importing bare indicators as flat attributes strips the analyst reasoning, confidence and relationships that made them useful. In MISP, unrelated attributes sharing common values or patterns can trigger the correlation engine across the whole instance, which floods analysts with matches that carry no meaning. Prevention: import with event grouping, tags, taxonomies and threat level set from the source, and disable or scope correlation for bulk loads until a sample batch has been reviewed.

Counts that do not match the source

A migration is not finished until the number of events, attributes and relationships in MISP matches what EclecticIQ reported for the same scope. Silent drops commonly come from rejected records, values that fail type validation, duplicate deduplication and exports that omit fields. Prevention: before cutover, reconcile counts per time window, per source group and per indicator type, and keep the reconciliation report as part of the migration record.

Partner feeds and sync not repointed

Partners, ISACs and internal tools often pull from EclecticIQ outgoing feeds or push into incoming feeds that were configured years ago. If those endpoints are not replaced with MISP sync, feed pulls or pushes, or TAXII-based collection in front of MISP, intelligence stops flowing without an obvious error. Prevention: inventory every consumer and producer before migration, then move them one at a time while the old feed stays live, confirming each partner receives the expected events.

MISP instances left on end-of-life 2.4

MISP 2.4 is end of life and receives security fixes only, and the project strongly advises against installing new 2.4 instances. A team that builds the target on an older release inherits a platform it will need to upgrade soon after cutover, during the period when partners are already connected. Prevention: deploy MISP 2.5 for new work, confirm the release level with the project before build, and plan the upgrade path, including the Ubuntu upgrade script if you run an existing 2.4 instance.

Questions buyers ask before moving from EclecticIQ to MISP

How long does a migration from EclecticIQ to MISP take?

The duration depends on how much intelligence you hold, how many sharing relationships and feeds you must rebuild, and how many downstream tools read from EclecticIQ today. No public benchmark for this migration was supplied, so ask any implementation partner, including DeployOpen, for a timeline built from your own counts. A useful first step is an inventory of events or entities, attributes or observables, sharing groups, incoming and outgoing feeds, and API consumers. Those numbers, combined with the number of data types that need manual mapping, drive most of the effort. Confirm the target MISP version with the MISP project before you plan, since the MISP download page recommends MISP 2.5 for new deployments.

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

A team with Linux administration and some MISP experience can often do the core work in-house, provided it has time and clear ownership. The MISP download page lists an installer for Ubuntu 24.04, plus Docker images, RPM packages, an Ansible role and a Puppet module, so the platform itself is not hard to stand up. The harder parts are mapping EclecticIQ objects to MISP events and attributes, rebuilding sharing groups and synchronization, and proving that counts match the source. Many organizations bring in outside help for those steps and keep the rest internal. Decide early which group owns each step and what must be verified before EclecticIQ is switched off.

What does the migration require from analysts and engineers?

Engineers carry the infrastructure, export and import work, while analysts carry the judgment about what the data means. Engineers need to set up the MISP instance, configure authentication, script or run exports from EclecticIQ, and check the imports. Analysts need to review how existing intelligence maps into MISP events, decide which context is essential, and confirm that tagging and taxonomies still reflect their practice. Plan for a period when both platforms run side by side so analysts can compare results. The MISP features page describes taxonomies, galaxies and warning lists, which analysts should review before deciding what to recreate.

What cost components should we budget for, and which are one-time?

The costs fall into a few groups. One-time costs include planning, export and import work, mapping EclecticIQ data to MISP, rebuilding feeds and sharing groups, and testing. Recurring costs include the servers or cloud capacity that run MISP, backups, patching and upgrades, staff time to operate the platform, and any support retainer. MISP itself is licensed under AGPL-3.0, so there is no license fee for the software, but the AGPL terms still apply to modifications. Also budget for the EclecticIQ subscription until the exit date in your contract. Ask any vendor for a quote that separates these groups and states what it assumes about data volume and integrations.

Can MISP fully replace EclecticIQ, or will we lose features?

MISP covers the core job of collecting, storing and sharing indicators and events, and it exports to many formats including STIX 1 and 2, CSV, OpenIOC and NIDS formats for Suricata, Snort and Zeek. It also synchronizes between instances with granular sharing controls. Some EclecticIQ capabilities may not map directly, such as specific custom object types, certain analyst workflows or particular dissemination patterns. Build a feature inventory that lists every EclecticIQ function your analysts and partners depend on, then mark each one as direct, adapted or unavailable in MISP. For teams that also need a richer STIX 2 graph model, the sibling comparison with OpenCTI may be relevant. Confirm each gap before you commit.

How do we cut over without losing sharing relationships?

The safest approach runs both platforms in parallel until each sharing relationship has been re-established and tested. Start by recreating sharing groups and synchronization links in a test environment, then confirm that a partner can receive and publish events in both directions. Only after counts and content match should you repoint downstream tools, feeds and API consumers to MISP. Keep the EclecticIQ export in a retained archive so you can recheck records later. Use the MISP support channels for questions about synchronization and sharing behavior before go-live, and agree a rollback plan for every step.

Does DeployOpen handle the whole migration, and how is it scoped?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, including MISP. Most engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. A typical written scope for this kind of migration would name the source inventory, export method, import and mapping rules, sharing group rebuild, parallel run period and handover documentation. DeployOpen does not publish a price list, so a quote follows from the written scope. Ongoing support and upgrades are available as retainers.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so MISP runs on your servers or in your cloud account. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory EclecticIQ entities, sightings, relationships, feeds and sharing partners to set the migration boundary.
Agree in writing which data types move as MISP events, which become attributes or objects, and which are retired.
Define the sharing groups, distribution levels and synchronization partners MISP must reproduce before cutover.

How we build

Deploy MISP 2.5 in your environment using the supported installation method your platform team selects.
Script the export from EclecticIQ, import into MISP as events, and reconcile object counts against the source.
Rebuild feeds, taxonomies, galaxies and authentication, and test each sharing path with the partners you name.

How we hand over

Deliver runbooks for installation, import jobs, sharing configuration, backups and upgrades in your own repository.
Document every field mapping decision, including EclecticIQ data with no direct MISP equivalent and how it was handled.
Walk your analysts and engineers through daily workflows, and record the parallel-run period and repointing steps.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Confirm the upgrade path with the MISP project and your own change control before each version change.
Ask any provider, including DeployOpen, to define support hours, response expectations and escalation in the written scope.

Migrate from EclecticIQ to MISP