OpenCTI migration services

What an OpenCTI migration involves

An OpenCTI migration is either a data migration, where existing threat intelligence from MISP, spreadsheets or another platform is brought into OpenCTI and mapped to the STIX2 knowledge schema, or a platform migration, where an existing OpenCTI install is moved onto new infrastructure or a newer release line. Many projects involve both, because the move is the point at which legacy data is cleaned up and loaded into a store that will be shared. The two types need different skills and carry different risks, so decide early which one you are doing.

Migrations are usually triggered by one of three events: a tool being retired and its intelligence needing a new home, a shared intelligence store outgrowing the host it runs on, or an install that is no longer supported on its release line. OpenCTI publishes regular and LTS release lines with set support windows, so confirm the current support status of your version in the product life cycle documentation before you plan the move. An unsupported install is a reason to move soon, not a reason to skip planning.

In-house or partner. A team with a small, clean dataset and an experienced platform owner can often run the migration itself. Mixed sources, large volumes, decisions about how MISP events, indicators and spreadsheet fields map to STIX2 objects, and the cutover window for a shared store usually justify outside help. Ask any partner to show how they will test mappings on a sample, reconcile counts after import and roll back if the cutover fails. Implementation planning, upgrades, SSO, sizing and connectors are covered on their own pages; this one stays on the data and the move.

What the work includes

A migration moves data, meaning, access rules and operating procedures together. Each work package below ends with a document or artifact your team keeps, so the migration can be reviewed and repeated after the project closes.

Source inventory

We catalog every source holding threat intelligence: MISP instances, spreadsheets, existing platforms and any older OpenCTI install. For each source we record object types, custom fields, marking or sharing rules, owners and known data quality issues. The inventory deliverable is a source register that sets the scope of every later package, so gaps found here do not surface during cutover.

Target data model and STIX2 mapping specification

We define how each source object maps to OpenCTI's STIX2-based knowledge schema, including entity types, relationships, identifiers and custom attributes. Decisions on what becomes an observable, an indicator or a note are written down with rationale. The client keeps the mapping specification, which becomes the reference for scripts, connector settings and future imports.

Extraction and transformation scripts or connector configuration

We build the code or connector settings that read source data and convert it to the agreed mapping, using OpenCTI's import connectors where they fit and custom scripts where they do not. Each transformation is versioned and runs repeatably against the same input. The client receives the migration scripts or configuration files, with a README stating prerequisites and how to re-run a load.

Staged loads into a non-production instance

We load data in stages into a non-production OpenCTI that matches the target platform, dependencies and worker layout. Early loads usually expose mapping gaps, duplicate entities and performance limits in search and queues, so each stage is reviewed before the next one begins. The client keeps a load log per stage recording what ran, when, and what failed.

Reconciliation of counts and relationships

We compare object counts, relationship counts and sample records between each source and the staged target, and explain every difference. Deduplication, dropped fields and relationships that could not be resolved are listed with their causes. The client receives a reconciliation report that shows the evidence behind a cutover decision, not only a pass or fail result.

Access and marking mapping for migrated data

We map source sharing rules, groups and classification labels to OpenCTI markings, organizations and user roles so migrated intelligence keeps its original restrictions. Errors here can widen access to sensitive reporting, so each mapping is tested with named accounts before cutover. The client keeps the access mapping table and the test results, and the mapping should be checked against your own data handling policy.

Cutover and rollback runbook

We write the step-by-step procedure for the production load, freezing writes in the source, validating the target and switching analysts and connectors over. The runbook sets out the rollback path, including who decides to roll back and how the source stays intact until acceptance. The client keeps the runbook, which should be rehearsed on the non-production instance before the production date is fixed.

Handover

We transfer ownership of the mapping specification, scripts, reconciliation report, access mapping and runbook to your team, and walk through how to re-run a load or onboard a new source. Open items, such as connectors to retire or data to clean up later, are recorded with owners. Confirm with your team which of these artifacts must live in your own repository and document store before the project starts.

What drives cost and duration

The table lists the factors that most change the effort of an OpenCTI migration, why each one matters, and how to keep it under control.

