Kafka 4.0 Removes ZooKeeper: KRaft Migration Guide for 2026

Apache Kafka 4.0, released March 18, 2025, completely removed ZooKeeper support—not deprecated, REMOVED. If you’re still running ZooKeeper mode, you can’t upgrade directly to 4.0. The required path? Migrate to KRaft mode in Kafka 3.7-3.9 first, then upgrade. It’s May 2026, and thousands of production deployments are hitting the migration cliff. ZooKeeper support officially ended six months ago.

The Migration Cliff: You Can’t Skip to Kafka 4.0

Kafka 4.0 doesn’t support ZooKeeper mode at all. There’s no direct upgrade path from ZooKeeper-based clusters to 4.0. The required path: move from ZooKeeper mode (Kafka 3.x) to KRaft mode in version 3.7-3.9, then upgrade to 4.0. Kafka 3.9 is the recommended “bridge version”—it’s the last release supporting ZooKeeper with the best migration tooling.

If you’re running Kafka 2.x, the path is longer: upgrade to 3.7+, migrate to KRaft, then move to 4.0. According to the Apache Kafka 4.0 upgrade documentation, “From version 4.0 of Kafka, clusters will not support ZooKeeper anymore.” The Kafka 3.9 release notes confirm it’s the final version to support ZooKeeper mode.

Why the Migration Effort Pays Off

The operational benefits of KRaft are real and quantified. A fintech engineering team cut cluster setup time by 40% after eliminating ZooKeeper. A SaaS provider reduced infrastructure costs by 20% by retiring dedicated ZooKeeper nodes. OSO engineers tested KRaft in production and reported 8x performance improvements with the ability to scale to millions of partitions.

KRaft delivers near-instantaneous controller failover compared to ZooKeeper’s slower failover times. The architecture removes an external dependency, simplifies deployment, and eliminates a metadata bottleneck. Aiven proved the migration works at scale: they migrated 15,000 servers from ZooKeeper to KRaft in three months with zero downtime—11,000 servers via automated tooling, 4,000 via user opt-in. The OSO analysis of KRaft highlights the performance gains that make the migration worthwhile.

Migration Tooling is Production-Ready

The ZooKeeper-to-KRaft migration tooling matured quickly. Introduced in Kafka 3.6, designated production-ready in 3.7, and refined to its best iteration in 3.9. The process supports rolling restarts for zero-downtime migration.

The migration path: upgrade to Kafka 3.7+, enable the KRaft quorum alongside ZooKeeper, perform a rolling restart of brokers, and let metadata migration start automatically. During the dual-write phase, Kafka writes to both KRaft and ZooKeeper as a safety net. You can roll back until finalization, but after that, there’s no turning back. The Confluent KRaft guide and Strimzi migration documentation provide detailed walkthroughs.

What Developers Should Do Right Now

Don’t wait for 4.0 upgrade pressure to force the migration. Check your Kafka version:

kafka-broker-api-versions.sh --bootstrap-server localhost:9092 --version

Your decision path depends on your current setup. On Kafka 3.x with ZooKeeper? Plan migration now using Kafka 3.9 as the bridge. On 3.x with KRaft? Upgrade to 4.0 when ready. On 2.x? Upgrade to 3.7+ first, migrate to KRaft, then move to 4.0.

Before migrating production, test in lower environments. Inventory client applications using ZooKeeper APIs and update them. Create a migration runbook specific to your infrastructure. Train operations teams on KRaft troubleshooting. Budget realistic timelines: testing takes 2-4 weeks, production migration 1-3 months depending on scale. The Instaclustr analysis of Kafka 4.0 emphasizes phased rollout.

Kafka 4.0 Delivers More Than ZooKeeper Removal

ZooKeeper removal is the headline, but Kafka 4.0 includes worthwhile features beyond the migration requirement. The new consumer rebalance protocol (KIP-848) reached general availability, dramatically improving rebalance performance through incremental partition assignment instead of full revoke-and-rebalance cycles. This reduces downtime and latency for large consumer groups.

Kafka 4.0 introduces early access to Queues for Kafka (KIP-932), bringing traditional queue semantics directly into Kafka for point-to-point messaging. Enhanced observability arrived with client metrics collected from brokers and KRaft-specific metrics like ActiveControllersCount providing better cluster health visibility.

Breaking changes include Java 17 required for brokers, Connect, and tools, with Java 11 required for clients and Streams. Kafka 4.0 clients require brokers 2.1+ and drop support for message formats v0 and v1. The Confluent announcement of Kafka 4.0 details the full feature set.

The Infrastructure Simplification Trend

This migration fits a broader pattern: infrastructure simplification by removing legacy dependencies. ZooKeeper was a coordination bottleneck that added operational complexity and limited Kafka’s scalability. KRaft consolidates metadata management within Kafka itself, reducing external dependencies and improving performance—the same pattern seen with Kubernetes replacing custom orchestration.

The migration is mandatory and inconvenient, but the long-term payoff is clear: faster operations, lower costs, better scalability, and a foundation for future Kafka innovations. If you’re still on ZooKeeper in May 2026, the question isn’t whether to migrate—it’s how quickly you can execute the move before technical debt turns into an operational crisis.