Apache Kafka 4 Without ZooKeeper: Planning the KRaft Migration and 4.x Upgrade

Apache Kafka 4.0 removed ZooKeeper mode. Every 4.x release runs only in KRaft mode, where Kafka’s own controllers manage cluster metadata. A cluster that still depends on ZooKeeper cannot be upgraded to 4.x directly: it must first be migrated to KRaft on the 3.9 line, and the 3.9 line is no longer listed as a supported release.

This article sets out where the Apache Kafka release lines stand on 26 October 2026, which upgrade path applies to each starting point, how the ZooKeeper-to-KRaft migration works, and what to check before rolling brokers to 4.x.

What changed in Apache Kafka 4.0

The Apache Kafka 4.4 upgrade notes are direct: Apache Kafka 4.0 supports only KRaft mode, and ZooKeeper mode has been removed. The same notes say that clusters in ZooKeeper mode have to be migrated to KRaft mode before they can be upgraded to 4.x.

The 4.0 release removed more than ZooKeeper. The upgrade notes list the removal of old protocol API versions, the original MirrorMaker (MM1), Scala 2.12 support and Log4j, which is replaced by Log4j2. Many deprecated client APIs, configuration options and command-line options were removed as well.

Java requirements also changed. Clients and Kafka Streams need Java 11 or later. Brokers, Kafka Connect and the command-line tools need Java 17. For many estates, the Java runtime on brokers and Connect workers is the first dependency to plan.

Finally, the new consumer rebalance protocol from KIP-848 became generally available in 4.0. According to the upgrade notes, it is enabled on the server when the upgrade to 4.0 is finalized. The same notes add a downgrade limit: once consumer groups use the new protocol, the cluster can only be downgraded to 3.4.1 or newer. Client teams should test the protocol deliberately rather than discover it during the upgrade.

Where the release lines stand on 26 October 2026

The Apache Kafka downloads page lists three supported releases: 4.4.0, 4.3.2 and 4.2.2. Every other release is archived. The page states that the project aims for three releases a year and that bugfix releases are made as needed for supported releases only.

Release line	Latest release (date)	Status on the downloads page
4.4	4.4.0 (22 October 2026)	Supported
4.3	4.3.2 (23 October 2026)	Supported
4.2	4.2.2 (29 September 2026)	Supported
4.1	4.1.2 (17 March 2026)	Archived
4.0	4.0.2 (16 March 2026)	Archived
3.9	3.9.2 (21 February 2026)	Archived; last line with ZooKeeper mode

The project’s time-based release plan describes the intent behind this list. The community tests rolling upgrades from each release in the past year to the latest version, and it will attempt bugfix releases as needed for the last three releases. This is a community intention, not a dated commitment. The project publishes no end-of-life dates.

Two consequences follow. First, a cluster on 3.9 now runs on an archived line, and the bridge it needs for the KRaft migration will not move forward. Second, a cluster on a supported 4.x line today will fall out of the supported list within about a year if it is not upgraded. Upgrade planning is a recurring task, not a one-time project.

Security fixes follow the same pattern. The project’s CVE list records the affected and fixed versions for each vulnerability. Fixed versions appear on release lines that are still maintained, so an archived line can stay exposed to a vulnerability that is fixed elsewhere.

Which upgrade path applies to your cluster

The path depends on two facts: whether the cluster still uses ZooKeeper, and which version it runs. The upgrade notes say brokers must be on 3.3.x or later, for both software and metadata version, before an upgrade to 4.x. KRaft clusters on older versions should first upgrade to 3.9.x.

Starting point	Path to a supported 4.x line
ZooKeeper mode, any 3.x or 2.x version	Upgrade to the 3.9 line, migrate to KRaft, then upgrade to 4.x
KRaft mode, older than 3.3.x	Upgrade to 3.9.x first, then upgrade to 4.x
KRaft mode, 3.3.x to 3.9.x	Rolling upgrade to a supported 4.x line
4.0 or 4.1 (archived)	Rolling upgrade to a supported 4.x line

Clients have their own rule. The 4.0 upgrade notes ask you to make sure brokers are on version 2.1 or higher before upgrading Java clients to 4.0. That rule also covers Kafka Connect and Kafka Streams, which use the Java clients internally.

Migrating from ZooKeeper to KRaft on 3.9

The migration procedure is documented in the Apache Kafka 3.9 KRaft operations guide. On the research date, it required brokers on software version 3.9.1 with inter.broker.protocol.version set to 3.9 before the migration begins. Check the page again before you schedule the work.

