Migrate from EclecticIQ to OpenCTI

Migrate from EclecticIQ to OpenCTI: what the move involves

The move is an export, import and rebuild exercise, run in parallel with EclecticIQ until downstream tools are repointed. Teams usually arrive here because a renewal date is close, a data residency rule has tightened, or the cost of depending on one vendor's export tooling has become a concern. The work itself is not a single data copy. Entities and their relationships are exported, loaded into OpenCTI, and then the things that made the old platform work for your analysts are rebuilt: incoming feeds become connectors, sharing outputs become TAXII collections or streams, and custom object and taxonomy decisions are mapped by hand. Security and CTI engineers from your own team do most of this, usually with an implementation partner for the connector and infrastructure work. Effort and risk depend far more on how much custom modeling and feed logic you have than on raw data volume.

The hardest parts are the ones that do not appear in a standard export. Custom objects, labels, taxonomies and the marking or segregation rules attached to them need an explicit mapping to OpenCTI's STIX 2 model before any bulk load, and each mapping should be written down and reviewed by the analysts who rely on it. Incoming feed logic is the second area to plan carefully: each EclecticIQ feed has filters, transformations and scheduling that must be re-expressed as OpenCTI connectors, then tested against a sample of known data. Ask your vendor and your partner to confirm exactly which relationship types and custom fields survive the export format you choose, and check object counts per type against the source after every load. Keep EclecticIQ running in read-only parallel until the counts match and each downstream consumer has been repointed and verified.

Which EclecticIQ capabilities map to OpenCTI, and which need rework

This table maps the main EclecticIQ capabilities to their closest OpenCTI equivalents and marks each as clean, needs rework or gap. Confirm each mapping against your EclecticIQ version and your OpenCTI edition before planning the cutover, because several controls sit in the Enterprise Edition under its own license.

Capability	OpenCTI equivalent	Status
STIX 2 entities and relationships	OpenCTI stores data on a STIX 2 based schema, so STIX 2.1 bundles from EclecticIQ can be imported with relationships intact	Clean
Custom objects and entity types	Custom entity types need schema definition in OpenCTI; map each EclecticIQ custom object to an existing STIX type or a documented extension	Needs rework
Outgoing feeds (STIX, CSV)	No one-to-one feed object; rebuild dissemination with OpenCTI streams, exports or a TAXII-based connector, then test each consumer	Needs rework
REST API bulk extraction	OpenCTI exposes a GraphQL API rather than a REST API, so export and import scripts must be rewritten against GraphQL queries	Needs rework
Incoming feeds	Re-create each feed as an OpenCTI import or external-import connector, configured and monitored individually	Needs rework
Enrichment and connectors	Connectors cover MISP, TheHive and MITRE ATT&CK; confirm that each commercial or custom enrichment source has a matching connector or needs a custom build	Needs rework
Analyst workflow and case handling	OpenCTI offers investigations and workflow features; confirm whether analyst review queues match your current process before retiring the EclecticIQ queue	Needs rework
Access segregation by organization	Organization-based segregation is an Enterprise Edition feature under the OpenCTI Enterprise Edition License	Gap in Community Edition
SSO and authentication	OpenID, LDAP, SAML, certificate and header authentication are documented, with SSO configuration in the Enterprise Edition	Gap in Community Edition
Audit logs and playbooks	Audit logs and playbooks are Enterprise Edition features; plan equivalent evidence collection if you stay on Community Edition	Gap in Community Edition

Which data and integrations move, and through which export path

Intelligence moves through three paths: outgoing feeds in STIX, the REST API for bulk extraction, and connectors that replace incoming feeds. Each path carries different fields, so confirm what your EclecticIQ tenant exposes before you plan the cutover.

Outgoing feeds as STIX

Outgoing feeds are the most direct export path for sharing content in STIX form. Ask your EclecticIQ administrator which feeds exist, which STIX version and output format each one uses, and whether relationships and observables are included or only top-level objects. Import a sample feed into a test OpenCTI instance and compare object counts against the source before you rely on it for the full history.

REST API for bulk extraction

The REST API is the route for full history, entities that feeds do not expose, and attributes that need to be read field by field. Confirm the API version, authentication method and rate limits with EclecticIQ, and write a script that pages through each entity type and logs the count per type. Store the raw JSON so you can re-map fields later without another full pull.

Importing STIX into OpenCTI

OpenCTI structures its data on STIX 2, so STIX 2 bundles from EclecticIQ are the cleanest input. Load them through a test import, check that identities, marking definitions and relationships resolve to existing objects, and record every bundle that fails validation. Duplicate objects can appear when the same indicator arrives from a feed and from the API, so decide on one source of truth per object type.

