How to export your data from EclecticIQ

How to export your data from EclecticIQ before the contract ends

If a renewal, licensing change or data residency requirement means intelligence has to leave EclecticIQ, the documented routes are outgoing feeds, which can publish entities in STIX or CSV, and the REST API, which is the path for bulk extraction. Whether either route carries every object type, relationship and custom field your team depends on is a question for EclecticIQ, not for DeployOpen. DeployOpen does not hold EclecticIQ's export specifications, so confirm with your account team and the EclecticIQ documentation for your installed version which formats, record limits, pagination behavior and relationship coverage apply before you plan any extraction.

Start by inventorying what you actually need to keep. Separate indicators and observables, reports and campaigns, threat actors and malware entities, the relationships between them, sightings, source attribution, markings and any custom objects or taxonomies your analysts built. For each category, ask the vendor whether the STIX output preserves the relationship records and custom properties, and whether the API returns them in the same call or requires separate requests. Run a test extraction of a representative sample, then compare object counts per type against the source console, so a gap is found while EclecticIQ is still licensed and not after the contract ends. Keep the exported files, the query parameters used and the counts as evidence for later migration work.

Plan the extraction window early, because a bulk pull through the API on a large repository can take longer than the team expects and may be subject to rate limits set by your deployment. Ask for written confirmation of the retention and access terms that apply after termination, including how long your tenant remains readable and whether a final full export can be requested. Where the data is held in an on-premises deployment on RHEL or Rocky Linux, also confirm backup and database export options with your administrators, since the application-level export may not capture everything stored at the database layer. Those answers determine whether you can finish the export on your own schedule.

Which EclecticIQ data types can you export, and in what format

This table lists each EclecticIQ data type, the documented export route for it, the formats it may arrive in, and the limits to confirm before planning a bulk extraction. Treat the limits column as a question list for EclecticIQ, since page sizes, rate limits and result caps depend on your deployment. The main takeaway is that outgoing feeds and the REST API are the routes to test, and relationships and custom objects need a check against the source.

Data type	Export method	Format	Limits to confirm with EclecticIQ
Indicators and observables	Outgoing feed or REST API	STIX or CSV	Ask for feed size limits, page size and whether observable types keep their original labels.
Entities	Outgoing feed or REST API	STIX	Confirm which entity types map to STIX objects and which fall back to generic fields.
Reports	Outgoing feed or REST API	STIX	Ask about attachment handling and the maximum result set for large report sets.
Relationships	REST API, confirm feed support	STIX	Confirm whether links between objects appear as STIX relationship objects in feed output.
Sightings	Outgoing feed or REST API	STIX or CSV	Confirm sightings are included at all and that source and timestamp fields are preserved.
Custom objects	REST API	STIX or CSV with custom properties	Confirm custom object types export as typed objects and are not flattened into plain fields.
Taxonomies and tags	Outgoing feed or REST API	STIX labels or CSV columns	Confirm tag names and taxonomy values survive export unchanged, with no renaming.
Sources and feeds	REST API	JSON or CSV, confirm format	Ask for rate limits and confirm source names and feed origins appear on exported records.
Users and sharing groups	REST API, confirm	Confirm format	Confirm whether user accounts and audit history export at all; intelligence exports usually omit both.

Where exported STIX and CSV land in MISP and OpenCTI

OpenCTI is built on a STIX 2 based knowledge schema, so STIX 2 bundles are the natural export format for this destination. Objects such as threat actors, malware, indicators, observables, reports and the relationships between them can be carried in one bundle, and the platform exposes a GraphQL API that your import scripts or connectors can use to verify what landed. Plan the import as a set of batches rather than one large file, and confirm object counts per type after each batch.

Use STIX 2 bundles as the primary format: Confirm with your EclecticIQ administrator which STIX version and object types the export produces, since OpenCTI expects STIX 2 content.
Map custom objects before import: EclecticIQ entity types without a STIX 2 equivalent need a documented mapping, such as a STIX custom object, a label or an external reference, decided before the first import.
Check relationships explicitly: Verify that relationship objects survive the bundle, because a bundle can contain entities and still lose the links between them if the export is filtered.
Use connectors where they fit: OpenCTI has connectors for MISP and MITRE ATT&CK, which can bring in data from those sources, but confirm each connector's behavior in your version before relying on it for a migrated dataset.
Compare counts through the API: Query the GraphQL API per object type and compare the results against counts from the EclecticIQ export, keeping the comparison in your migration log.

Before sign-off, sample a set of high-value reports and actors and confirm their relationships and labels in the OpenCTI interface.

What does not export cleanly, and the workaround for each

