kafka kraft vs zookeeper migration

TL;DR

KRaft removes ZooKeeper entirely, which cuts a whole operational dependency and its failure modes. Migration runs through the supported ZooKeeper-to-KRaft path in modern Kafka versions: upgrade brokers first, migrate metadata, then decommission ZooKeeper. Size the controller quorum as an odd number (3 or 5) and test the rollback plan before you start.

The query

kafka kraft vs zookeeper migration

Use this when

• you are planning a ZooKeeper to KRaft migration
• ZooKeeper outages or scaling pain are hurting the cluster
• you are sizing controllers for a new KRaft cluster

Not for

• Kafka client, producer, or consumer configuration
• topic data migration between clusters, which is a separate tool (MirrorMaker)

Steps

1. Confirm your Kafka version supports the migration path and that all brokers are on a compatible version first.

Expected output: Every broker reports a version that supports KRaft migration.

1. Size the controller quorum: 3 for most clusters, 5 for very large ones. Always an odd number.

Expected output: You have a controller count that survives a single node loss.

1. Run the migration in staging with production-like load and practice the rollback before touching production.

Expected output: Staging migrated cleanly and the rollback steps are tested.

1. Migrate metadata during a low-traffic window and watch controller logs for election and quorum health.

Expected output: The metadata migration completes with a healthy quorum.

1. Decommission ZooKeeper only after the cluster has run stably on KRaft and backups of the metadata exist.

Expected output: ZooKeeper is gone and the cluster runs on KRaft alone.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstn3xfaM-iBZmTCwoeqaTPg