## 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
```text
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.

2. 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.

3. 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.

4. 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.

5. 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/pst_n3xf_aM-iBZmTCwoeqaTPg