Driver	Why it matters	How to keep it down
Number and type of source systems	Each MISP instance, spreadsheet, other threat intelligence platform or older OpenCTI has its own export format, identifiers and quirks, and each needs its own extraction and validation.	Inventory every source first, retire sources with no active use, and migrate the largest or most-used sources before smaller ones.
Depth of STIX 2 mapping	OpenCTI's knowledge schema is based on STIX 2, so source fields must be mapped to existing object types and relationships. Fields with no clean match need design decisions and testing.	Map only the fields analysts actually use, agree a mapping document with analysts before building, and treat unmapped fields as an explicit keep or drop decision.
Data quality and deduplication	Duplicate indicators, inconsistent naming and stale confidence values from older sources multiply during import and degrade search and correlation in the new platform.	Profile source data before import, define deduplication rules and matching keys, and clean the highest-volume records first rather than the full archive.
Relationships and observables that must be preserved	Links between indicators, malware, campaigns and observables carry much of the analytical value. Rebuilding them by hand is slow and error-prone.	Limit the preserved relationship set to those analysts query, and script relationship reconstruction where source identifiers allow it.
Number of object types and custom attributes	Custom object types or attributes beyond the standard schema need extra mapping, validation and sometimes platform configuration before data can load.	Reuse standard object types where possible and approve each custom attribute against a documented business need before the build starts.
Volume of history to keep versus archive	The amount of historical data loaded determines import time, index size and validation effort. Full history rarely adds equal value for every analyst.	Agree a retention window with intelligence owners, load recent active data into OpenCTI, and archive older data in a read-only store with a search path.
Source of truth during the transition	If analysts keep writing to the old system while the new one is loaded, changes must be synchronized or re-imported, which adds rounds of work.	Set a cutover date, freeze writes on the legacy source for the final load, and record which system is authoritative for each dataset.
Number of environments and validation rounds	Each test environment and each trial import adds build, reconciliation and sign-off effort. Several rounds are normal when mappings change.	Plan a fixed number of validation rounds with exit criteria, and use one representative dataset for early rounds to limit rework.
Infrastructure change	Moving an older install to current infrastructure can mean new hosts, Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, each needing sizing, hardening and monitoring. Confirm current minimums with the OpenCTI deployment overview.	Reuse the target platform design from the implementation plan, size from the documented minimums and expected data growth, and avoid changing infrastructure and data model in the same step where possible.
Edition and licence needs	Features such as SSO, audit logs and organization-based data segregation require the Enterprise Edition, and LTS releases need a specific licence key. Confirm licence scope with Filigran before the design is fixed.	List required enterprise features during scoping, confirm licence type and term in writing, and check whether the migration target needs an LTS or continuous release.

How the project runs

The project moves intelligence through seven checkpoints, each closing with an artifact you can review before the next phase begins.

Inventory sources and collect the current state
We list every source that holds threat intelligence, such as MISP instances, spreadsheets, feeds and any existing OpenCTI install, and record object counts, owners, sharing rules and known data quality problems. You receive a source inventory with each source's owner, format and access method, and you confirm it is complete before design starts.
Design the target and record mapping decisions
We agree the target OpenCTI architecture, including platform, workers, search, queue and storage placement, and the decisions that shape the data: marking and organization handling, how indicators and observables are represented, and which STIX2 objects each source type maps to. You receive a target design and a decision log that names each choice and the reason for it.
Write the mapping specification and extract test samples
For each source field we define the target STIX2 object, property, relationship and transformation rule, and we extract a representative sample to prove the rules work on real records. You receive a signed mapping specification and a sample set with expected outputs, so you can check the logic before any bulk load.
Load staging and reconcile counts
We run full loads into a staging instance, then compare source and target counts, sampled field values and relationship integrity, and log every rejected or transformed record with its rule. You receive a reconciliation report listing discrepancies and their disposition, and the load is repeated until the remaining differences are explained and accepted.
Validate results with analysts
Your analysts search, pivot and review migrated intelligence in staging against a test list of real investigation questions, and they flag objects that look wrong or are hard to find. You receive signed analyst acceptance criteria and a defect list, and fixes are retested in staging before cutover is scheduled.
Cut over with a tested rollback path
Before cutover we confirm the target version and infrastructure steps against the vendor's upgrade and deployment documentation, because the exact sequence depends on the source and target versions and any version or infrastructure move. We then run the production load, switch access, and keep the source available with a documented rollback procedure that has been rehearsed. You receive a cutover record and a confirmed rollback plan.
Hand over runbooks and operations
We deliver runbooks covering the platform, workers, connectors, backups, restore, mapping rules and known exceptions, and walk your operations team through them. You receive the documentation set and a handover sign-off confirming your team can run the platform without us.

