Which strategy should I use for Strimzi ZooKeeper to KRaft Before Kafka 4.0 Adoption?
Kafka operators on Strimzi need to decide whether to finish ZooKeeper-to-KRaft migration now or delay platform upgrades as Kafka 4.0-era assumptions make the old topology harder to justify.
Blockers
- Strimzi removed support for ZooKeeper-based Kafka clusters starting with Strimzi 0.46.
- Kafka 4.0 runs only in KRaft mode.
- The supported migration path exists in Strimzi from 0.40.0 onward.
- Verified prerequisites include Kafka 3.7.0 or newer.
- Current docs say KRaft deployments require Kafka plus KafkaNodePool resources.
- Verified prerequisites include the Unidirectional Topic Operator.
- package/strimzi-0.45 — EOL about one year after Kafka 3.9 release
Who this is for
- enterprise
- high-scale
- real-time
Candidates
Finish the migration now on the supported Strimzi migration path, then move to Strimzi 0.46+ and Kafka 4.x
As of 2026-04-02, Strimzi 0.48 documentation states that Kafka 4.0 runs only in KRaft mode and that Strimzi removed support for ZooKeeper-based Kafka clusters starting with Strimzi 0.46. The supported migration path exists in Strimzi from 0.40.0 onward and is semi-automated through the `strimzi.io/kraft` annotation states and `KafkaNodePool` resources. Current docs also say KRaft deployments require `Kafka` plus `KafkaNodePool` resources, and production setups typically use dedicated broker and controller nodes. There is no Strimzi pricing change to weigh here; check official docs for any separate Kubernetes or managed-platform cost impact.
When to choose
Use this when you need future Kafka or Strimzi upgrades, or when platform policy already assumes Kafka 4.x and operator support continuity. The decisive factor is that ZooKeeper clusters cannot be upgraded under Strimzi 0.46 or later, so finishing migration is the clean path to stay on supported releases.
Tradeoffs
You remove ZooKeeper operational overhead and unblock Kafka 4.x adoption, but the migration is still a real platform change that needs extra controller nodes, rolling updates, and careful validation.
Cautions
Verified prerequisites include Kafka 3.7.0 or newer, `KafkaNodePool` usage for brokers, `strimzi.io/node-pools: enabled`, and the Unidirectional Topic Operator. During migration, ZooKeeper and KRaft controllers run in parallel for a period, so you need spare cluster capacity. As of 2026-04-02, Strimzi still uses static controller quorums, which means controller-role node pools cannot be scaled or renamed freely and some storage changes remain constrained.
Delay only on the ZooKeeper-capable bridge release, but plan migration before any further platform upgrade
As of 2026-04-02, Strimzi's Kafka 4.0 planning states that the last ZooKeeper-capable Strimzi line was expected to be the 0.45 generation paired with Kafka 3.9, with 'extended support' attempted for about one year after Kafka 3.9 release where possible. That extended support is narrow: critical CVEs, critical bug fixes, and new Kafka 3.9 patch releases where feasible, not new features. The same Strimzi guidance says that no matter how long you wait on that bridge, you still must migrate to KRaft on the ZooKeeper-capable line before upgrading to newer Strimzi or Kafka versions. It is therefore a short-term risk-buffer, not a durable topology choice.
When to choose
Use this only if you have a near-term blocker such as node-pool conversion work, change-freeze timing, or insufficient capacity to run ZooKeeper and controllers in parallel during migration. The decisive factor is whether a short controlled delay is safer than forcing a rushed migration, while accepting that the migration debt still has to be paid before 0.46+.
Tradeoffs
This buys preparation time and may reduce migration execution risk, but it extends time on an aging release line and keeps you off current Strimzi versions that have already dropped ZooKeeper support.
Cautions
Do not treat this as a steady-state option. Strimzi explicitly warns that if you upgrade a ZooKeeper cluster to the Kafka-4.0-era Strimzi line without migrating first, the cluster is not deleted but Strimzi cannot operate it; recovery then means recreating the cluster on KRaft or downgrading and migrating first.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Which strategy should I use for Strimzi ZooKeeper to KRaft Before Kafka 4.0 Adoption?"