Confluent Platform 7.x End of Support: What the 7.8 and 7.9 Dates Mean for ZooKeeper Clusters

The short answer

Confluent Platform 7.8 reaches end of standard support on 2 December 2026, and Confluent Platform 7.9 on 19 February 2027. Customers on Confluent's Platinum support tier get one more year on each: 2 December 2027 for 7.8 and 19 February 2028 for 7.9. After those dates Confluent no longer ships fixes for the line.

Those two dates matter more than a routine end of support because Confluent Platform 7.x is the last major line that runs Apache Kafka with ZooKeeper. Confluent Platform 8 is built on Kafka 4.x, which runs only in KRaft mode. A ZooKeeper-based Confluent deployment therefore has to migrate its metadata to KRaft before it can move to a supported release.

Which Confluent Platform versions are currently supported?

Confluent publishes its support dates in the Versions and Interoperability section of the Confluent Platform documentation. Each minor release carries its own end-of-support date, and the two lines that matter for ZooKeeper-based clusters are these:

Both lines follow the same pattern: two years of standard support from release, and a third year for Platinum customers. Earlier 7.x lines followed the same calendar and have already ended. Always check the live table for your exact minor version, because the date belongs to the minor release, not to 7.x as a whole.

Why Confluent Platform 7.x is the ZooKeeper line

Apache Kafka 4.0, released on 18 March 2025, removed ZooKeeper entirely. It runs only in KRaft mode, where a quorum of Kafka controller nodes stores the cluster metadata in a Raft log. Kafka 3.9 was the final release that could run with ZooKeeper, and it is the bridge release for moving from ZooKeeper to KRaft.

Confluent Platform versions track the Apache Kafka core underneath them: 7.8 ships Kafka 3.8 and 7.9 ships Kafka 3.9. Everything newer is built on Kafka 4.x. So the question for a Confluent customer is not simply "when does my version go out of support?" It is "when will each of my clusters be on KRaft?"

The Kafka community's guidance, which Confluent's own migration documentation follows, is to migrate from ZooKeeper to KRaft on a 3.x release and only then upgrade to 4.x. There is no route that upgrades a ZooKeeper cluster straight to a KRaft-only release.

How Confluent's support policies work

Confluent's support policies attach a date to every minor release of Confluent Platform rather than to the major version. Each release of Confluent Platform bundles a specific Apache Kafka version together with Kafka Connect, Kafka Streams, Schema Registry, ksqlDB, REST Proxy and Confluent Control Center, and the whole bundle reaches end of life together. Minor upgrades inside 7.x are rolling upgrades of the Kafka cluster and its components; the jump to 8.x is where the ZooKeeper to KRaft change forces a migration first.

Confluent Cloud is outside this calendar. It is Confluent's managed service, runs KRaft-based Kafka, and upgrades itself, which makes it an option for teams willing to move their clusters rather than upgrade them.

What stops at end of support

• Patch releases. No further maintenance releases for the Confluent Platform line, including its Kafka brokers, Connect, Schema Registry, ksqlDB, REST Proxy and Control Center components.
• Security fixes. New advisories against the line are not fixed on it. Confluent directs customers to a supported release instead.
• Support cases. Confluent support engineers handle issues on supported versions. Cases on an unsupported version generally start with an upgrade.
• Confluent for Kubernetes compatibility. Operator releases are tested against supported Confluent Platform versions, so the platform and the operator age out together.

The risks of running Confluent Platform after end of support

The broker usually is not the first thing to break. The exposure builds in three places:

• The Kafka core. Apache Kafka continues to publish advisories. Kafka CVEs such as CVE-2026-35554, a producer race condition that can send records to the wrong topic, are fixed on current 3.9 and 4.x patch releases, not on older lines.
• ZooKeeper. The ensemble behind a Confluent 7.x cluster has its own releases and its own advisories, and it is often older than the brokers.
• The components around Kafka. Schema Registry, Connect and Control Center carry large dependency trees. Transitive library CVEs are the most common finding in audits of older Confluent deployments.

For regulated estates the audit finding arrives before any exploit. PCI DSS 4.0 requirement 6.3.3 and SOC 2 CC7.1 both ask for evidence that system components receive security fixes, and "the vendor stopped supporting this version" is not that evidence.

Your options for ZooKeeper-based clusters

1. Migrate to KRaft on 7.9, then upgrade to Confluent Platform 8

This is the path Confluent and the Kafka community intend. Upgrade to 7.9 while still on ZooKeeper, add a KRaft controller quorum, run the migration, finalize it, then take the platform upgrade. The technical steps for one cluster take days. The finalize step cannot be rolled back, which is why fleets move one change window at a time. Our ZooKeeper to KRaft migration runbook walks through each phase.

2. Buy another year with Platinum support

Platinum support extends each line by a year: 7.9 to February 2028. It is the simplest option for Confluent customers already committed to the platform, and it is priced as a Confluent subscription tier, so it raises the cost of standing still.

3. Move to community Apache Kafka

Much of Confluent Platform is Apache Kafka, and Kafka, Connect and Streams are Apache 2.0 licensed. Schema Registry, ksqlDB and REST Proxy are under the Confluent Community License, and Control Center is commercial. Teams that mostly use the Apache components can run community Kafka and replace or retain the rest deliberately. The Apache Kafka vs Confluent licence map shows where the boundary sits, and leaving Confluent covers the migration.

4. Move to Confluent Cloud

For teams that want to stay with Confluent but stop running the platform, Confluent Cloud removes the upgrade problem by removing the self-managed cluster. It is a migration of data and clients to a new Kafka cluster rather than an in-place upgrade, and it changes the cost model from subscription to consumption.

5. Third-party extended support for Kafka 3.x and ZooKeeper

For clusters that cannot move on Confluent's calendar, extended support keeps the Apache Kafka core and ZooKeeper patched while the KRaft migration waits its turn. OSSeva provides extended support for Kafka 3.x on ZooKeeper, covering the brokers and the ensemble, with help running the migration when each cluster is ready.

How to plan the next five months

1. Inventory every cluster with its Confluent Platform version, Kafka version, ZooKeeper version and whether it already runs in KRaft mode.
2. Record the end-of-support date for each minor release, including the Platinum date if you hold that tier.
3. Find the clients that will break on Kafka 4.x. Kafka 4.0 removes old client protocol versions, so clients older than 2.1 stop working after the final upgrade.
4. Order the clusters by risk and effort: internet-facing and regulated clusters first, large and quiet clusters last.
5. Decide per cluster between migrating before the date, extending with Platinum, moving to community Kafka, or third-party support for the gap.

Frequently asked questions

What is the end-of-support date for Confluent Platform 7?

It depends on the minor release. Confluent Platform 7.8 standard support ends on 2 December 2026 and 7.9 on 19 February 2027. Platinum support adds one year to each.

Does Confluent Platform 8 support ZooKeeper?

No. Confluent Platform 8 is built on Apache Kafka 4.x, which runs only in KRaft mode. ZooKeeper-based clusters must migrate to KRaft on 7.x first.

How can I calculate the end-of-support date for my Confluent Platform version?

Look up your exact minor version in the Confluent Platform Versions and Interoperability documentation. For 7.8 and 7.9, standard support ends two years after the release date and Platinum support a year later.

What happens if we keep running Confluent Platform 7.x after end of support?

The software keeps running, but new security fixes are not produced for your line, Confluent support will direct cases towards an upgrade, and audits will record an unsupported component.