01
Version and Mode Inventory
Kafka version, ZooKeeper or KRaft mode, metadata version, inter-broker protocol and the Connect workers, Streams applications and tools that share the cluster.
Kafka Upgrades
Kafka upgrades and KRaft migration
Last reviewed by Scott Sternloff
Apache Kafka 4.0 removed ZooKeeper, so every ZooKeeper-based cluster has to migrate to KRaft before it can reach a supported release. AceMQ plans and runs that migration and the move to Kafka 4.x: the bridge release, the controller quorum, the client and Java changes, a downtime model and a rollback point at every step before finalization.
- last release that can bridge ZooKeeper to KRaft
- 3.9
- Java version Kafka 4.0 brokers require
- 17
- min emergency SLA on the support plan
- 15
Trusted for Mission-Critical Kafka by Teams in Finance, Healthcare, Defense, Telecom, and More
Customers
Partners
Is This You?
You probably need this if…
- 01
You run ZooKeeper-based Kafka on 3.x and the move to 4.x has not been scoped
- 02
Your cluster is on a release line the Apache project no longer fixes, and nobody owns the CVE question
- 03
You need a KRaft migration plan with a rollback story before a change board will approve it
- 04
Client libraries and Connect workers are on versions nobody has inventoried
- 05
A past upgrade caused an incident and the team is wary of the next one
- 06
Your platform team is small and a migration window competes with product work
- 07
You want an engineer who has done the migration to review the plan, not to write a generic one
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your Kafka estate when the engagement closes.
Before
The team knows ZooKeeper has to go but not in what order, or what breaks on the way.
After
A written path from the current version to Kafka 4.x, with every step, its rollback point and its owner.
Before
Client and Java compatibility is discovered in production.
After
A client and runtime inventory checked against the Kafka 4.0 requirements before the first broker restarts.
Before
The upgrade is a single weekend change with no way back.
After
Rehearsed on a copy, run as rolling restarts, with a clear boundary after which rollback is no longer possible.
Before
Nobody can say who patches Kafka CVEs once a version leaves community support.
After
A support contract that covers the version you run today and the one you are moving to.
Scope
What's covered
- 02
Client Compatibility Audit
Kafka 4.0 needs clients, including Streams and Connect, on version 2.1 or higher. We list every client library and runtime, and the applications that need a change first.
- 03
Bridge Release
Brokers upgraded to Kafka 3.9.1 with inter.broker.protocol.version set to 3.9, the prerequisite the Apache documentation gives for the ZooKeeper to KRaft migration.
- 04
Controller Quorum Design
Controller count and placement, dedicated or combined roles, disk for the metadata log, and the cluster ID and node IDs the migration depends on.
- 05
Migration Run
Quorum provisioned, brokers put into migration mode with rolling restarts, brokers moved to KRaft, then finalization. Logs checked at each phase.
- 06
Authorizer and Security
ACLs on the legacy AclAuthorizer move to the StandardAuthorizer, with TLS and SASL settings carried across and tested.
- 07
Upgrade to Kafka 4.x
Rolling broker upgrade, feature finalization and client upgrades in the order the Apache documentation sets, with Java 17 for brokers, Connect and tools.
- 08
Rollback and Downtime Model
A per-step rollback plan until finalization, and a plain statement of what happens to producers and consumers during each rolling restart.
- 09
Monitoring and Runbooks
ZooKeeper-based dashboards and alerts replaced with controller and metadata-log monitoring, and runbooks rewritten for the KRaft topology.
The Engagement
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
- Phase 11-4 weeks, by scope
Assessment
Inventory, client audit and a written path. This is the Kafka health check applied to the upgrade question. Delivery is remote and read-only, guided by your engineers. We take no access to your environment or code.
You receive
- Version, mode and client inventory
- Blocking items against Kafka 4.0
- Upgrade path with order of operations
- Phase 2Scoped per estate
Rehearsal
The migration and upgrade are run on a non-production cluster that mirrors yours, including the rollback at each step, so the production window holds no first attempts.
You receive
- Rehearsed runbook
- Measured restart times
- Known issues checked against your configuration
- Phase 3Planned change window
Migration
Bridge release, controller quorum, migration mode, broker migration and finalization, run as rolling restarts. Platform migration and version upgrade are separate changes, never one window.
You receive
- Cluster in KRaft mode
- ZooKeeper decommissioned
- Post-change verification report
- Phase 4Planned change window
Upgrade and Handover
Rolling upgrade to the chosen Kafka 4.x line, client upgrades in order, then runbooks and monitoring handed to your team or to AceMQ support.
You receive
- Cluster on Kafka 4.x
- Updated runbooks and dashboards
- Support onboarding
Kafka ZooKeeper to KRaft migration: the path to Kafka 4
Apache Kafka 4.0 supports KRaft mode only. The Apache documentation says clusters in ZooKeeper mode have to be migrated to KRaft before they can be upgraded to 4.0.x, and names 3.9 as the last bridge release. Where you start decides the path.
| Starting point | Path | Note |
|---|---|---|
| ZooKeeper mode, Kafka 3.x | Upgrade brokers to 3.9.1, migrate to KRaft, then upgrade to 4.x | The migration needs inter.broker.protocol.version set to 3.9 and a KRaft quorum with the cluster's existing ID |
| ZooKeeper mode, older than 3.x | Step up to a 3.x release, then follow the row above | Clients must be on 2.1 or higher before the 4.0 broker upgrade; we plan the steps from your exact version |
| KRaft mode, 3.3.x or later | Rolling upgrade straight to 4.x | Software and metadata versions must be at least 3.3.x |
| KRaft mode, older than 3.3.x | Upgrade to 3.9.x first, then 4.0.x | The Apache documentation's own recommendation |
The migration phases are explained step by step in our Kafka migration guide
To find out which of these rows you are in, start with a Kafka health check and KRaft readiness assessment
KRaft migration steps and where rollback stops
The migration moves through five states, and the Apache documentation is explicit about the boundary: rollback to ZooKeeper is possible until the migration is finalized, and after finalization it is not.
| Phase | State of the cluster | Can you return to ZooKeeper? |
|---|---|---|
| 1. Initial | All brokers in ZooKeeper mode with a ZooKeeper controller | Yes, nothing has changed |
| 2. Initial metadata load | A KRaft quorum has loaded the metadata from ZooKeeper | Yes, by deprovisioning the quorum |
| 3. Hybrid | Brokers restarted into migration mode, KRaft controller in charge | Yes, with extra steps to clear the controller state in ZooKeeper |
| 4. Dual-write | All brokers in KRaft mode, the controller still writes to ZooKeeper | Yes, with an additional rolling restart |
| 5. Finalized | Metadata no longer written to ZooKeeper | No |
Brokers restart in a rolling fashion, which the documentation describes as avoiding an impact on cluster availability. Known limitations in the same page are the reason for a rehearsal: a broker with several log directories shuts down if any of them fails during migration, KRaft node IDs must differ from existing ZooKeeper broker IDs, and the migration can stall if the ZooKeeper Security Migration Tool ran earlier. We check each against your configuration before the window.
Rule we hold
Never combine a platform migration with a version upgrade in the same production window. The KRaft migration, the Kafka 4.x upgrade and any client changes are three separate changes, each with its own rollback.
Kafka 4 upgrade: client and Java compatibility
| Component | Requirement | What we check |
|---|---|---|
| Brokers, Connect, tools | Java 17 | JVM version on every host and container image |
| Clients and Kafka Streams | Java 11 minimum | Application runtimes that are still on Java 8 |
| Client libraries | Version 2.1 or higher, including Streams and Connect, before upgrading to 4.0 | Libraries per application and per Connect worker |
| Non-Apache clients | Covered by KIP-896, which removes old protocol versions | Language clients and their negotiated API versions |
| Metadata and software | At least 3.3.x on a KRaft cluster before the 4.0 upgrade | Current metadata version and feature levels |
| Downgrade | Cluster metadata downgrade is not supported in this version | A rollback plan that does not depend on one |
One further note from the same documentation: once consumer groups use the new rebalance protocol (KIP-848), the cluster can only be downgraded to 3.4.1 or newer, so the decision to switch groups over belongs in the plan, not in a settings change after the upgrade.
Is there a Kafka LTS, and who patches the CVEs?
Apache Kafka has no long-term support line. The project aims for three releases a year and, per its downloads page, makes bugfix releases "as needed for supported releases only." On 26 October 2026 the supported lines are 4.4 (4.4.0 released 22 October 2026), 4.3 and 4.2. Kafka 3.9.2, released on 21 February 2026, sits under archived releases.
That is the CVE gap for ZooKeeper-based clusters: the migration is the route to a line that receives fixes. For the time it takes, AceMQ covers the version you run with 24/7 support, and CVE fixes for Kafka 2.8 to 3.7 are backported through OSSeva, our extended support platform. Other end-of-life lines get support and upgrade planning rather than patched builds.
The supported-version picture in more detail: Apache Kafka end of life
For production-readiness questions about Kafka 4, read Kafka 4 KRaft production readiness
Price and engagement model
AceMQ prices upgrade work as a scoped engagement, not per hour or per broker, and publishes no rate. The drivers are the number of clusters and environments, brokers and Connect workers, how many client applications must change, how much rehearsal you want, and whether the cluster moves onto a support or managed plan afterwards.
Once the cluster is on Kafka 4.x, ongoing cover is 24/7 Kafka support
If you would rather hand upgrades and the pager to us, see managed Kafka services
Where this service is not a fit
- Hosted Kafka — On Amazon MSK or Confluent Cloud the provider chooses and performs broker upgrades. We review your clients, Connect workers and topic design instead.
- Application code — We tell you which client settings and library versions to change. Your developers make the change.
- No downtime guarantee — Rolling restarts are designed to keep the cluster available, and a client-side failure during a restart is still possible. The plan states the exposure for each step.
- Remote delivery — We work from your exports and a screen share, guided by your engineers, and do not log in to your environment.
Customer Success
Real Kafka Results
See how enterprises trust AceMQ for their most critical Kafka workloads.
Producer Timeouts Traced to Controller-Leader Overload
European Hosting Provider
A five-node Kafka cluster serving 60,000 customers was timing out producers under load. The cause was topology, not capacity.
Apache Kafka
Docker
LinuxRecovering Transaction Throughput After a Kafka Rollout
Banking Transaction Platform
Throughput fell from 320,000 to roughly 45,000 transactions per hour after Kafka was introduced. The platform needed 80,000 to prove it could scale.
Apache KafkaKRaftJMeter
Real-Time Manufacturing Data Ingestion Modernization
Global Automotive Manufacturer
Replacing fragile SQL-trigger-based ingestion with a reliable event-driven architecture for plant-floor data movement and low-latency operations.
RabbitMQMQTTKafkaSQL Server
KubernetesMiddleware Architecture Assessment for Financial Trading
European Online Trading Platform
Independent architecture and performance review of RabbitMQ, Kafka, and Redis for an online trading platform.
RabbitMQKafka
RedisReplacing Kafka with Debezium + RabbitMQ for Change Data Capture
American National Insurance
American National Insurance replaced a Kafka-based CDC pipeline with a standalone Debezium + RabbitMQ architecture, simplifying operations while maintaining SQL Server change capture with improved message routing flexibility.
KafkaRabbitMQDebeziumKubernetesKafka CVE Patching and Compliance Strategy for Global Enterprise
Global Technology Enterprise
AceMQ developed a multi-technology compliance strategy covering CVE patching for Kafka alongside RabbitMQ and IBM MQ deployments, creating a unified vulnerability management approach across the entire enterprise messaging stack.
KafkaRabbitMQ
IBM MQHigh-Throughput Kafka and RabbitMQ Support for Global Payments
PagoNXT (Financial Technology)
AceMQ provided ongoing support for PagoNXT's high-throughput payments infrastructure running Kafka and RabbitMQ at 2,500 transactions per second, including load testing validation and architecture optimization.
KafkaRabbitMQKafka Architecture Assessment and Migration Advisory
Enterprise Organizations
AceMQ's Kafka assessment service evaluates streaming architecture health, identifies operational risks, and provides a structured migration or modernization roadmap for enterprises running or evaluating Kafka.
Kafka
FAQ
Questions about Kafka upgrades
Do I have to migrate to KRaft?
To run Apache Kafka 4.0 or later, yes. Kafka 4.0 supports KRaft mode only, and the Apache documentation says ZooKeeper-mode clusters must be migrated to KRaft before they can be upgraded to 4.0.x. Staying on ZooKeeper means staying on a 3.x line, and the last one, Kafka 3.9.2 released on 21 February 2026, is listed by the Apache project as an archived release.
Can I upgrade Kafka without downtime?
Both the KRaft migration and the Kafka 4.x upgrade are designed as rolling restarts, one broker at a time, so the cluster can stay available. Applications still see leadership changes during each restart, so clients need sound retry and reconnect settings. The plan states the exposure for each step, and a rehearsal measures it first.
How long is Kafka 3.9 supported?
The Apache project no longer lists 3.9 as a supported release: the latest 3.9 release, 3.9.2, came out on 21 February 2026 and is archived. Kafka 3.9 remains the last bridge release for the ZooKeeper to KRaft migration. AceMQ supports Kafka 3.8 and 3.9 clusters 24/7 and plans their migration to KRaft.
Who patches Kafka CVEs?
The Apache project fixes supported release lines only. For older lines AceMQ provides 24/7 support and upgrade planning for every version, and CVE fixes for Kafka 2.8 to 3.7 are backported through OSSeva. The durable answer for a ZooKeeper cluster is the migration to a supported 4.x line.
Can the KRaft migration be rolled back?
Yes, until it is finalized. The Apache documentation sets out the rollback steps for each phase, and says that after finalization it is not possible to return to ZooKeeper mode. That is why we rehearse first and keep the Kafka 4.x upgrade out of the same window.
Let's talk
Scope Your Kafka Upgrade
Tell us your Kafka version, whether the cluster runs ZooKeeper or KRaft, and how many clusters you have. We will scope the work and reply within 1 hour and follow with a timeline and a written quote.
Get in Touch
Talk to a Kafka Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.