Migrate from Recorded Future to OpenCTI: what the move involves
OpenCTI can take over the platform role Recorded Future plays for your team, but it cannot take over the collection or analyst reporting that Recorded Future produces. If your trigger is a renewal, a pricing change, a data residency requirement or lock-in, the practical question is whether you still need Recorded Future's portal to store, correlate and share indicators. In most cases you do not, because OpenCTI holds that role on your own infrastructure. What you still need is a source of intelligence, which may be a commercial feed, open feeds or your own research. OpenCTI structures its data on the STIX 2 standard, so indicators, reports, threat actors, malware and the relationships between them can be stored as linked objects and queried through its GraphQL API. Collection, proprietary telemetry and analyst-written reporting remain with whoever produces them, so a move of this kind changes where intelligence lives, not where it originates.
The work is usually shared among three groups. The platform team deploys and sizes the stack, which includes Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, and handles backups, upgrades and access control. Security engineering builds and maintains the connectors that import and export data, and wires indicators into detection and blocking tools. The intelligence team decides what is worth keeping, how reports are structured and which sources remain in scope. Confirm early which of these roles you can staff internally, because the largest effort tends to sit in connector configuration and data mapping rather than in the initial installation. Check the OpenCTI deployment overview and the product life cycle documentation to decide between regular releases and LTS releases, since LTS builds require a specific license key and receive only critical fixes after stabilization.
The effort and risk are moderate and depend mostly on how much history you need to carry over. Current indicators and active reports are the simplest to move. Years of relationships, custom fields and analyst notes take longer to map to the STIX 2 model and need validation in a test instance first. The main risks are losing context during import, duplicating records from overlapping sources, and running without a feed if the subscription ends before the new pipeline is proven. Ask any implementation partner for a written scope that names the data sets, connectors, environments, acceptance tests and cutover steps, and confirm with your own environment which Recorded Future exports and API access you are entitled to under your current contract before work begins.
Which Recorded Future capabilities map to OpenCTI, and which need rework
This table maps common Recorded Future capabilities to their OpenCTI equivalents and marks each as clean, needs rework or gap. Read the status column as a planning signal: confirm connector coverage and licensing with Filigran or in a pilot before you cut any subscription.
| Capability | OpenCTI equivalent | Status | What to confirm |
|---|---|---|---|
| Indicator storage | STIX 2 objects such as indicators and observables, held in the OpenCTI knowledge graph | Clean | Export formats and field mapping for your current indicator set in a pilot import |
| Reports and analyst write-ups | STIX report objects with linked entities and attached files stored in MinIO-compatible storage | Needs rework | Templates and report layout will be rebuilt by your analysts, not carried over automatically |
| Relationships and graph views | Entity relationships and the graph visualization built on the STIX knowledge schema | Clean | Whether your relationship types and graph depth needs match the default views |
| Search | Full text indexing and filters backed by Elasticsearch or OpenSearch | Needs rework | Saved searches and alert queries must be rewritten as OpenCTI filters or playbook rules |
| Enrichment from Recorded Future risk data | Recorded Future connectors (enrichment and feed import), if your subscription and token allow them | Needs rework | Connector availability, supported object types and update cadence with Filigran or Recorded Future |
| ATT&CK mapping | MITRE ATT&CK connector that maps techniques to intelligence objects | Clean | Connector version compatibility with your OpenCTI release line |
| API access | GraphQL API for reads, writes and automation | Needs rework | Every script and integration calling the Recorded Future API must be rewritten against GraphQL |
| Collection from proprietary sources | No equivalent in OpenCTI, which stores and organizes intelligence but does not collect it | Gap | What you need from open feeds, partner sharing or a retained commercial feed |
| Analyst reporting and finished intelligence | No equivalent. Your team writes its own reports inside OpenCTI | Gap | Staffing and editorial capacity to produce the reports you currently receive |
| User access and single sign-on | Local accounts plus SSO options such as OpenID, LDAP, SAML, certificate and header authentication in Enterprise Edition | Needs rework | Whether SSO and organization segregation require the Enterprise Edition License, and what your identity provider supports |
| Audit logs, playbooks and organization segregation | Enterprise Edition features under the OpenCTI Enterprise Edition License | Needs rework | License decision before go-live, since these features are not in Community Edition |
What moves cleanly and what stays behind
Indicators, observables, reports and the links between them move cleanly into OpenCTI because they map to STIX 2 objects. OpenCTI structures its data on the STIX 2 standard, so indicators, observables, malware, threat actors and the relationships connecting them can be represented as STIX objects and imported as such. Before you rely on that, export a sample from Recorded Future, land it in a non-production OpenCTI instance, and check that object types, labels, confidence scores, validity dates and relationships survive the import. Confirm with your team which Recorded Future export formats and import paths you will use, whether that is risk list downloads in CSV or STIX, TAXII collections, or the Recorded Future connector if the feed stays. Also decide who owns the mapping for fields with no direct STIX equivalent, such as proprietary risk scores and internal analyst notes.
Commercial intelligence content does not come across as data that OpenCTI can hold or regenerate. Analyst-written reports, proprietary collection from Recorded Future's own sources, and the risk scoring logic behind exported values stay in the Recorded Future portal or are lost when the subscription ends. An export can carry the resulting indicator or a score snapshot, but it cannot carry the research method, the underlying collection or the ability to re-score historical items. Plan for this in your retention decisions: archive the reports your analysts still cite, record the date and version of each exported risk list, and note which downstream detections depend on scores you can no longer refresh.
Treat the content you lose as a capability gap rather than a data migration task. OpenCTI can host your own analyst reporting, but it will not produce the proprietary collection that Recorded Future gathers, so the question is which open feeds, sharing communities or commercial feeds will cover the same use cases. Ask your team to list the detections, enrichment steps and executive reports that currently depend on Recorded Future, then mark each as migrated, replaced or retired. Any item marked replaced needs a named source before the subscription ends, and any item marked retired needs sign-off from the consumers who rely on it.
Data exports and integrations to rebuild
Moving off Recorded Future is mostly a question of which data paths you rebuild, who owns each one, and which ones stop when the subscription ends. The six paths below cover what leaves the portal, how it reaches OpenCTI, and where it goes after that. Confirm each one against the current documentation before you cut anything over.
Risk list exports in CSV and STIX
Risk lists are the simplest data to carry across. Each export holds indicators with their risk scores and context at the moment you download it, so it is a snapshot, not a live feed. Your team owns the schedule, the storage location and the import step into OpenCTI. Confirm which export formats and file size limits your subscription includes, and whether the STIX output maps cleanly to OpenCTI's STIX 2 model. Expect to re-run exports on a cadence you set yourself.
TAXII collections
TAXII collections deliver STIX content on a pull basis, so they are the closest match to a live feed if you keep the subscription. Whoever holds the TAXII credentials controls what enters the platform, and a polling job or connector must run inside your network. Confirm which collections are included in your contract, the polling interval the service allows, and how deleted or revoked indicators are represented so they do not linger in OpenCTI.
Recorded Future connector and Enrichment connector
OpenCTI connectors run as separate processes that import or enrich data through the platform's message queue. If you keep Recorded Future, the Recorded Future connector brings intelligence in and the Enrichment connector looks up observables on demand, which changes how often you query the service. Your team operates these connectors, so they need patching, monitoring and a restart procedure. Confirm which connectors are current, which version of OpenCTI they support, and what they do when the API is unavailable.
API token handling
Each connector that calls the Recorded Future API uses a token tied to your subscription. Store tokens in your secrets manager, scope them to the minimum needed, and rotate them on a schedule your security team sets. Remember that the token is the entitlement, so a token left in a container image or a shared configuration file is a credential exposure. Confirm the token types your contract issues, how revocation works, and whether usage is logged per token.
SIEM and firewall blocklist pushes
Many teams today push high-risk indicators from Recorded Future into SIEM watchlists or firewall blocklists. After migration, OpenCTI can export indicators to those targets only if you configure a stream or export connector and build the filter that selects what goes out. Your security operations team owns the blocklist content and the rollback path if a false positive blocks a business service. Confirm the export formats each target accepts and the score threshold you use for blocking.
MISP and TheHive links
OpenCTI ships connectors for MISP and TheHive, so indicators can flow to a sharing community or into case management without manual exports. Choose the direction of each link deliberately, because two-way sync can duplicate or overwrite records if identifiers do not match. The platform team owns the connector configuration, and the case team owns what reaches TheHive. Confirm the connector versions you run and test the mapping of indicator types and confidence values on a copy before enabling it in production.
The migration sequence from inventory to decommission
This sequence moves Recorded Future consumers onto OpenCTI in controlled stages, so each feed, indicator and workflow is accounted for before the subscription or its connectors are switched off. Each step ends with a written output that the next step depends on.
Inventory feeds, use cases and consumers
Your threat intelligence lead, with the SOC and detection engineering teams, lists every Recorded Future product in use, including risk lists, alerts, API calls, STIX or TAXII collections and portal reports. For each item, record the owner, the downstream consumers (SIEM rules, firewall blocklists, EDR, ticketing, analyst workflows) and the data format. The step closes with a signed-off inventory that marks each item as migrate, replace, keep or retire. Confirm the current entitlements and export options with Recorded Future, since they determine what can be extracted.
Size and provision the OpenCTI dependencies
Your platform engineers prepare the hosting environment for OpenCTI in your own cloud account, data center or air-gapped network. The documented dependencies are Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage such as MinIO. The deployment overview also documents baseline sizing for the platform, search backend and workers, with at least one platform node for every three workers. Confirm the sizing against your expected indicator volume with your own load tests. The output is a documented architecture, a sizing record and a tested backup and restore for each dependency.
Run a pilot deployment with representative data
A small group of engineers installs OpenCTI, configures authentication (for example SSO through your identity provider), and loads a bounded set of data from the inventory, such as one risk list and one TAXII collection. They connect a test connector, map the STIX objects and verify that relationships, labels and marking definitions survive import. Pilot connectors for Recorded Future should be checked against the current connector documentation before use. The pilot is done when the team has a list of mapping gaps, a repeatable import procedure and a reconciled indicator count against the source export.
Build production connectors and reconcile data
Platform engineers move the validated import and enrichment connectors into production and set their schedules, credentials and error alerting. They run a full load and compare object counts by type, expiry dates and confidence scores with the Recorded Future exports. Analysts review a sample of high-priority indicators to confirm that context was not lost. Document every field that does not map cleanly, because those become the decisions in the next step. The output is a reconciliation report signed by the threat intelligence lead and a documented connector runbook.
Run a parallel period with both platforms
For a defined period agreed in advance, consumers keep receiving intelligence from Recorded Future while OpenCTI receives the same data and feeds the test consumers. The SOC compares alert outcomes, enrichment results and blocklist contents between the two sources and logs every divergence with its cause. Open feeds such as those from MISP communities may be added at this stage, with their licensing reviewed first. The step closes when divergences are explained and accepted, and the team has a tested rollback that returns each consumer to its previous feed in a documented procedure.
Cut over consumers one group at a time
Consumers are moved in groups, starting with the lowest-impact ones, such as dashboards and analyst research workflows, and ending with blocking controls such as firewall and EDR blocklists. Each group has a named owner, a change record and a rollback step. Before a group moves, confirm that its exports or API calls point to OpenCTI and that the format each tool expects is produced. The output is a cutover log showing each consumer, its switch date, its verification result and any rollback that was used.
Decommission the subscription and connectors
Once every consumer has run stably on OpenCTI through an agreed observation period, the team disables the Recorded Future connectors, revokes API tokens, removes stored credentials from the platform and archives final exports for audit. Procurement confirms the subscription end date and any data retention obligations in the contract. Confirm with Recorded Future what data remains accessible after termination. The step closes with a decommission record covering credential revocation, archived exports, the final reconciliation report and the updated data flow diagram.
Running both platforms in parallel and cutting over
This path keeps the Recorded Future subscription in place and changes only where intelligence is stored, correlated and shared. Recorded Future data flows into self-hosted OpenCTI through its connectors while existing consumers keep reading from the Recorded Future side until each one is moved. Parallel running is the main reconciliation tool here, because both sources describe the same indicators and you can compare what each platform holds for a sample of recent items.
- Repoint consumers one at a time: Move SIEM rules, firewall blocklists and enrichment lookups to OpenCTI in groups, starting with low-impact consumers, and record which feed each one reads from.
- Reconcile by sample and by count: Compare indicator counts per type and per source, then check a fixed set of recent indicators in both systems for matching values, labels and validity windows.
- Keep the old path live during overlap: Leave the original export or API pull running until the new consumer has produced clean results over a period you agree with the security team.
- Define the rollback trigger: Write down the condition that sends a consumer back to the old path, such as missing indicators or a broken connector, and who has authority to switch it.
- Watch connector and token health: Track API token expiry and connector errors, since a silent failure on the feed side looks like a quiet platform.
Confirm with your Recorded Future account team which data types and API interfaces your current contract includes, and whether the connector use case is allowed under your terms.
A reduced subscription keeps a narrower set of Recorded Future data, often one or two risk list types or specific collections, and moves everything else to OpenCTI or MISP fed by open and community sources. Reconciliation has to answer a different question: not whether both platforms match, but whether every consumer that depended on dropped content has a replacement. Map each consumer to the data it uses before you change the contract.
- Inventory dependencies by data type: List each consumer, the Recorded Future feed or collection it uses and the open alternative that could cover it, if one exists.
- Expect coverage gaps: Some proprietary collection will not have an open equivalent. Record those gaps as accepted risk or as items that stay in the reduced subscription.
- Repoint only the covered consumers first: Move consumers whose data is fully replaced, then handle the rest in a second wave once the reduced subscription is confirmed.
- Reconcile against the reduced scope: Compare volumes for the retained types only, so that a drop in total indicator count is not mistaken for a loss.
- Plan rollback around the contract: Confirm whether dropped feeds can be re-added mid-term, at what cost and with what delay, because a rollback here may depend on the vendor, not your team.
Confirm with the vendor what a mid-term change to the subscription involves, and whether historical data for dropped types remains accessible during the notice period.
Dropping the subscription is the most complete cutover and the one with the least room for error, because no Recorded Future data arrives after the end date. Every consumer must be repointed before that date, and any data you need for history, audit or ongoing investigations must be exported and stored in OpenCTI or another system you control. Plan the parallel run to finish well before the contract ends, so the final comparison is made while the source still exists.
- Export before the end date: Pull risk lists, reports you are entitled to keep and any collections you need for history, in the formats your contract allows.
- Run a final reconciliation before termination: Compare OpenCTI against Recorded Future for each indicator type and record the differences that remain and why.
- Retire consumers in a fixed order: Switch SIEM, endpoint, firewall and enrichment consumers in turn, and confirm each one reads from OpenCTI before the next moves.
- Keep a read-only archive: Store the exported data with its source, date and handling terms, so later investigations can see what was known at the time.
- Decide the rollback window: Once the subscription ends, rollback means re-subscribing, so set a point after which that option is closed and say so in the cutover plan.
Confirm the data-retention and export rights in your contract with the vendor, and check how your auditors expect historical threat data to be kept.
Across all three paths, the cutover is only as safe as the record of what changed and how it can be reversed. This tab covers the controls that apply regardless of the option you choose: change records, reconciliation evidence and a tested reversal path for each consumer. These records also help the security team and auditors see that the change was managed, not improvised.
- Record every repointing change: Log the consumer, the old source, the new source, the date and the approver for each switch.
- Keep reconciliation output: Save the count comparisons and sample checks as dated artifacts so that later questions can be answered from records.
- Test the rollback before you need it: Repoint one low-impact consumer back to its original source and confirm it recovers cleanly.
- Assign ownership for each feed: Name who watches connector health, token expiry and failed imports after cutover, because these failures often go unnoticed.
- Set a review point after cutover: Schedule a review of indicator quality, false positives and consumer behavior before closing the project.
Confirm your internal change-management and retention requirements with your security governance team before finalizing the rollback plan.
What drives cost and duration, and how to keep each down
This table lists the main drivers of cost and effort when moving from Recorded Future to a self-hosted OpenCTI platform, with what each driver depends on and how to keep it down. Read it as a checklist for scoping and quoting, since the largest one-time items are data mapping and SIEM and blocklist rebuilds, while hosting, connector upkeep and analyst time recur.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Consumers and integrations | Each SIEM, firewall, SOAR or sharing partner that reads intelligence adds mapping, testing and ongoing maintenance work. | Inventory every consumer before scoping and move the highest-value ones first. Retire lists that nobody reads. |
| Indicator and relationship volume | Large indicator sets and dense object graphs increase import time, index size and search load on Elasticsearch or OpenSearch. | Import only indicators still in use, set expiry rules, and confirm sizing with the vendor for your actual volumes. |
| Commercial feed retained or dropped | Keeping any Recorded Future feed means connector upkeep and a subscription, while dropping it shifts collection and curation work onto your analysts. | Decide feed by feed. Ask for connector scope in writing so retained feeds are clearly defined. |
| Stack sizing | The documented minimums cover the platform (2 cores, at least 8 GB RAM), Elasticsearch or OpenSearch (2 cores, 8 GB RAM, 16 GB SSD), and at least one platform node per 3 workers, and production load can exceed them. | Start from the documented minimums, load test with real indicator volumes, and ask the implementer to state the sizing basis in the quote. |
| LTS versus regular release planning | Regular releases ship from daily to weekly, while LTS releases arrive every 6 months and are supported for 1 year, so upgrade effort depends on the line you pick. | Pick the LTS line for production and schedule upgrades inside its overlap window. Budget testing for each upgrade. |
| LTS license key handling | LTS releases need a specific LTS license key, and after one month of stabilization they receive only critical bug and security fixes. | Confirm key ownership, renewal terms and who holds the key before go-live. Record the process in the runbook. |
| Staff skills | Operating Elasticsearch or OpenSearch, Redis, RabbitMQ, MinIO, connectors and STIX 2 data modeling needs skills most intelligence teams do not hold today. | Name an owner for the platform, cross-train analysts and ask for knowledge transfer as a line item in the scope. |
| SIEM and blocklist pushes | Every existing push from Recorded Future to SIEM or firewall blocklists must be rebuilt, tested and checked for false positives before cutover. | Map each push to its OpenCTI export or connector path, run both in parallel for a period, and retire the old push only after sign-off. |
| Data mapping and migration | Mapping Recorded Future risk lists and reports into STIX 2 objects and relationships is one-time work that scales with source complexity. | Export a representative sample first, agree the mapping in writing, and limit scope to data that must move. |
| Hosting and upkeep | Infrastructure, patching, backups and monitoring recur for as long as the platform runs. | Right-size the stack, automate deployments and set a fixed patch cadence tied to the LTS schedule. |
What usually goes wrong and how to prevent it
Moving from Recorded Future to OpenCTI tends to fail in the gaps between data, people and operations rather than in the platform itself. The cards below cover the risks we see most often, each with a check to run before cutover. Work through them in order, because the data and consumer risks only surface once the import is underway.
Losing analyst context from reports
Indicators import cleanly, but the reasoning behind them often lived in analyst reports, portal notes and linked finished intelligence. Those narratives rarely map to a single OpenCTI object. Before cutover, list the reports your analysts actually cite, decide which ones become OpenCTI Report objects, and record which context stays in the Recorded Future portal for reference. Confirm with analysts which report types they rely on most.
Duplicate and orphaned indicators
Re-importing the same risk list through a connector and a manual export produces duplicate indicators, and removing a Recorded Future source later can leave orphaned observables with no owning feed. Assign a single source of truth per indicator type, and tag imported objects with their origin so they can be filtered and retired. Run a reconciliation query after each import batch and compare counts with the source export.
Consumers still pointing at the old feed
SIEM rules, firewall blocklists and enrichment scripts often hold direct references to Recorded Future API endpoints, tokens or CSV download paths. These keep working until the subscription lapses, then fail quietly. Inventory every consumer before cutover, switch each one to an OpenCTI export or stream, and keep the old feed running in parallel until each switch is verified.
Unplanned Enterprise Edition needs
Community Edition covers the core platform under Apache 2.0, but some requirements, such as audit logs, playbooks, organization-based segregation, AI insights and SSO options, are listed as Enterprise Edition features under a separate license. If your access policy requires audit trails or SAML and LDAP sign-in, check these against the Enterprise Edition documentation before you design the target state. Ask the vendor to confirm licensing for your use case in writing.
Release and LTS lifecycle drift
OpenCTI ships non-LTS releases often, while LTS lines receive only critical and security fixes after an initial stabilization period. Running a non-LTS build in production, or letting an LTS line expire, creates upgrade debt that grows quickly. Choose an LTS line for production, confirm you hold the required LTS license key, and schedule a recurring upgrade window tied to the published life cycle.
Underestimating sizing and dependency upkeep
OpenCTI depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, and each needs patching, backup and capacity planning. Sizing guidance starts with a platform node of 2 cores and at least 8 GB RAM, and the search tier should be sized for your indicator volume, not the minimum. Ask your implementation partner for a sizing estimate based on your actual feed volume, and budget for ongoing dependency upkeep in the operating plan.
Choosing OpenCTI release tracks and licensing before go-live
Before the cutover date, decide which OpenCTI release track your team will run and confirm the license basis for it. OpenCTI uses date-based version numbers: regular releases follow the pattern x.YYMMDD.z, and LTS releases follow x.YYMMDD.z-lts.n, where the date is the release or LTS branching date. Non-LTS releases ship when they are ready, from daily to weekly, which suits teams that want new connector and platform fixes quickly and can absorb frequent upgrades. LTS releases arrive about every six months, and each is supported for one year, so consecutive LTS versions overlap by six months. That overlap gives you a planned upgrade window rather than a forced one. Use the OpenCTI product life cycle documentation to map the current LTS dates against your migration plan.
The LTS track has a licensing condition that many migration plans miss. LTS container images require a specific LTS license key, and after a one-month stabilization period they receive only critical bug and security fixes. If you choose LTS, ask Filigran in writing which key covers your deployment, who holds it, how it is rotated, and what happens to the image pull and the running instance when the key or support window lapses. Then separate the two editions. Community Edition is licensed under Apache 2.0, while Enterprise Edition uses the proprietary OpenCTI Enterprise Edition License and adds features such as audit logs, playbooks, organization-based segregation and SSO options. If your Recorded Future replacement depends on any of those features, confirm with Filigran whether they are in scope for your edition before you design around them.
Make the track decision a checklist item with an owner, not a default. Record the chosen track, the license key holder, the Enterprise features you need, and the date by which an upgrade must be scheduled. Plan for the upgrade path in the same document, including a test instance on the next release before production moves. Ask your Filigran contact to confirm the terms in writing, because the public documentation describes the tracks and feature set but cannot settle what your contract allows. Verify the current LTS line on the OpenCTI releases page on the day you freeze the design, since release numbers change quickly.
Questions buyers ask before migrating from Recorded Future to OpenCTI
How much effort does a move from Recorded Future to OpenCTI take?
The effort depends on how much of Recorded Future you use and how much of it you intend to keep. A team that only consumes indicators into a SIEM has a smaller job than one that relies on Recorded Future's reports, alerts, analyst notes and API-driven enrichment across many workflows. The main drivers are the number of data types in scope, the number of downstream systems that read indicators today, the volume of historical data you want to keep, and whether your analysts need to be retrained on a new interface. OpenCTI is built on the STIX 2 standard and exposes a GraphQL API, so mapping and integration work is real engineering effort. Ask any partner to break the estimate down by data type, connector and downstream consumer, in writing, before agreeing a scope.
How long does migrating from Recorded Future to OpenCTI take?
The timeline varies with scope, the state of your current intelligence workflows and how much platform work your team must absorb. A deployment that is only a platform layer with a few inputs and outputs is far shorter than a rebuild that moves reports, relationships and integrations together. Parallel running also adds time, because you need both platforms feeding your controls until the new one is trusted. Infrastructure is a factor too: OpenCTI depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, and standing those up in your environment, through your change process, sets the pace. Expect a timeline to be set only after scope is agreed, and ask for milestones tied to specific data flows.
What does the migration need from our own team?
Your team needs to supply decisions and access as much as technical hands. Someone must own the list of intelligence consumers, such as SIEM, firewall and EDR integrations, and confirm which ones change. Your platform or infrastructure team needs to provide the hosting environment, container and orchestration standards, identity integration and backup targets. Your security team must decide which Recorded Future data types matter and who validates the migrated content. OpenCTI's Enterprise Edition features such as audit logs, organization-based segregation and SSO for OpenID, LDAP, SAML or certificate authentication may affect access design, so identity owners should be involved early. Plan named owners for each area before the work starts.
Can we do the migration in-house instead of hiring a partner?
Yes, many teams can do it in-house if they have the skills for the stack. The work covers platform deployment and sizing, STIX 2 data modelling, connector configuration, GraphQL-based integration, authentication, backup and upgrades. OpenCTI publishes a deployment overview and a product life cycle, and its releases come in regular and LTS lines, with LTS releases requiring a specific license key. Those upgrade rhythms create recurring work. The honest test is whether your team can carry the platform for its full life, not only the first deployment. A partner such as DeployOpen can plan, implement, integrate, harden, back up, upgrade and document the platform under a fixed-scope agreement, or provide ongoing support as a retainer.
Do indicators and reports transfer from Recorded Future into OpenCTI?
Indicators and relationships are the most portable, and reports need more care. OpenCTI structures data on the STIX 2 standard, and Recorded Future data exported in STIX or CSV can be mapped to that model, so indicators, their observables and many relationships can be loaded with the right transformation. Reports are harder because their value often lies in analyst narrative, context and source handling, which may not survive a bulk export intact. Confirm with Recorded Future exactly which interfaces and formats your subscription allows you to export, and check the export terms before you plan the move. Test a sample set of each data type end to end before committing to a full load.
Can we keep a Recorded Future feed flowing into OpenCTI?
Yes, if your Recorded Future subscription and licence terms allow it, you can keep the feed and connect it to OpenCTI. OpenCTI has connectors for MISP, TheHive and MITRE ATT&CK, and the connector ecosystem is where a Recorded Future data source would be wired in, so confirm the connector status and maintenance with the vendor or the project before you depend on it. This option changes what you pay for: you keep the intelligence and the API access you need, but you may still need a Recorded Future subscription, and you still operate the platform that stores and shares the data. Ask for the exact entitlement and API token handling in writing.
What can OpenCTI not replace from Recorded Future?
OpenCTI is a knowledge and sharing platform, so it cannot replace Recorded Future's proprietary collection, its analyst-authored reporting or its own enrichment and risk scoring. OpenCTI stores, correlates and shares the intelligence you bring into it, and it can use MITRE ATT&CK through a connector, but the underlying collection sources are not part of the open-source platform. Analyst reporting is produced by people with access to sources you may not have. Plan for these gaps explicitly: either keep a commercial feed, subscribe to community or open sources, or accept reduced coverage in specific areas. Compare what each source contributes, not only the platform price.
What should we ask a partner before agreeing a migration scope?
Ask for a written scope that names each data type, each connector, each downstream consumer and each platform component that will be deployed. Ask how the partner will handle OpenCTI's dependencies, including Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, and how sizing will be documented against the vendor's deployment overview. Ask which Recorded Future interfaces will be used for export, how credentials and API tokens will be stored, and how Enterprise Edition features will be licensed if you need them. Ask who will support upgrades across OpenCTI's regular and LTS releases. Clarify whether DeployOpen would prepare evidence for a compliance assessment, which it does without issuing any audit report or certification.
How DeployOpen would scope the work with your team
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted OpenCTI inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. Most engagements are fixed-scope, so the systems, connectors, deliverables and timelines are agreed in writing before work starts. For a migration like this, the scope is not fixed at the outset. It follows from two inputs: an inventory of what Recorded Future data you actually use (risk lists, STIX or TAXII collections, API-driven enrichment, saved searches, and the reports analysts rely on) and the results of a pilot that loads a representative slice of that data into OpenCTI.
The inventory tells us which data must move, which can be replaced with open feeds, and which stays in the Recorded Future portal. The pilot tells us what the platform needs in practice. Expect the written scope to cover the OpenCTI deployment on the dependencies named in the deployment documentation (Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage), the connector set for each feed you keep, the authentication model, including SSO if your Enterprise Edition licensing covers it, backup and restore testing, and the handover documents your operations team will use. Confirm with Filigran whether your intended OpenCTI edition and any Enterprise features you need are licensed for your deployment model before the scope is signed.
A quote follows from the written scope. DeployOpen does not publish a price list, so ask for the quote to show the components separately: the pilot, the build and integration work, hardening, the documentation and any ongoing retainer for upgrades and support. Ask how each component changes if the inventory finds more feeds or more legacy integrations than expected. Your team should decide early who owns the Recorded Future API tokens, who approves changes to connectors, and who signs off the pilot results, because those decisions set the boundaries of the scope.
How DeployOpen runs the migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Recorded Future to OpenCTI, we start with a written scope that separates what OpenCTI will hold from what stays in the Recorded Future portal or with another provider.
How we scope
- Inventory which Recorded Future data types you use: indicators, reports, risk lists, and alerts, and which consumers depend on each.
- Decide which connectors stay in the migration, and which feeds or analyst workflows remain outside OpenCTI.
- Agree deliverables, timelines and responsibilities in writing before work starts, since engagements are fixed-scope.
How we build
- Deploy OpenCTI with its platform, workers, connectors, Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO in your environment.
- Map Recorded Future entities to STIX 2 objects and test imports, relationships and deduplication against sample data.
- Configure authentication, organization-based segregation and access rules, then test them against your identity provider.
How we hand over
- Document the architecture, connector configuration, data mapping, runbooks and the decisions made during scoping.
- Provide a handover session covering operation, upgrades, and how the chosen LTS or regular release line is maintained.
- Record what did not move, such as proprietary collection and analyst reporting, so your team knows where intelligence now comes from.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan OpenCTI version upgrades against the published release and life cycle schedule, with testing before each change.
- Ask any quote to itemize platform hosting, connector upkeep, testing and support so the recurring costs are visible.