What teams keep in-house and what they outsource

This table compares, for each part of an OpenCTI migration, what the internal team usually owns, what a partner usually takes on, and the skills each side needs, so you can see where the work is shared.

Work part	Usually in-house	Usually outsourced	Skills required
Source ownership and data-owner sign-off	Data owners decide which feeds, MISP events, spreadsheets and reports are worth keeping, and who signs off on each source	Partner drafts the source inventory, flags duplicates and stale sources, and prepares the sign-off record	Intelligence management, data governance, knowledge of how each source is used by analysts
Mapping rules to STIX2	Analysts define how the organization's intelligence practice classifies actors, campaigns, indicators and reports	Partner translates those rules into mapping specifications and tests them against sample records	STIX2 modeling, MISP and spreadsheet structures, analyst-level threat intelligence practice
Extraction scripting and connector configuration	Owners of the source systems grant read access and confirm field meanings	Partner writes extraction scripts, configures import connectors and sets worker capacity for the batch	Python, OpenCTI connector configuration, API tokens, RabbitMQ and worker operations
Reconciliation and statistical checks	Data owners review discrepancies that involve judgment calls about duplicates or confidence	Partner compares object counts, relationship counts and sampled records between source and target, and reports gaps	Data profiling, scripting for comparisons, familiarity with STIX2 object relationships
Analyst validation	Analysts check that migrated reports, indicators and relationships are usable in daily work	Partner prepares test sets, validation checklists and defect logs	Analyst workflow knowledge, clear acceptance criteria written before the load
Cutover coordination	Operations and analyst leads set the freeze window, communication plan and rollback decision	Partner runs the cutover runbook, the final load and the post-load checks	Change management, incident handling, OpenCTI platform administration
Post-migration operations	Internal platform team owns connectors, data quality, access and daily use	Partner may offer retained support for upgrades, connector fixes and recurring reconciliation, if agreed in writing	OpenCTI administration, Elasticsearch or OpenSearch operations, release and upgrade testing

What usually goes wrong

Most OpenCTI migrations fail in the data work, not the install. The cards below describe the failure modes we see most often in threat intelligence moves and the checks that prevent them.

Mapping loses relationships or markings

Source records often carry links between indicators, malware and campaigns, plus TLP or other marking values. A field-by-field mapping can drop those links or leave markings unset, so sensitive intelligence becomes visible to the wrong audience. Prevent it with a mapping specification signed off by analysts and a sample load checked for relationships and markings.

Re-imports create duplicate objects

Running a load twice, or after a partial failure, can create a second copy of every indicator, report and actor. Duplicates distort counts, dashboards and scoring. Prevent this with idempotent loads keyed on stable identifiers, so a re-run updates existing objects instead of creating new ones.

Source identifiers not preserved

If the original identifiers are not stored, later references from tickets, reports, MISP events or other systems point to nothing. Keep the source identifier on every imported object as an external reference, and confirm that lookups by that identifier return the migrated object before the source is retired.

Timestamps and confidence distorted

Transformation steps can shift timestamps across time zones, reset first-seen and last-seen dates to the import time, or rescale confidence values from one scale to another. Analysts then lose the age of intelligence and misjudge its reliability. Check a sample of records field by field against the source after each transformation.

Inconsistent spreadsheet columns

Spreadsheets maintained by different analysts often use different column names, date formats, delimiters for multiple values and empty-cell conventions. A single parser then mis-reads some rows silently. Agree a column dictionary, validate every file against it before import, and reject rows that fail rather than guessing their meaning.

