// ZooKeeper to KRaft migration
ZooKeeper to KRaft migration, done for you.
Patched ZooKeeper keeps the cluster covered until the cutover is final.
Kafka 4.0 removed ZooKeeper mode, so a ZooKeeper-mode cluster has to migrate to KRaft on a 3.x release before it can upgrade. OSSeva runs that migration for you, cluster by cluster, and ships patched ZooKeeper builds as the bridge: the brokers and the ensemble stay covered while each cluster waits for its change window and until the controllers are finalized. The same service moves ClickHouse to Keeper, Patroni to etcd and Pulsar to Oxia, and keeps ZooKeeper patched for Solr, HBase and Hadoop, which cannot leave it yet.
Trusted globally by enterprises
Why a KRaft migration needs a bridge
The Kafka move is the common one, and it is not a single change. Other products leave ZooKeeper on their own schedules, and some cannot leave yet.
Kafka: migrate on 3.x, one change window at a time
Kafka 4.0 removed ZooKeeper mode entirely, so ZooKeeper clusters must migrate to KRaft before upgrading, and the community guidance is to do it on 3.9, the final ZooKeeper-capable line. The final step cannot be undone, so each cluster needs its own rehearsal and change window. The clusters waiting their turn still run brokers and a ZooKeeper ensemble that nobody upstream patches. That gap is what the patched bridge covers.
Ready to move: ClickHouse, Patroni
ClickHouse recommends ClickHouse Keeper, which speaks the ZooKeeper protocol on top of Raft. Patroni supports etcd, Consul and Kubernetes as well as ZooKeeper.
Moving: Pulsar
Pulsar has offered Oxia as a metadata store since 3.3.0. Pulsar 5.0, released on 5 October 2026, makes Oxia the recommended store and adds live ZooKeeper to Oxia migration (PIP-454), while ZooKeeper remains fully supported.
Not yet: Solr, HBase, Hadoop
Solr 10 still requires ZooKeeper, now through Apache Curator. HBase 3.0 still needs it on the server side, and the work to remove it from client connections is open against HBase 4.0. HDFS and YARN high availability in Hadoop 3.5 still elect leaders through ZooKeeper. These stay on a patched ensemble.
The dates that matter
2014
The Raft paper, In Search of an Understandable Consensus Algorithm, wins Best Paper at USENIX ATC.
2021-12
ClickHouse 21.12 declares clickhouse-keeper feature complete.
2023-01-30
Patroni 3.0.0 deprecates its built-in Raft option in favour of an external DCS.
2025-03-18
Kafka 4.0 removes ZooKeeper mode. KRaft only.
2026-02-21
Kafka 3.9.2, the final release of the last ZooKeeper-capable line.
2026-03-03
Solr 10.0.0 released. It still requires ZooKeeper.
2026-06-23
Pulsar 5.0.0-M1 preview recommends Oxia and adds live migration from ZooKeeper.
2026-08-05
HBase 3.0.0 released. The server side still requires ZooKeeper.
2026-10-05
Pulsar 5.0.0 LTS released, with Oxia as the recommended metadata store.
What OSSeva delivers
The migration, run for you
Kafka ZooKeeper mode to KRaft before the 4.x upgrade, with each cluster rehearsed and a tested rollback until the controllers are finalized. The same team moves ClickHouse to ClickHouse Keeper with clickhouse-keeper-converter, Patroni to etcd v3, and Pulsar to Oxia on 5.0.
Patched ZooKeeper bridge
Patched builds of ZooKeeper 3.4, 3.5, 3.6 and 3.7 and support for 3.8 and 3.9 keep the ensemble covered until the last client has moved, with third-party CVE attestation, including VEX. The same builds cover the Solr, HBase and Hadoop clusters that cannot leave ZooKeeper yet.
A map of every ensemble
We find every ZooKeeper in your estate, bundled or standalone, and every product that talks to it, so you know which ensembles can be retired and which have to stay. 24/7 operations for the ensembles and their replacements are available.
Your options, compared
| Option | What you get | Trade-off |
|---|---|---|
| Migrate everything at once | A ZooKeeper-free estate on paper | Not possible today. Solr, HBase and Hadoop still require ZooKeeper, and each Kafka cluster needs its own change window. |
| Do it yourself, in waves | Full control, using the community runbook | The clusters waiting their turn stay unpatched in Kafka and ZooKeeper. |
| Keep ZooKeeper, upgrade to 3.9 | A community-supported line | Each product's bundled client and Curator version has to be compatible first. |
| OSSeva migration and patched bridge | The KRaft migration run for you, with patched Kafka and ZooKeeper until each cluster is done | A subscription covering both for as long as ZooKeeper remains. |
Raft description from raft.github.io. Kafka dates from the Kafka 4.0 announcement, upgrade notes and downloads page. ClickHouse Keeper facts from the ClickHouse documentation and 2021 changelog. Pulsar facts from the 3.3.0, 5.0.0-M1 and 5.0.0 release notes. Solr, HBase and Hadoop facts from each project's news, downloads and documentation pages. Patroni facts from the Patroni release notes.
Frequently asked questions
What does a done-for-you ZooKeeper to KRaft migration include?
OSSeva inventories the clusters and the clients that talk to them, rehearses the migration on each cluster, runs it in the change window you choose, and keeps the brokers and the ZooKeeper ensemble patched until the controllers are finalized. Each cluster has a tested rollback until that final step, which cannot be undone.
Do we have to keep ZooKeeper running during the migration?
Yes. The migration is online, and ZooKeeper stays authoritative until the controllers leave migration mode. That is why the patched ZooKeeper bridge matters: the ensemble needs fixes for as long as it runs, including on clusters still waiting for their window.
ZooKeeper vs etcd: what is the difference?
Both are replicated, strongly consistent coordination stores. ZooKeeper is a Java service that uses its own ZAB protocol and a hierarchical znode tree. etcd is a Go service that uses Raft and a flat key-value space with a gRPC API. Neither is a drop-in replacement for the other, so the choice depends on what the product above supports.
Is there a ZooKeeper alternative for every product?
No. Kafka has KRaft, ClickHouse has Keeper, Patroni supports etcd and Consul, and Pulsar is moving to Oxia. Solr 10, HBase 3.0 and Hadoop 3.5 still require ZooKeeper, so those clusters stay on a patched ensemble.
Does Kafka 3.9 need to move to KRaft?
Before it can go to Kafka 4.0, yes. Kafka 4.0 removed ZooKeeper mode, and ZooKeeper-mode clusters must migrate to KRaft first. Kafka 3.9.2, released in February 2026, is the final release of the last ZooKeeper-capable line.
What happens to a shared ZooKeeper ensemble?
It stays until its last client moves. If Kafka and HBase share an ensemble, moving Kafka to KRaft does not retire it. OSSeva patches the ensemble for as long as any product still depends on it.
Let us run the KRaft migration. Keep ZooKeeper patched until it is done.
Book a discovery call and we will map every ZooKeeper in your estate, what depends on it, and which clusters can move first.