KRaft mode migration finalization in Kafka 3.x: irreversible cutover readiness

Migrating Apache Kafka 3.x clusters from ZooKeeper to KRaft mode involves a documented multi-phase process, but the finalization step is irreversible and lacks concrete readiness signals. Once finalized, rollback to ZooKeeper is unsupported, and backups of the prior metadata backend do not provide a recovery path. Operators must therefore determine when a cluster has achieved sufficient stability under KRaft control, a decision currently left to individual judgment rather than prescribed thresholds. This gap is compounded by version-sensitive deprecation timelines and potential breakage in third-party tooling that assumes a ZooKeeper connection string. The result is a practical uncertainty point in the migration lifecycle where the cost of premature finalization outweighs the benefits of ZooKeeper removal.

Which concrete migration metrics or controller quorum states serve as sufficient evidence that a cluster is safe to finalize? How long do operating teams typically sustain the dual-write phase before committing to finalization, and which failure modes should postpone the cutover? What validation steps should precede finalization to ensure third-party tooling compatibility without a ZooKeeper dependency?