Standard STIX exports carry core entities and many relationships, but several EclecticIQ constructs depend on the platform itself. The cards below cover what is most likely to be lost or changed in transit, the workaround for each, and what to confirm with EclecticIQ before you assume an item is gone.

Custom object types and fields

Custom object types and their field definitions live in the EclecticIQ schema, not in each record, so a bulk export may return values without the names, types or allowed values that give them meaning. Export the object schema alongside the data and keep it in version control. When the target is MISP, flatten custom fields into MISP attributes with a documented type mapping, or into tags where the value is a classification. Ask EclecticIQ support whether the export includes custom type definitions before assuming they are lost.

Relationships and link direction

Relationships are often the most valuable part of an analyst's graph, yet some exports keep the linked objects without the relationship type or the direction of each link. Test with a sample of known relationships, such as an indicator that indicates a malware family, and check that the source and target are not reversed. Record the mapping from EclecticIQ relationship labels to STIX relationship types before the bulk run, and confirm with EclecticIQ how its relationship export represents direction.

Analyst notes and comments

Analyst notes, comments and review history are usually attached to a record as separate items, so they may not appear in a standard entity export. Decide which notes matter for the new platform, such as a judgment on attribution or a handling caveat, and copy those into the description or a note object in OpenCTI, or into the event comment field in MISP. Ask EclecticIQ whether comments can be pulled through the REST API as their own records.

Sharing and access rules

EclecticIQ access controls are based on how the platform groups users and data, and they do not map one to one to MISP distribution levels or sharing groups. Expect to redesign this part rather than copy it. Document each existing access rule, decide which audience each dataset should reach in MISP or OpenCTI, and test with a non-privileged account on the target. Confirm with EclecticIQ exactly which rules an export can express before planning the redesign.

Feed configurations and credentials

Incoming and outgoing feed definitions, their schedules and the credentials for third-party sources are configuration, not intelligence, so they do not move with the data. Inventory each feed, its source, its format and its owner, then re-create each incoming feed as a connector on the new platform. Rotate any credentials you re-enter. Keep the EclecticIQ outgoing feeds running until downstream consumers are repointed, since partners often poll them directly.

Audit history

Audit logs record who viewed, changed or exported what, and they are rarely part of a data export. If your compliance or incident review needs that history, keep the EclecticIQ instance read-only for an archive period, and export the logs in whatever form the platform provides. Ask EclecticIQ support whether audit records are available through the API and how long they are retained, so the archive plan matches your retention policy.

The export sequence, from inventory to signed-off counts

This sequence moves intelligence out of EclecticIQ in a controlled order, so each data type is inventoried, tested, extracted, stored with checksums and reconciled against the source before the contract ends. The output is a verified, organization-held archive with a documented count reconciliation that a receiving platform can be checked against.

Inventory data types and sharing groups
Start by listing every entity type in use, such as indicators, observables, reports, threat actors, campaigns, malware and custom objects, along with the sharing groups, sources and marking levels that govern who can see each one. The platform team and the intelligence leads should own this list together, since analysts often know which custom objects matter downstream. Record an approximate total per type from the EclecticIQ console or existing reports. The step is done when the inventory is signed off by both teams and every type has a named owner and an expected count.
Confirm documented export paths and limits
Before writing any script, confirm with EclecticIQ which export routes your licence and deployment support: outgoing feeds in STIX or CSV, the REST API for bulk extraction, and any page size, rate or record limits that apply. Ask in writing whether relationships, custom objects, taxonomies and sharing markings are included in each route, and what the export looks like when a record cannot be represented in STIX. Request the API documentation for your version. The step is done when the answers are stored with the project records and any gap is logged as a known risk.
Export a small test set end to end
Select a sample that spans every data type, including a few records with relationships, custom objects and restricted sharing groups. Export it through the chosen route, then load it into a scratch instance of the target platform, such as MISP or OpenCTI, to confirm the file parses. Compare the counts per type between the source sample and the export, and sample at least a handful of records by hand to check field values, timestamps and relationship links. The step is done when the test set round-trips with no unexplained losses and each mismatch has a documented cause.
Run the full bulk extraction
Run the full extraction through the REST API or the outgoing feeds in the formats agreed in the first two steps, working through each data type in turn rather than one large job. Keep the run logs, request parameters and any pagination cursors, because they are needed to repeat or resume a failed pull. Record the number of records returned per type at the end of each run. The step is done when every type has a complete output file and a run log that matches the expected inventory, with any gaps explained.
Store output with checksums in controlled storage
Move the exports into storage that the organization controls, such as an encrypted volume or object store in its own environment, and do not leave the only copy in a vendor-hosted location. Generate a cryptographic checksum for every file, record file sizes and record counts in a manifest, and keep the run logs beside them. Restrict access to named roles and log who reads the archive. The step is done when a second person can recompute the checksums and get matching values from the stored copies.
Freeze the source for a final delta extraction
Close to the cut-off date, ask the intelligence team to stop or slow new ingestion and sharing changes, then run a delta extraction for records created or modified since the full run. Confirm with EclecticIQ how modification timestamps are used by the export route so that edits to existing records are captured, not only new ones. Merge the delta into the archive with its own checksums and manifest entry. The step is done when the delta covers the full gap between the two runs and the frozen source counts match the sum of the full and delta totals.
Sign off counts and reconcile against the source
Compare the final counts per type in the archive manifest with the source counts taken at the freeze point, and check relationship counts and a random sample of custom object records against the source. Investigate every difference and document whether it is a true loss, a format limitation or a record that was excluded by sharing rules. The platform owner, the intelligence lead and the compliance contact should each sign the reconciliation report before the EclecticIQ subscription is closed. The step is done when the signed report shows agreed counts, a list of accepted exceptions and the checksum manifest.

