When I wrote about KRaft being marked production ready last December, the conclusion was awkward: excellent news for new clusters, nothing you can act on if you already run one. There was no migration path, and the plan said one would come in a later 3.x release.

Kafka 3.5 shipped in June and it is that release. ZooKeeper is now formally deprecated, and the ZooKeeper-to-KRaft migration exists — as early access, which is a phrase worth taking literally.

Why the migration is hard at all

Worth restating, because it explains the design of the answer.

This is not a data migration. The topics never lived in ZooKeeper. What has to move is the cluster's metadata — topics, partitions, in-sync replica sets, configuration overrides, ACLs — from a store that a running cluster is actively reading and writing, into a completely different store, without stopping the cluster and without a window where the two disagree.

Stopping is not on the table. A Kafka cluster is usually sitting underneath everything else, so "brief downtime while we migrate metadata" means brief downtime for every service that publishes or consumes.

Dual write, and the way back

The mechanism is that the migration does not cut over. It enters a mode where both systems are written.

A KRaft controller quorum is provisioned alongside the existing cluster and put into migration mode. It takes ownership of metadata, and while the migration is in progress it writes every change to both the KRaft metadata log and to ZooKeeper. Brokers are restarted one at a time into KRaft mode. When every broker has moved and the metadata is confirmed consistent, the migration is finalised and the ZooKeeper writes stop.

The property that makes this something an operations team would actually agree to is that while dual write is active, ZooKeeper still holds a current copy of the metadata. So the migration has a way back. If something is wrong three brokers into a rolling restart, you can fall back rather than finish a cutover you have lost confidence in.

That is the design decision I find most instructive here. The hard part of migrating a live system is almost never the mechanism — it is that a one-way door forces you to be certain in advance, and nobody is certain in advance. Dual write buys back the ability to change your mind, and pays for it with a period of extra writes and a more complicated system while it lasts. It is the same trade as writing to the old and the new database at once during a cutover, and it is the reason that pattern keeps being reinvented: the extra writes are cheap, and being allowed to stop halfway is not.

What early access means here

Not production ready. The documentation says so, the release notes say so, and for a metadata migration of a system everything else depends on, that label deserves more respect than usual.

The published plan from here: the migration becomes generally available in 3.6, 3.7 is the final bridge release, and 4.0 is where ZooKeeper support is removed entirely. So the shape of the next couple of years is clear, and so is the deadline — anyone still on ZooKeeper when 4.0 lands must migrate through a 3.x bridge first, because 4.0 will not know how to talk to ZooKeeper at all.

What I would do if this were mine

Nothing yet, and then quite a lot of preparation.

The migration is early access, so running it against production this quarter is volunteering to find its bugs. But the deprecation notice is the real signal: the clock started in June, the removal is already scheduled, and a cluster that has not moved by 4.0 is a cluster that cannot upgrade.

So the work that is available now is the work that does not depend on the migration being ready. Find out whether anything in the deployment uses the features KRaft did not support — JBOD with multiple storage directories, delegation tokens. Rehearse the migration on a staging cluster with production- shaped metadata, because the interesting failures scale with partition count. Write down which tools reach into ZooKeeper directly, because there are always one or two scripts that do.

None of that is urgent and all of it is the sort of thing that becomes urgent later, at the least convenient version bump. The advantage of a project publishing a removal schedule two years out is that it is possible to be ready without hurrying — which is worth something, given how rarely deprecations come with dates at all.