Migrating data analysts no longer use

Moving every historical record inflates storage, search cost and connector workload, and it carries stale indicators into active workflows. Ask analysts which sources, date ranges and object types they use, then agree a retention cut-off and archive the rest in a read-only form outside the platform.

Cutover without a tested rollback

A cutover that changes sources, connectors and user access at once leaves no safe way back if the new platform fails. Keep the source frozen during cutover, reconcile counts before and after, and rehearse the rollback on a copy of production data before the switch date.

Access rules do not carry across

Groups, organizations and sharing rules in the old platform rarely map one-to-one to OpenCTI roles and data segregation. Users can then see too much or lose access to their own work. Document each source access rule, map it to a target role or organization, and test access with a sample user from each group.

Older install not checked against its release line

An older OpenCTI install may hold data shaped by a release that is no longer supported, or by connectors that have since changed. Moving it without checking the data model and version path can break imports or hide defects. Record the current version, confirm the upgrade path against the release line in the product life cycle docs, and test the upgrade on a copy first.

How the work changes by starting point

MISP data commonly arrives through the OpenCTI MISP integration, which is the usual path for moving events, attributes and objects into the STIX2-based knowledge schema. The exact import path must be confirmed for the connector version in use, because field handling and filtering options vary between releases.

Extraction and mapping: Confirm how MISP event tags, galaxies, object templates and sharing groups translate into OpenCTI labels, markings and identities.
Versions: Confirm the MISP version, the OpenCTI release line and the connector version as one tested set.
Effort drivers: Event volume, the share of custom object templates, and whether historical events or only recent ones are in scope.
Decisions: Which distribution levels to import, whether to deduplicate against existing entities, and how to handle events that were shared with restrictions.
Verification: Sample events should be compared field by field in the target before bulk import starts.

What you need to provide

Before migration work starts, the client needs to provide read access to every source, with a sample export from each. The sample is what lets the team map fields to STIX2 objects and find gaps before committing to a full run. Each source also needs a named data owner who can answer questions about field meaning, confidence values, sharing markings and records that were edited by hand. For a MISP instance, this is usually the team that runs MISP. For spreadsheets, it is the analyst who maintains them.

Analysts who will validate results must be named early, with enough time set aside to check mapped indicators, observables and relationships against the originals. Their review is the acceptance test for the mapping. The client also needs to decide which historical data to keep, such as an age cutoff, expired indicators, or low-confidence records. Every record kept adds volume to Elasticsearch or OpenSearch, so this decision affects sizing as well as data quality. The cyber threat intelligence lead usually owns both decisions.

The target environment must be ready before data is loaded. Confirm the platform hosts and the dependency services: Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage. Platform engineering owns this. The access and marking model also needs a decision: which organizations, groups and marking definitions apply to migrated data, and who can see sensitive material. Security governance usually owns that model, and it should be settled before import so that imported records are not exposed by default.

Agree a change window with the owners of any source system that stays live and with the analyst teams who depend on OpenCTI during cutover. Also decide the licence. Community Edition is licensed under Apache 2.0, while features such as SSO, audit logs and organization-based data segregation require the Enterprise Edition. If the target runs an LTS release, it also needs a specific LTS license key. Procurement and the CISO or CTO usually own this decision. Ask Filigran to confirm the edition and any trial terms before the migration plan is finalized.

Frequently asked questions

Can our own team migrate spreadsheet threat intelligence into OpenCTI?

Yes, if your team has someone who can map spreadsheet columns to STIX2 objects and load them through the platform's API or an import process. Spreadsheets vary widely: one sheet may hold indicators, another actors and campaigns, and relationships often sit in free-text cells. Your team must decide how each column becomes an entity, relationship or marking, then test the import on a copy. Mapping and cleaning usually take most of the effort. Platform engineers handle the infrastructure side, and analysts must confirm that the imported meaning is correct. A written scope can show which parts your staff would handle and which parts a partner would take on.

What drives the cost and duration of an OpenCTI migration?