Checking exported counts against the source before you rely on them

Before you rely on an export, compare counts by data type between EclecticIQ and the exported output: indicators, observables, entities, relationships, reports, and any custom object types your deployment uses. Take each count at the same point in time. Export jobs run against a live platform, so analysts who ingest, merge or retire records during the job will shift the numbers. If you cannot freeze ingestion, record the timestamp of each count and the list of changes that happened in between, so the difference is a documented delta rather than an unexplained gap. Confirm with your EclecticIQ administrator how the platform's API and outgoing feeds report totals, and whether a count query returns the same scope as the export job you ran.

Counts can match and still hide losses, so sample individual records. Pick a set of entities that span the data types you care about, including ones with many relationships and ones that carry custom fields. For each sampled record, check that the exported copy contains its identifiers, timestamps, source attributions, markings and every linked object. Relationship checks matter most: confirm that both ends of each link exist in the output and that the relationship type survived. Where a custom field has no equivalent in your target format, note which field was dropped and where it is recorded, because that loss belongs in your migration record, not in a footnote.

When counts differ, reconcile the cause before accepting the result. Common explanations include deduplication during import or export, sharing or access filters that hide records from the account running the export, and records that the serializer rejected because of malformed content or unsupported types. Each explanation should have its own line in the reconciliation, with the number of affected records and an example identifier. Keep these checks as a dated record with the queries, settings and reviewer names, so that internal audit or a compliance reviewer can see how you verified the export. Repeat the comparison after any change to the export configuration.

What to plan before the renewal or termination date

Export work for EclecticIQ succeeds or fails on decisions made before the final extraction starts. The cards below cover the contract, timing, data model, retention, downstream tools and hosting constraints that shape what you can take out and how you verify it.

Confirm export rights in writing

Check the subscription agreement for what you are allowed to extract, in which formats, and whether bulk extraction through the REST API is included. Ask the vendor to confirm these terms in writing, including any limits on volume, rate or the export of enrichment data from third-party sources. Verbal assurances from account teams do not bind the license, so record the answers before you plan the migration.

Agree the final extraction window

Set the cut-off point for the final extraction and agree with the vendor when the instance moves to a read-only period. Intelligence still arriving through incoming feeds during extraction will be missed unless you plan a delta run. Ask how the read-only mode affects analyst logins, scheduled jobs and outgoing feed generation, and whether the vendor can hold the instance in that state while you verify counts.

Request the data model and custom objects

Ask for the documented data model, the definitions of any custom object types, and the mapping of entity relationships used in your deployment. Standard STIX objects export predictably, but custom fields, proprietary relationship types and analyst-defined taxonomies may not. Without these definitions, the target platform receives records it cannot interpret, so request them early enough to build the mapping before extraction.

Plan retention for exported copies

Decide how long exported files, staging databases and backups will be kept, who can access them, and when they will be deleted. Intelligence exports often contain sensitive indicators, victim information and partner-shared material with handling restrictions. Confirm that the sharing terms from your partners allow the copies you intend to hold, and record the deletion step in the decommissioning checklist.

Reserve time to repoint downstream tools

List every feed, SIEM rule, SOAR playbook and connector that reads from EclecticIQ, and assign an owner to each. Outgoing feeds, TAXII consumers and automation that pulls indicators will all need new endpoints and credentials. Schedule the repointing so that both platforms run in parallel until each consumer has been tested, rather than switching all consumers on the same day.

Check hosting and data handling constraints

Confirm where the current instance runs, whether on premises on RHEL or Rocky Linux or in the vendor's cloud service, and what the vendor does with data during and after extraction. On-premises deployments let you control the export host and network path directly. Cloud deployments depend on the vendor's data handling terms, so ask for the deletion process for your tenant and any retained backups, in writing.

