Cequence Platform 9.1.x to 9.2.x upgrade and rollback

This article covers upgrading an on-premises Cequence Unified API Protection (UAP) platform installation from release 9.1.x to release 9.2.0, and rolling back if needed. Release 9.2.0 moves the platform's Kafka message bus off ZooKeeper and onto KRaft, and moves Airflow from 2.x to 3.x. Both changes recreate underlying infrastructure rather than migrating it in place, so read this article fully before you begin.

SaaS-hosted environments are upgraded by Cequence directly. This article is for on-premises installations using Helm.

Before you upgrade to release 9.2.0

Complete the following before starting the upgrade.

Export your current configuration. The upgrade replaces both the Airflow metadata database and the Kafka cluster rather than migrating them, so anything you need to retain from either system must be exported first.

Data loss: Airflow run history. DAG run history, task history, connections, variables, and users do not carry over this upgrade. If you need to preserve this history, export it before you begin. Machine-learning model configurations themselves are unaffected.

Data loss: Kafka topic data. The Kafka cluster is rebuilt, not migrated, as part of this upgrade. Topic data does not carry over. This is expected and does not affect UAP functionality, because configuration lives in Elasticsearch and republishes to Kafka automatically when components start.

Upgrading to release 9.2.0

Complete the steps in order. Each step depends on the one before it.

Export all current configuration, if you have not already done so as part of the prerequisites above.
Apply the Strimzi 0.51.0 custom resource definitions (CRDs) to your cluster, server-side.
Upgrade the Strimzi operator to release 0.51.0.
Run the Helm upgrade to release 9.2.0.
The upgrade recreates pods across the platform as it proceeds. Monitor the rollout and verify that each component reaches a healthy state before considering the upgrade complete.

After the upgrade completes, the platform is running release 9.2.0 with Kafka on KRaft and Airflow on 3.x. Continue to the verification steps below.

Configuration value changes

The following Helm chart values change between release 9.1.x and release 9.2.0. Old key names still exist in values.yaml for backward compatibility, but release 9.2.0 does not read them, so anything left in the old location is silently ignored rather than raising an error.

Release 9.1.x value	Release 9.2.0 value	Change
`airflow.airflowVersion: "2.11.0"`	`airflow.airflowVersion: "3.3.0"`	Airflow major version
`airflow.webserver`	`airflow.apiServer`	The webserver component is replaced by api-server, which serves both the UI and the REST API at `/api/v2/`.
`airflow.ingress.web`	`airflow.ingress.apiServer`	The new block defaults to `enabled: false` and an empty `ingressClassName`. Set both explicitly, or the Airflow UI is unreachable after the upgrade.
`airflow.config.api.auth_backends`	Removed	Release 9.2.0 handles API authentication differently. Delete this key from your overrides.
`airflow.config.elasticsearch.log_id_template` using `{execution_date}`	Uses `{run_id}`	Template becomes `{dag_id}_{task_id}_{run_id}_{try_number}`.
Not present	`airflow.config.elasticsearch.write_to_es: 'True'`	New. Task logs write to Elasticsearch.
Not present	`airflow.config.elasticsearch.target_index`	New. Defaults to a daily index of the form `airflow-filebeat-<date>`.
Not present	`airflow.jwtSecretName: airflow-api-auth-jwt-secret`	New. Shared JWT signing key used by the scheduler, api-server, and workers.
Not present	`airflow.apiSecretKeySecretName: airflow-api-secret-key`	New.
Not present	`airflow.apiAuthJwtSecretConfig`	New. Leave the `secret` value empty to generate and persist one automatically.
Not present	`airflow.apiServerUrl: ""`	New. An empty value derives the URL from the release name. Consumed internally as `AIRFLOW_API_BASE_URL`.

Old key names remain present in the chart's default values.yaml but are not rendered on release 9.2.0. This is a compatibility carryover, not an indication that the old keys still function.

Verifying the upgrade

Verify the following after the upgrade completes and before you consider it finished.

Verify that the pods removed in release 9.2.0 are gone: kafka-zookeeper-*, kafka-*, and airflow-webserver.
Verify that the pods new in release 9.2.0 are running: kafka-4-controllers-*, kafka-4-kafka-*, airflow-api-server, and airflow-dag-processor.
Verify that kafka-4-kafka-*, kafka-4-entity-operator-*, kafka-4-kafka-exporter-*, and kafka-4-connect-* are all healthy. These are the renamed equivalents of the release 9.1.x Kafka pods.
Check system logs across the platform for errors or warnings.

DAG run history from before the upgrade is not preserved, because the Airflow metadata database migrates to a new PostgreSQL 17 instance rather than carrying forward. This is expected. See the data loss warning above.

Once verification passes, monitor system performance for a few hours before considering the upgrade complete. Watch for error logs or unusual behavior during this window.

Rolling back to release 9.1.1 or later

If you need to roll back, roll back to release 9.1.1 or a later 9.1.x release. Rolling back to release 9.1.0 is not supported.

Downgrade the Strimzi operator to release 0.45.2.
Run the Helm upgrade specifying release 9.1.1 or later.
Monitor the downgrade as components revert. If airflow-webserver enters a crash loop during this step, delete the pod. It recovers on restart.
Downgrade the Strimzi CRDs to release 0.45.2.
Import the configuration you exported before the upgrade.

Verifying the rollback

Verify that all pods are running.
Verify that the platform version shows release 9.1.1 or later.
Verify that Kafka is back on ZooKeeper. The kafka resource should be ready on Kafka 3.9.1, with kafka-zookeeper-* and kafka-kafka-* pods running.
Check system logs for errors or warnings.

Rolling back also rolls Airflow back to 2.x. The airflow-api-server and airflow-dag-processor pods are removed and airflow-webserver returns. Any Airflow values you moved to apiServer or ingress.apiServer for release 9.2.0 need to move back under webserver and ingress.web for the Airflow UI to be reachable after the rollback.