Exiting Confluent Platform: An Enterprise Migration Playbook to Apache Kafka

Why Enterprises Are Leaving Confluent

Confluent Platform — Broadcom's commercialisation of Apache Kafka with proprietary extensions — has followed a pricing trajectory familiar to enterprises that remember the VMware playbook. Since Confluent's IPO and subsequent pricing restructuring, enterprise Kafka customers have seen annual costs increase substantially, often without corresponding increases in capability usage. The question many platform teams are now asking is whether the Confluent proprietary extensions they depend on are worth the delta — or whether open source Apache Kafka plus targeted tooling can deliver the same capabilities at a fraction of the cost.

Mapping the Confluent Feature Delta

The Confluent Platform capabilities that have no direct Apache Kafka equivalent — and require the most migration planning — are:

Schema Registry

Confluent Schema Registry manages Avro, Protobuf, and JSON Schema schemas with a REST API and schema evolution controls. The open source alternative is the community-maintained Apicurio Registry, which provides a compatible Schema Registry API and is used in production by several large OSS Kafka deployments. Migration from Confluent Schema Registry to Apicurio requires exporting schemas (available via the Schema Registry REST API) and updating producer/consumer client configuration to point to the new endpoint.

ksqlDB

ksqlDB (the Confluent streaming SQL engine) enables stream-table joins, aggregations, and transformations via a SQL interface. Open source alternatives include Apache Flink (significantly more powerful, significantly more operational complexity), RisingWave (a Postgres-compatible streaming database), and Kafka Streams (Java API, integrated with Kafka directly). The right choice depends on the specific use cases built on ksqlDB; most can be migrated to Kafka Streams or Flink, but some SQL-idiomatic patterns require careful redesign.

Confluent Control Center

Control Center provides cluster monitoring, consumer group lag tracking, and schema management UI. Open source replacements include AKHQ (Apache Kafka HQ) for cluster management, Kafka UI for topology visualisation, and Prometheus + Grafana with Kafka Lag Exporter for monitoring and alerting. The monitoring replacement requires instrumentation work but is fully achievable and provides more customisability than Control Center's fixed dashboard model.

Kafka Connect Management

Kafka Connect is open source, but Confluent's Confluent Hub connector marketplace and the commercial connectors (Oracle CDC, SAP connector, Salesforce connector) require evaluation. The open source Confluent connectors (JDBC, Elasticsearch, S3) are available under the Apache license. The fully commercial connectors require either Confluent licensing or replacement with open source alternatives (Debezium for CDC, custom connectors for proprietary systems).

Migration Sequence

1. Inventory: Document every Confluent-proprietary feature in use across all environments. Categorise by migration complexity (direct OSS equivalent vs. replacement-required vs. no equivalent).
2. Replace monitoring first: Deploying Prometheus + Kafka Lag Exporter + Grafana before the migration begins gives you visibility into the Confluent cluster during the migration and validates the monitoring stack before it becomes the only monitoring stack.
3. Migrate Schema Registry: Deploy Apicurio in parallel with Confluent Schema Registry, migrate schemas, update client configuration in a non-production environment, and validate schema compatibility checking works as expected.
4. Migrate Connect workloads: Deploy open source Kafka Connect workers and migrate connector configurations one at a time, validating data flow before decommissioning the Confluent-managed Connect instances.
5. ksqlDB replacement: This is typically the longest-lead item. Plan the Flink or Kafka Streams replacement in parallel with the other migration tracks.
6. Cut over broker configuration: For the broker itself, the migration is minimal — OSS Kafka is the same codebase as Confluent Platform's broker component. Update the broker configuration to remove Confluent-specific settings and deploy open source Kafka in the same topology.

OSSeva's Role in the Transition

During and after the migration, OSSeva provides CVE-patched builds of Apache Kafka for the version you're migrating to, along with compliance documentation that satisfies the same evidence requirements that Confluent's commercial support previously fulfilled. This ensures that leaving Confluent does not create a support gap that auditors will flag.

Conclusion

Exiting Confluent is a well-bounded engineering project for most enterprises. The broker itself is trivially replaceable; the complexity is in the proprietary extensions. Prioritising those extensions in the inventory phase — and sequencing the migration to replace monitoring first and ksqlDB last — keeps the work manageable and the risk contained.