The guide describes the migration in phases:

1. Provision the KRaft controllers. Deploy a controller quorum that uses the existing cluster ID, with migration enabled and a connection to ZooKeeper.
2. Enable migration on the brokers. Restart the ZooKeeper-mode brokers with migration enabled and the controller quorum settings. When the last broker restarts, the controllers copy the metadata from ZooKeeper.
3. Move the brokers to KRaft. Reconfigure each broker as a KRaft broker, keep its node ID, remove the ZooKeeper settings and restart it.
4. Finalize the migration. Remove the migration setting from the controllers and restart them one at a time. After this step, ZooKeeper can be deprovisioned.

The guide is clear about the point of no return. Rollback is possible only while the cluster is still in migration mode. After the migration has been finalized, it is not possible to revert to ZooKeeper mode. Each earlier phase has its own revert steps, and the guide warns of a known issue with controller epochs during a revert, with a workaround.

The controller quorum also needs a deliberate design. The 3.9 guide explains that a quorum is either static, listed in controller.quorum.voters, or dynamic, found through controller.quorum.bootstrap.servers. The type is fixed when the controllers are formatted, and the 3.9 guide says a static quorum cannot be converted to a dynamic one. Decide the quorum type, the number of controllers and their placement before the first controller is formatted.

Upgrading a KRaft cluster to 4.x

Once a cluster runs in KRaft mode on a version that the upgrade notes accept, the move to 4.x is a rolling upgrade. Brokers are upgraded one at a time, behavior is verified, and the new metadata version is then finalized with kafka-features.sh and the upgrade --release-version option.

Finalization deserves its own decision point. The upgrade notes say a metadata downgrade is only possible when there are no metadata changes between the versions. Treat the finalize step as the end of the easy rollback window, and run it only after clients, connectors and Kafka Streams applications have been checked against the new brokers.

Plan the target line too. On the research date, 4.4.0 had just been released, 4.3 had reached 4.3.2 and 4.2 had reached 4.2.2. A newly released line is a reasonable target once your own tests pass, but it has had less time in the field. Pick the line, record why, and plan the next upgrade at the same time.

Recent releases also bring changes worth reading before you choose. The upgrade notes record that Queues for Kafka (share groups) are production-ready in 4.2. In 4.4, broker.id is deprecated in favor of node.id, and brokers with a JWKS endpoint now fail at startup unless the expected audience and issuer are set. Changes like these can stop a broker from starting if they are missed.

Removed features to check before the 4.x upgrade

Search your estate for anything that depends on what 4.0 removed. The upgrade notes are the reference list; the items below come up most often in inventories.

• Scripts, tooling or monitoring that read from or write to ZooKeeper directly, including command-line options that took a ZooKeeper connection string.
• Cross-cluster replication still running on the original MirrorMaker (MM1). The current tool is MirrorMaker 2, built on Kafka Connect, which needs its own configuration and testing.
• Logging configuration written for Log4j 1.x, and any use of KafkaLog4jAppender.
• Applications built with Scala 2.12, or that call client APIs removed in 4.0, such as poll(long) and alterConfigs.
• Java runtimes below Java 17 on brokers, Connect workers and tool hosts, and below Java 11 on clients and Kafka Streams applications.
• Very old brokers that 4.x clients must still talk to: the client rule above requires brokers on 2.1 or higher.

A planning checklist

• [ ] Record the mode (ZooKeeper or KRaft), software version and metadata version of every cluster.
• [ ] List every client, connector, Kafka Streams application and tool, with its client library version and Java runtime.
• [ ] Choose the target 4.x line from the downloads page, and record the reason.
• [ ] For ZooKeeper clusters, confirm the 3.9 migration prerequisites on the current KRaft operations page.
• [ ] Decide the controller quorum type, size and placement before formatting the controllers.
• [ ] Rehearse the migration and the upgrade in a staging cluster, including each rollback step.
• [ ] Mark the points of no return: migration finalization and metadata version finalization.
• [ ] Update monitoring and runbooks for KRaft controllers, then plan the retirement of ZooKeeper.
• [ ] Schedule the next upgrade review, since the supported list moves with each feature release.

How Bassirah can help

Bassirah provides independent engineering for self-managed Apache Kafka, including migration assessments, rehearsed ZooKeeper-to-KRaft migrations and planned 4.x upgrades. We are not affiliated with The Apache Software Foundation or any Kafka vendor, and upstream fixes follow the project’s timeline, as our open-source support model explains. See our Apache Kafka engineering page for the scope of our work, and our platform reliability work for recovery testing.