Re-creating incoming feeds as connectors

Each incoming feed in EclecticIQ needs a matching OpenCTI import connector, or a scheduled job that pushes content into the platform. OpenCTI runs connectors as separate processes that depend on RabbitMQ, so each one needs its own credentials, schedule and monitoring. Inventory every incoming feed, its source, its authentication and its update frequency, then confirm a connector exists or must be built for each one.

Mapping custom objects and taxonomies

EclecticIQ custom objects and internal taxonomies rarely have a one-to-one STIX counterpart. Map each one to a standard STIX object where the meaning matches, to a STIX extension where the field set is structured, or to labels where the value is a classification. Document every mapping in a shared table and review it with the analysts who use those fields, because a wrong mapping silently changes how content is searched and shared.

Sharing relationships and user accounts

Sharing groups, marking definitions and user accounts do not move by export alone. Recreate organizations and access groups in OpenCTI, map each EclecticIQ role to an OpenCTI capability, and confirm which identity provider will authenticate users through the OpenCTI authentication options. Keep a register of which partners receive which content, since that register is what you check against when downstream tools are repointed.

The migration sequence from inventory to decommission

This sequence moves EclecticIQ intelligence into OpenCTI in a controlled order, so each stage has a verified output before the next one begins. It keeps EclecticIQ running as the system of record until downstream consumers are confirmed on the new platform.

Inventory feeds, objects and integrations
List every incoming and outgoing feed, every custom object type, taxonomy, marking and tag in use, and every system that reads from or writes to EclecticIQ, including SIEM, SOAR, ticketing and partner TAXII consumers. Record the owner, format, cadence and purpose of each item. The output is an inventory register that names each connector and consumer that must be rebuilt, mapped or retired. The step is done when the platform owners sign off that nothing in production is missing from the register.
Export a representative sample from EclecticIQ
Pull a bounded set of entities through outgoing feeds or the REST API, covering each object type, relationship pattern and marking in the inventory. Keep the raw STIX bundles as an untouched copy so later mapping problems can be traced back to the source. The output is a sample archive with a manifest of object counts per type. The step is done when the team can state which fields survive the export and which ones need a mapping decision.
Run a pilot import into a sized OpenCTI test instance
Stand up a separate OpenCTI test instance sized to the documented deployment requirements, with Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage. Import the sample bundles and re-create the first incoming feed as a connector. Review the custom object and taxonomy mappings with the analysts who use the data daily. The output is a mapping specification and a list of defects found in the pilot. The step is done when the pilot runs without manual cleanup for the sample set.
Reconcile counts and fix mapping gaps
Compare object counts, relationship counts and markings between the EclecticIQ export and the OpenCTI import, type by type. Investigate every difference, whether it comes from deduplication, dropped fields or unsupported objects, and document the decision for each. The output is a count reconciliation report signed by the data owner. The step is done when every discrepancy has a recorded disposition and the mapping specification has been updated to match.
Run both platforms in parallel
Feed production sources to EclecticIQ and OpenCTI at the same time, with the new connectors writing to OpenCTI while the existing feeds keep serving consumers. Compare daily ingestion volumes and spot-check sample records on both sides. Confirm the OpenCTI LTS or regular release line and license arrangements before this stage starts, so the platform does not change under the team mid-run. The output is a parallel run log with discrepancy tickets. The step is done when the team agrees that OpenCTI matches EclecticIQ for the agreed period.
Repoint downstream consumers to OpenCTI
Work through the inventory register and change each consumer to read from OpenCTI, whether through its GraphQL API, a TAXII stream or a connector, one consumer at a time. Test each change against a known indicator before moving the next. Keep the old EclecticIQ path available as a fallback until the consumer's owner confirms it. The output is a list of repointed consumers with test evidence and the rollback path for each. The step is done when every register entry shows a verified new source.
Cut over and retain an export archive
Stop writes to EclecticIQ, make a final full export, and confirm its counts match the last reconciled state in OpenCTI. Confirm that partner sharing agreements and feed recipients have moved to the new distribution method. The output is a final export archive stored under the organization's retention policy and a signed cutover record. The step is done when no consumer depends on EclecticIQ and the archive has been verified by restoring a sample.
Decommission EclecticIQ and close the program
After the retention period set by your legal and records teams, shut down the EclecticIQ hosts, revoke API keys and service accounts, and remove stored credentials from connectors and vaults. Update the asset register, the backup scope and the access reviews to remove the retired system. The output is a decommission record listing each removed component and its disposal date. The step is done when the asset register no longer lists EclecticIQ as an active system.