The main drivers are the number and type of sources, how clean the data is, how much relationship mapping is needed, and how many analysts depend on the current system. Structure matters more than volume: a large, consistent MISP export can move faster than a small, messy spreadsheet. Custom entity types, connectors that need reconfiguring, and a target platform that must be sized first also add effort. Costs come from the written scope, which lists each source, mapping rule, test cycle and cutover step. Durations depend on the drivers in the effort table, so ask any partner to show how each driver changes its plan.

How do we test a migration without disrupting analysts?

Run the test on a separate OpenCTI instance that analysts do not use, loaded with a copy of the source data. Test in rounds: import a sample, check entity counts, markings and relationship integrity, then load the full set. Analysts review a fixed list of known threat actors, campaigns and indicators and confirm they match the source. Keep production unchanged until the sign-off criteria are met. Agree the test environment, acceptance checks and rollback step in the written scope before any data moves.

Can MISP data migrate into OpenCTI without losing relationships?

Relationships are preserved only when both ends of each link are mapped and imported together. OpenCTI uses a STIX2-based schema and integrates with MISP, but events, attributes, objects, tags and sharing settings must each be checked against your data. Confirm how each MISP object type, galaxy and distribution setting translates, and what happens to links that point to events outside the export. Test with a sample event that has several linked objects, then compare counts and links on both sides. Ask for the mapping table as a deliverable in the scope.

How do we move an older OpenCTI install without losing data?

Plan it as a new deployment on current infrastructure, moving data across through a tested export and import. First record the installed version, enabled connectors and custom settings. Then check the dependency versions the target needs, including Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage. Compare data counts and sample records on both systems before cutover. Keep the old system available until analysts sign off and rollback has been proven. Choose the release line, including whether an LTS line fits, as part of the upgrade plan, and have the written scope name each step.

Can a migration run in parallel with a live OpenCTI source?

It can, if the source can report what changed since the last copy. The usual approach copies data in batches while the source keeps receiving updates, then runs a delta sync at cutover. Feasibility depends on whether the source tracks changes by timestamp or identifier, and whether incoming records arrive through connectors you can pause. Expect a short freeze window where changes stop, and confirm how analyst edits made during the copy will be reconciled. Parallel runs need more testing and monitoring than a single load, so define the freeze, delta and conflict rules in writing before work starts.

How DeployOpen delivers OpenCTI migrations

DeployOpen scopes, builds, tests and hands over OpenCTI migrations inside infrastructure you control, whether the source is MISP, spreadsheets, another platform or an older OpenCTI install. Each engagement is fixed-scope, with deliverables agreed in writing before work starts.

How we scope

Inventory the source systems, data volumes, object types and the teams that depend on each dataset before any mapping starts.
Map each source field to STIX2 objects and relationships, and record which fields are dropped, merged or left in custom attributes.
Confirm the target OpenCTI version, Enterprise Edition needs such as SSO or audit logs, and whether an LTS license applies.
Agree the written scope, deliverables and timeline with you, and ask for the quote to break out source-by-source effort.

How we build

Stand up a non-production OpenCTI environment with Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage sized to the migration volume.
Build import scripts or connector configurations for each source, with repeatable runs so that a failed batch can be rerun safely.
Test a representative sample against the mapping rules, checking object counts, relationships, markings and author attribution.
Run a timed full-volume rehearsal and record worker load, errors and any deduplication outcomes before scheduling cutover.

How we hand over

Deliver the mapping specification, import scripts, configuration and a reconciliation report comparing source and target counts.
Document the cutover runbook, rollback steps and the final checks your analysts and administrators will perform after go-live.
Walk your operations team through running imports, monitoring workers and retiring the legacy store or previous install.
Provide written records of what was migrated, what was excluded and what requires a follow-up decision from your intelligence owners.

How we support

Offer ongoing support and upgrades as a retainer after handover, covering issues that appear once analysts use the migrated data.
Plan any follow-on move from a non-LTS release to the LTS line as a separate, tested change, confirmed against your license.
Confirm with your vendor or Filigran which release and license terms apply to your environment before scheduling upgrades.
Review connector and data volume growth with your team so that the migrated dataset stays manageable as feeds are added.