ZooKeeper to KRaft: pick your path, keep a way back

Which ZooKeeper to KRaft path applies to you​

A ZooKeeper to KRaft migration is not one procedure. Self-managed clusters migrate in place with the KIP-866 dual-write flow through the Kafka 3.9 bridge release. Strimzi runs that same flow from a single annotation. Amazon MSK has no in-place path at all — there, the migration becomes a cluster move.

The deadline is fixed upstream: ZooKeeper mode was deprecated in Kafka 3.5 and removed in 4.0. A 4.x broker will not start against ZooKeeper.

Each in-place procedure is covered step by step in the complete ZooKeeper to KRaft migration guide. Still deciding whether to move at all? The KRaft vs ZooKeeper comparison settles that first.

Back up before you touch cluster metadata​

Every path above rewrites the cluster's metadata layer while production traffic keeps flowing. The migration procedures protect metadata — they do nothing for the data in your topics if a step goes wrong mid-flight. A point-in-time backup with offset headers is the safety net that works on every platform, because it depends only on the Kafka protocol, not on ZooKeeper or KRaft.

mode: backup
backup_id: "pre-kraft-migration"

source:
bootstrap_servers:
  - broker-1.prod.kafka:9092
  - broker-2.prod.kafka:9092
topics:
  include:
    - "*"
  exclude:
    - "__consumer_offsets"

storage:
backend: s3
bucket: my-kafka-backups
region: us-west-2
prefix: backups/pre-migration

backup:
compression: zstd
include_offset_headers: true   # Required to reset consumer groups later
source_cluster_id: "prod-zk-cluster"

kafka-backup backup --config backup.yaml

kafka-backup list --path s3://my-kafka-backups/backups/pre-migration \
--backup-id pre-kraft-migration

A backup taken on the ZooKeeper cluster restores to a KRaft cluster without changes — the storage format is independent of the metadata mode. That gives you a second migration route too: restore into a fresh KRaft cluster with consumer_group_strategy: header-based and consumers resume from equivalent positions. The migration use case shows that backup-and-restore pattern, and every key above is documented in the configuration reference.

After the switch​

Keep the backup schedule running against the KRaft cluster from day one — the metadata mode changed, the durability question did not. If the migration also retires the old cluster, hold the pre-migration backup until your retention policy clears it: it is the only copy of the cluster's state from before the one-way door.