How the OpenCTI platform fits together after the move

An OpenCTI deployment is several cooperating services, not one application, and the migration team needs to understand each piece before it plans the cutover. The platform provides the web interface and the GraphQL API that analysts, scripts and other tools call. Writes do not go straight to the database: Python workers consume messages from RabbitMQ and perform the asynchronous work, so a backlog in the queue shows up as delayed ingestion rather than as an error in the UI. Connectors run alongside the platform as separate processes. Their roles are import, enrichment, file extraction, export and stream consumption, and each one is configured with its own credentials and scope.

The platform depends on Elasticsearch or OpenSearch for indexing and search, Redis for caching and coordination, RabbitMQ for the message queue, and S3-compatible object storage such as MinIO for uploaded files. Each of these needs its own backup, monitoring and upgrade plan, and the supported version ranges are listed in the deployment overview. Check those versions against your hosting standard before you commit to hardware, because the search cluster and the object store usually drive most of the storage footprint. The documented sizing guidance gives minimum resources for the platform and the search nodes and recommends a ratio of platform nodes to workers. Treat those figures as a starting point and confirm them with a load test that uses your own export volume from EclecticIQ.

Connectors replace the incoming feed logic you ran in EclecticIQ, so the migration inventory should list every feed as a connector decision rather than as a single setting to copy over. An import connector pulls from a source, an enrichment connector adds context to existing objects, and an export connector pushes data to downstream consumers, including the tools you need to repoint. Each connector needs an owner, a schedule, a failure alert and a documented mapping to the STIX objects it writes. Confirm with your OpenCTI vendor and the connector catalog which of your current sources already have a maintained connector, and plan custom development or a retained feed for the rest.

What drives migration cost and duration, and how to reduce each driver

This table lists the factors that change the effort of moving from EclecticIQ to OpenCTI, why each one matters, and how to keep it contained. Use it to scope a fixed-scope quote, since the same platform move can vary widely depending on these inputs.

Driver	Why it changes effort	How to keep it down
Custom objects and taxonomies	Each EclecticIQ custom entity or tag set must be mapped to a STIX 2 object, a custom STIX extension or an OpenCTI label and vocabulary, and each mapping needs testing.	Inventory every custom type and taxonomy first, retire unused ones, and map to standard STIX objects where the meaning matches.
Incoming feeds to rebuild as connectors	Each incoming feed needs an OpenCTI import connector configured, tested and monitored, and parser differences can change the resulting objects.	Ask for a feed-by-feed list, drop feeds nobody reads, and prioritize the feeds that drive detections.
Downstream consumers to repoint	SIEM rules, SOAR playbooks, blocklists and partner feeds that read from EclecticIQ outgoing feeds or the REST API must be switched to OpenCTI endpoints or stream connectors.	Build a consumer register before work starts and repoint in stages while both platforms run in parallel.
Data volume and relationship density	Large indicator sets and dense relationship graphs take longer to export, import and verify, and relationships may need explicit re-creation.	Export by time window or type, verify counts against the source, and confirm which relationships the export carries.
Sharing and access model	Organization-based segregation, marking definitions and per-group visibility must be rebuilt, and mismatched access rules can expose data.	Document existing groups and markings, and agree the target model with data owners before import.
Enterprise Edition features required	Features such as audit logs, playbooks, organization-based segregation and SSO for OpenID, LDAP, SAML, certificate or header authentication sit in the Enterprise Edition under its own license.	Confirm which features you need against the OpenCTI Enterprise Edition documentation and separate them from the Community Edition scope.
Parallel running period	Keeping EclecticIQ and OpenCTI in sync adds operating load for analysts and engineers until every consumer is moved.	Set explicit cutover criteria per consumer and retire each source feed once its replacement is verified.

How the migration differs by team size and starting point

Teams running EclecticIQ Intelligence Center on premises on RHEL or Rocky Linux usually own the whole stack, including the database, the storage, the operating system patching and the network paths to feed sources. The migration therefore touches infrastructure as well as data. You will provision a new OpenCTI environment alongside the existing hosts, then move entities and rebuild feeds against the new endpoints. Plan the OpenCTI dependencies early, since the platform relies on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO.

Host provisioning: Size the new nodes against the OpenCTI deployment overview before the first import, not after.
Network paths: Recheck firewall rules for every incoming feed source, since each one becomes a connector that must reach its provider.
Patching windows: Keep both platforms patched on separate schedules so a fault in one does not stop intelligence flow.
Change control: Route host builds through your existing change process, because the new stack adds several new services.
Parallel running: Keep the EclecticIQ hosts online until downstream tools point to OpenCTI.