Questions teams ask before exporting EclecticIQ data

What does it cost to export data from EclecticIQ?

Most of the cost is staff effort, not software, because the export itself is a set of queries, transformations and checks. The effort rises with data volume, the number of custom objects that need a target equivalent, the number of sharing groups whose access rules must be recreated, and the number of downstream integrations that consume feeds or API output. Your EclecticIQ subscription terms govern whether bulk API extraction carries additional charges, so confirm that with your account team before planning. Ask any outside provider for a fixed-scope quote built from a written inventory of those four drivers, with deliverables for each export stream and each verification step listed separately.

How long does an EclecticIQ data export take?

The schedule depends on how much of the data model is standard and how much is custom, how many systems read from the export, and how long verification takes compared with extraction. Extraction from the REST API is usually the shorter part, while mapping custom objects, rebuilding sharing groups and reconciling counts against the source take longer. Plan for a parallel period in which EclecticIQ and the target both run, because downstream tools need repointing before the contract ends. Ask for a timeline tied to milestones rather than a single end date, and check that the contract end date leaves room for at least one full verification cycle.

Which people does an EclecticIQ export need on the internal team?

Three roles cover most exports: an EclecticIQ administrator who can grant API access, confirm outgoing feed configuration and explain sharing groups, an analyst who knows how intelligence is modeled in practice, and an engineer who owns the target platform. The administrator is the source of truth for configuration, the analyst decides which relationships and custom fields matter, and the engineer builds the import path and monitors it. In small teams one person may hold two roles, but the analyst role should not be skipped because data loss is most likely in fields that only analysts recognize as important.

Can we export EclecticIQ data without an outside partner?

Yes, a team with the three roles above can export its own data, especially if the intelligence volume is modest and the data model is mostly standard. Teams usually manage the bulk extraction and the first import themselves. The steps that are hardest to do alone are mapping custom objects and taxonomies to the target schema, recreating access controls so that sharing does not widen, and proving that relationships survived the move. These steps need someone who has done a schema mapping before and who can document decisions for auditors. If internal staff lack that experience, a fixed-scope engagement can cover only those steps while the team keeps ownership of the rest.

Do we need a consultant to map and verify exported data?

A consultant is not required, but a second pair of hands is useful for mapping and verification because those tasks are easy to get subtly wrong. Verification should compare object counts by type, sample relationships end to end, and confirm that distribution levels and sharing restrictions were carried over, not assumed. DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms in your own infrastructure, and it can scope verification as part of a fixed-scope engagement with written deliverables. It does not issue audit reports or certifications, so if you need evidence for an assessment, ask your independent auditor what records they expect from the migration.

How do we check that an export matches the EclecticIQ source?

Reconcile before you decommission anything. Compare counts per object type between EclecticIQ and the target, then compare a random sample of entities field by field, including labels, timestamps, confidence values and source attribution. Check relationships separately, because a relationship can import without its endpoints. Record each check, the person who ran it and the result, so the reconciliation can be shown later. Repeat the checks after each incremental export, since data that changed in the source during the cutover period will otherwise be missing from the target.

How DeployOpen scopes, delivers and supports an EclecticIQ data export

DeployOpen treats the export as a fixed-scope piece of work with written deliverables, agreed before any data leaves EclecticIQ. The work runs inside your own infrastructure, so extracted intelligence, staging stores and reconciliation reports stay under your control from start to finish.

How we scope

Inventory the object types, relationships, custom objects and feeds that must leave EclecticIQ before the contract ends.
Confirm which export routes apply to your EclecticIQ version: outgoing feeds, the REST API or both, with the formats each route produces.
Agree in writing the record counts, reconciliation method, retention rules and the target platform, whether OpenCTI, MISP or an archive.

How we build

Build extraction scripts against the EclecticIQ REST API with paging, logging and resumable checkpoints for large bulk pulls.
Map exported STIX objects and CSV fields into a documented target schema, flagging anything without a direct equivalent for your review.
Run test extractions on a subset and compare counts per object type against the source before running the full export.

How we hand over

Deliver the export scripts, configuration and run logs as code, with a runbook that a successor team can follow.
Provide a reconciliation report listing counts by entity type, relationship and custom object, with any differences explained.
Document the data mapping, known gaps and the list of items to confirm with EclecticIQ before the subscription ends.

How we support

Keep both systems available during the overlap so downstream consumers can be repointed without losing intelligence.
Offer ongoing support, upgrades and continuous testing as a retainer if the export or the target platform needs follow-up work.
Re-run reconciliation after any late-stage change in EclecticIQ content, such as new feed items or updated indicators.

How to export your data from EclecticIQ