OpenCTI LTS versus rolling release upgrades

The one licensing change supplied for this topic affects authentication. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature. Teams running Community Edition with SAML, OpenID Connect or another SSO strategy must decide before upgrading across that boundary whether they will hold an Enterprise Edition license or move sign-in to another mechanism. Start by listing every authentication strategy in use, recording which users depend on each one, and confirming with Filigran which strategies remain available under Community Edition on your target line.

Treat the license decision as a workstream with a named owner, a budget line and a go or no-go gate before the upgrade window. Ask Filigran for a written quote covering the Enterprise Edition license your target line requires. LTS lines also need a specific LTS license key, so an LTS plan may involve two license questions rather than one. Ask whether trial or free licenses apply to your organization, since the vendor documents those for development, research and non-governmental organizations. If approval arrives late, the fallback is to stay on a release before the boundary, which means accepting that release's support window, so check the life cycle documentation for its end dates first.

Other breaking changes and deprecations are not covered by the facts supplied for this topic, so the checklist must come from primary sources. Read the release notes for every regular and LTS release between your current version and your target on the OpenCTI releases page, and read the product life cycle documentation for support windows and LTS rules. Build a register with one row per change. Record the release, the change, the component it touches (platform, workers, connectors, dependencies or configuration), whether it removes or renames a setting, and the person who decides. Mark each row as no action, configuration change, connector change or blocker.

Then check the dependency floor and connectors against the target. The deployment overview lists minimums of Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later and RabbitMQ 3.11 or later, plus S3-compatible storage, so confirm that each running version meets the requirements of the target release, since its notes may have raised them. Confirm that each connector version works with the target platform, because connectors are separate components that must stay aligned with the platform. Finally, rehearse the upgrade on a staging copy of production data, watch the automatic migrations run to completion, and tie the rollback plan to the register so every blocker has an agreed resolution before production begins.

Connector versions must be checked against the platform version during every OpenCTI upgrade, because connectors run alongside the platform and depend on its messages. An OpenCTI deployment includes the platform (UI and GraphQL API), Python workers that consume RabbitMQ messages for asynchronous writes, and connectors for import, enrichment, file extraction, export and stream consumption. Connectors read from and write to the platform through this messaging path, so a change in how the platform handles messages or data can affect a connector even when the platform starts cleanly. Treat connector versions as part of the platform change from the first planning meeting.

Start with an inventory of every connector: its name, the image or package version it runs, the host or cluster where it runs, the team that owns it, and the platform version it was last tested against. Then confirm which connector releases support your target platform release. Check the OpenCTI connectors repository and the release notes for both the platform and each connector. The material available for this page does not include a compatibility matrix, so do not assume that a connector release supports a platform release because the version numbers look close. Ask the platform owner to confirm in writing which connector releases they have verified with the target version.

Plan connector upgrades in the same change window as the platform upgrade. Running an upgraded platform with older connectors, or the reverse, creates a mixed state that is harder to diagnose during an incident. Read the release notes for any required order of operations, and confirm that the shared services connectors depend on, including RabbitMQ, Redis and Elasticsearch or OpenSearch, still meet the platform's documented minimum versions. Custom or in-house connectors need their own test cycle, so identify them early and allow time for them to be rebuilt and tested against the target platform.

After the window, verify each connector before closing the change. Confirm that each connector registers with the platform, consumes its queue without a growing backlog, and writes the objects you expect. Watch RabbitMQ queues and worker logs for errors for a period you agree in advance. Keep the previous connector versions and their configuration available so you can roll back a single connector without reverting the platform. When you request a quote for connector work, ask for the connector count, the number of custom connectors, the test environments included and the verification steps in the written scope.

Define the test set before the upgrade window opens, and treat a passing run as the entry condition for the change. The set should show that the functions your team depends on still work on the target version. Start with login, using the strategy your team actually runs: local users, LDAP, or SSO. If you use SSO, confirm that your license covers it, because since OpenCTI 7.260224.0, defining and using authentication strategies is an Enterprise Edition feature. Test an administrator account, a standard analyst account and a service account, since integrations often authenticate with the last of these.

Next, cover the work your integrations and pipelines do every day. Run the GraphQL API calls that your scripts, dashboards and connectors make, and compare the responses with output recorded before the upgrade, paying attention to field names, pagination and error formats. Push a known sample file through an import connector and confirm that the expected objects and relationships appear. Run one enrichment job and one export, then check the results inside the platform. Finally, check worker health: RabbitMQ queues should drain, workers should keep consuming messages, and backlog should not grow. Confirm that Elasticsearch or OpenSearch, Redis and your S3-compatible storage respond normally too, because workers depend on all of them.

A rollback is only as good as the restore you tested before the change. Take a backup of the database, the search index and object storage, then restore it into a separate environment and run the full test set against the restored copy. Ask Filigran, and confirm in your own environment, whether a database schema change made by an automatic migration can be reversed by restoring a backup. If the answer is no, or you cannot confirm it, treat the pre-upgrade backup as the only rollback path. Record the exact versions and backup timestamps, and keep the database and search index from the same point in time so the restore can be repeated under pressure.

Decide rollback triggers in writing before the change starts, and name an owner for each. Useful triggers include a login failure that affects a defined group of users, a GraphQL call that an integration depends on returning errors, a sample import that does not finish, or a worker backlog that does not drain within a window your team agrees in advance. Also decide in advance whether a defect will be handled by a hotfix or by a rollback. If you run an LTS line, note that after its one-month stabilization it receives only critical bug and security fixes, so a non-critical defect may have to wait for a later release.

Finally, plan the decision itself. Name the person who can call a rollback and the person who executes it, and agree how users and connector owners will be told. Keep the test results, backup records and trigger log together so the decision can be reviewed afterward. If the target version falls outside the release line your team chose, record which tests you could not run and why, so the next window starts with those gaps closed. Confirm with Filigran which release line and license key apply to your target version before scheduling the window, since LTS releases require a specific key.