Confirm with your platform team which RHEL or Rocky Linux versions your standard build supports for each OpenCTI dependency.

What usually goes wrong and how to prevent it

Most failed EclecticIQ to OpenCTI migrations do not fail on the import itself. They fail in the gaps around it: counts that drift, relationships that vanish, feeds that stop quietly, and tools that keep reading the old platform. Each card below names one of these failures and the check that catches it before decommissioning.

Count mismatches after import

An import can finish without errors and still hold fewer indicators, observables or reports than the source. Duplicate handling, dropped object types and filters applied during export all shift totals. Before the parallel run, compare counts by entity type (indicators, observables, reports, threat actors, malware) between EclecticIQ and OpenCTI, and sample records from each batch. Record the differences and explain each one in writing so the team can tell expected deduplication from data loss.

Lost relationships and custom fields

STIX bundles carry relationships as separate objects, and custom object types or attributes from EclecticIQ may not map to a native OpenCTI type. A relationship whose source or target was skipped on import is silently lost. Inventory the custom objects and fields used in your EclecticIQ instance first, decide how each maps to OpenCTI, and test a sample report to confirm its links to actors, campaigns and indicators still resolve.

Incoming feeds silently stopping

Incoming feeds that worked in EclecticIQ do not move automatically. Each source must be rebuilt as an OpenCTI connector or a TAXII consumer, and a feed that stops without an error often looks like a quiet period. Assign an owner to every source, set an alert for the last successful ingest time, and confirm the first ingest from each partner before you turn off the old feed.

Downstream tools still pointed at the old platform

SIEMs, SOAR playbooks, firewall blocklists, scripts and partner sharing agreements often read from EclecticIQ through its API or outgoing feeds. These consumers keep working until the day EclecticIQ is switched off, then fail without warning. Build an inventory of every consumer with its endpoint, credential and owner, repoint each one to OpenCTI in a test environment, and track sign-off per consumer.

Version and LTS license key planning

OpenCTI release numbers follow a date-based scheme, and regular releases ship from daily to weekly. Teams that deploy a non-LTS build for production may face upgrades at short notice. LTS releases are published as container images but need an LTS license key, and after stabilization they receive only critical bug and security fixes. Decide early between a regular release and an LTS line, confirm the license terms with Filigran, and schedule upgrades in your change calendar.

Decommissioning before the parallel run proves out

Teams often shut down EclecticIQ once the import finishes, before analysts trust the new data or every consumer has moved. Keep the source read-only and running for a defined overlap period, and set exit criteria in advance: matched counts, verified relationships, every feed live for a full cycle, and all consumers signed off. Export a final archive from EclecticIQ before the contract ends, and keep it under the same retention rules as the live data.

Migration questions teams ask before bringing in outside help

What drives the cost of moving from EclecticIQ to OpenCTI?

The cost depends mostly on how much of your EclecticIQ setup has to be rebuilt, not on the volume of data alone. The main components are the platform and its dependencies (Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage), the time to re-create incoming feeds as connectors, the mapping work for custom objects and taxonomies, and the parallel run while downstream tools are repointed. Hosting is a recurring cost, while mapping and connector work is largely one-time. Ask any provider for a quote that lists each component separately, including who pays for infrastructure, who writes the connectors and who validates the results.

How long does an EclecticIQ to OpenCTI migration take?

Duration follows scope. A deployment with a small number of feeds, few custom object types and a single downstream integration takes far less time than one with many incoming feeds, bespoke taxonomies and several consumers such as SIEM, SOAR or ticketing tools. Each connector, mapping rule and downstream repointing adds effort, and the parallel run adds a fixed period during which both platforms operate. Confirm a timeline against a written inventory of your feeds, objects and integrations rather than a generic estimate.

What does the migration need from our internal team?

The work needs people who know your intelligence process as well as the tools. Expect to name an owner for the data model and taxonomies, an analyst who can confirm which indicators and relationships still matter, and an engineer who can provide access to the EclecticIQ REST API and outgoing feeds. Someone must also own the downstream tools that consume intelligence, because repointing them requires change windows and testing. Your team will also decide on retention and what happens to historical data.

Can our team migrate from EclecticIQ to OpenCTI without outside help?

A team with STIX 2 experience, Linux and container operations skills, and time to test can do the migration in-house. The areas most often underestimated are the data mapping, verifying relationships after import and rebuilding connectors that consume external feeds. Teams that lack a Python or GraphQL background, or that must meet a compliance deadline, often bring in outside help for the implementation and validation steps while keeping analysis in-house. Decide based on your internal skills and the number of integrations, not on the platform alone.

