A Confluent alternative that keeps you on Apache Kafka.
Exit Confluent Platform. Keep Kafka patched and supported.

Confluent Platform is Apache Kafka plus components under two further licences. Apache Kafka itself — including Connect and Streams — is Apache 2.0, as is ZooKeeper and the Confluent clients. Schema Registry, ksqlDB, REST Proxy and the community connectors are under the Confluent Community License, which is source-available rather than open source. Control Center, Tiered Storage, RBAC, Cluster Linking, Self-Balancing Clusters, Multi-Region Clusters, Replicator and the commercial connectors require an enterprise subscription. The licence boundary, not the feature list, is what determines how hard an exit is.

It is not Apache 2.0 — it is under the Confluent Community License — and this is the single most commonly missed fact in a Confluent exit. You can keep running it: the Community License permits internal use freely, and it does not stop when a subscription does. What it prohibits is offering it as a service that competes with Confluent. The practical advice is to keep Schema Registry running during a migration and treat replacing it as a separate, later project, because schema IDs are embedded in the message payloads themselves and changing that is not a cutover, it is a re-encoding.

Three. Cluster Linking, if you rely on it for multi-region topology — MirrorMaker 2 does the job but needs more operational care. Tiered Storage, if retention economics depend on it, though Apache Kafka now has its own implementation under KIP-405. And RBAC with structured audit logs, if that is what satisfies your auditor; Kafka ships ACLs, but not platform-wide role-based access control. Control Center, by contrast, is the easiest thing on the list to replace and the usual place to start.

Inventory the licence boundary first — every component, which of the three licences it falls under, and whether you actually use it. That step alone often halves the project. Then replace Control Center, which is low risk and produces immediate licence relief. Keep Schema Registry. Substitute only the enterprise components you genuinely use. Move the brokers last, and only once someone is in place to operate them. The order matters more than the tooling.

Possibly, and it is worth checking. Confluent Platform versions gate the Apache Kafka version underneath them, so a platform release you cannot upgrade pins you to a Kafka line that may no longer receive upstream fixes. The same applies to the ZooKeeper ensemble behind a pre-KRaft cluster, which in most estates is older than the brokers it coordinates. Those are patching questions independent of who you buy the platform from.

This is where most exits actually fail, rather than on the technology. Confluent is not only software; it is an operational safety net, and teams that remove it without replacing that capability discover the gap during their first partition-leader election under load. Running Apache Kafka well requires real depth in broker configuration, partition strategy, consumer-group behaviour and the upgrade path. The migration is not finished when the brokers are running — it is finished when someone owns them.

Confluent Platform adds: Confluent Schema Registry, Confluent Control Center (web UI), Confluent Replicator, RBAC via Confluent's metadata service, Tiered Storage (though community Kafka 3.6+ has this), and some connectors. Most of these have open-source equivalents: Apicurio Registry replaces Schema Registry, AKHQ or Redpanda Console replace Control Center, and MirrorMaker 2 replaces Replicator. OSSeva's exit toolkit maps each Confluent feature you use to a community option and flags the ones without a close equivalent.

OSSeva migrates Schema Registry to Apicurio Registry or keeps Confluent's community-licensed Schema Registry, both of which implement the Confluent Schema Registry API wire protocol. This means existing Kafka producers and consumers using the Schema Registry client continue to work without code changes. OSSeva validates schema compatibility and runs integration tests as part of the migration engagement.

We do not quote Confluent's prices. Contract terms vary enough that any figure we gave would be wrong for most readers. The model is public: Confluent Cloud is usage-based, metered on capacity units, data in and out, and storage, while Confluent Platform's enterprise features need a paid subscription agreed with Confluent sales. OSSeva is priced per cluster, and Apache Kafka itself is Apache 2.0 with no licence cost. Send us your current quote and we will match the equivalent coverage against it.

Only if you want to run Kafka yourself. OSSeva does not offer a hosted Kafka service, so leaving Confluent Cloud with us means moving to self-managed Apache Kafka in your own data centre, cloud account or Kubernetes, with OSSeva Operate running it. If you want to stay fully managed, Confluent Cloud or a cloud provider's managed Kafka is the better fit.