How do we verify that counts match after the export and import?

Compare object counts by type between EclecticIQ and OpenCTI before and after each import batch, and keep the export files as evidence. Check relationships separately, because a correct entity count can hide dropped links between indicators, malware, threat actors and reports. Sample records by hand, including those with custom fields and taxonomy tags, and confirm that marking definitions and author identities arrived intact. Record each reconciliation result so that a later audit or dispute has a clear trail.

Which OpenCTI edition and license do we need, and what do LTS keys cover?

OpenCTI Community Edition is licensed under Apache 2.0 and is developed by Filigran. OpenCTI Enterprise Edition uses a separate proprietary license and adds features such as audit logs, playbooks, organization-based segregation and SSO options. Confirm with Filigran which edition your requirements need before you design the architecture. LTS releases are distributed as container images but require a specific LTS license key to use, and after a one-month stabilization period they receive only critical bug and security fixes. Check the current terms in the OpenCTI product life cycle documentation before you commit.

What does a fixed-scope quote from DeployOpen cover?

A fixed-scope engagement covers the scope, deliverables and timeline agreed in writing before work starts. For this migration, the written scope should list the sources to export, the entity types and custom objects to map, the connectors to re-create, the downstream tools to repoint, the parallel run period, the verification method and the handover documentation. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Ongoing support and upgrades are available as separate retainers, and the quote follows from the written scope.

Official sources to check before you plan the move

Before you scope a move from EclecticIQ to OpenCTI, read the primary documentation for the OpenCTI release you intend to run. Start with the OpenCTI GitHub repository, which shows the STIX 2 based data model, the GraphQL API and the connector ecosystem that will replace your incoming feeds. Then read the OpenCTI deployment overview to confirm the components your team will operate: the platform, Python workers consuming RabbitMQ messages, connectors, and the Elasticsearch or OpenSearch, Redis and S3-compatible storage dependencies with their minimum versions. Those minimums and the sizing guidance drive the host plan, so treat them as the baseline for your architecture review rather than a finished design. Next, read the OpenCTI product life cycle documentation before you pick a version. Regular releases ship on a date-based numbering scheme, while LTS releases arrive about every six months, are supported for one year, and require a specific LTS license key. Decide early whether you will run a regular or LTS line, because that choice sets your patch cadence and upgrade calendar. The OpenCTI Enterprise Edition documentation matters if your requirements include audit logs, organization-based segregation, playbooks or SSO options, since those features sit under a different license from the Community Edition. Finally, confirm the export and API behavior in your own EclecticIQ environment. Check which outgoing feed formats and REST API endpoints your version offers, the EclecticIQ version and deployment mode you run on premises or in the cloud, and whether custom objects and relationships appear in the export. Document these answers with your EclecticIQ administrator and the vendor, because the vendor's documentation for your release is the authority on what you can extract. Record the confirmed items in your migration plan so the scope agreed with any implementation partner reflects what your environment actually supports.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For this migration, we start with a written scope that maps your EclecticIQ exports, feeds and downstream tools to OpenCTI, then build and test each step in your environment before cutover.

How we scope

Inventory EclecticIQ entities, relationships, custom objects, taxonomies and incoming and outgoing feeds before any data moves
Agree in writing which export paths, STIX mappings and connector replacements are in the migration
Define the parallel run period and the list of downstream tools that must be repointed to OpenCTI
Confirm deployment target, whether on-premises, private cloud or air-gapped, and the OpenCTI dependencies to be hosted

How we build

Deploy OpenCTI with its platform, workers, connectors, Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage in your environment
Script STIX import runs and reconcile object counts and relationships against the EclecticIQ source at each stage
Re-create incoming feeds as OpenCTI connectors and map custom objects and taxonomies to the agreed STIX model
Test authentication and access controls, including SSO options, before any analyst or partner account is moved

How we hand over

Deliver written documentation of the data mapping, connector configuration, sizing decisions and cutover runbook
Provide a reconciliation report comparing exported and imported records, with gaps and known losses listed
Run knowledge transfer sessions with your platform, security and analyst teams on daily operation of OpenCTI
Hand over backup and upgrade procedures so your team can run the platform after the engagement closes

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately
Plan OpenCTI upgrades around its release and LTS cycle, with checks on connectors before each change
Keep the parallel run monitored until the agreed repointing of downstream tools is confirmed
Confirm with your team which support level and response terms apply before the written scope is signed

Migrate from EclecticIQ to OpenCTI