Confluent Migration
Last reviewed by Tyler Eastridge
AceMQ moves Kafka estates off Confluent Cloud or on-premises Confluent Platform onto open source Apache Kafka, deployed on your infrastructure or ours, and has a 24/7 support contract in place before the Confluent one ends. The plan covers the data copy, Schema Registry and connector replacements, the Confluent-only features you give up, a dual-run period and the cutover.
Customers
Partners
Is This You?
A Confluent renewal is on the calendar and you want a real alternative to price it against
IBM completed its acquisition of Confluent on 17 March 2026 and procurement wants a plan B
The bill is driven by data in and out, and your traffic keeps growing
You use Confluent mainly as managed Kafka and rely on few of its platform features
The data has to stay in your own cloud account or data centre
You want one support contract that covers Kafka whatever runs underneath
You cannot say which Confluent features your applications actually depend on
Outcomes
Concrete state changes, not deliverable counts. This is what actually differs about your Kafka estate when the engagement closes.
Before
Nobody can list which Confluent-only features the applications use.
After
A feature map: each Confluent feature in use, its open replacement, or the decision to drop it.
Before
The exit looks like one risky cutover weekend.
After
A dual-run plan: both clusters live, topics mirrored, consumer groups moved one at a time, with a rollback point at each step.
Before
Support stops when the Confluent contract does.
After
A support contract with a named senior engineer and a 15-minute emergency response, in place before cutover.
Before
The cost after the move is a guess.
After
A before-and-after cost model on your own throughput, using public list prices wherever a hosted option is in the comparison.
Scope
Topics, partitions, retention, ACLs, quotas, Kafka versions and the client libraries behind every producer and consumer, so the target cluster is sized and configured from facts. On-premises Confluent Platform clusters are in scope as well as Confluent Cloud, and a cluster that still runs ZooKeeper needs a KRaft migration before Apache Kafka 4.
MirrorMaker 2, which ships with Apache Kafka, copies each Kafka topic with its configuration, consumer group offsets and ACLs. We plan topic naming up front, because replicated topics carry a source-cluster prefix by default.
Confluent's documentation says cluster links on Confluent Cloud can only be created with Dedicated or Enterprise Confluent Cloud destination clusters, so Apache Kafka cannot be the destination. The way out is MirrorMaker 2, and we plan around its limits.
Schemas, compatibility settings and, critically, schema IDs, because messages already on disk reference them. You can keep running Confluent Schema Registry yourself, subject to its licence terms, or move to another registry.
Each managed connector replaced by a Kafka Connect worker you run, with its configuration, offsets and licence checked one by one. Connectors are usually the longest list in the project.
Kafka Streams applications run on any Kafka cluster. Managed Flink statements need a replacement, and state and delivery guarantees are re-tested rather than assumed.
Confluent API keys, service accounts and RBAC rebuilt as TLS, SASL and Apache Kafka ACLs on the new cluster. RBAC does not map one-to-one onto ACLs, so each role is reviewed.
Confluent Cloud metrics replaced by JMX and Prometheus-style monitoring, with alerts for under-replicated partitions, consumer lag and disk before the first producer moves.
Runbooks written for the new topology, and the support contract at the stage you choose, so the pager has an owner on cutover day.
The Engagement
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.
A Kafka health check of the Confluent estate: clusters, features in use, connectors, clients and security. The output is the feature map and a sized target. Delivery is remote and read-only, guided by your engineers. We take no access to your environment or code.
You receive
The target Apache Kafka cluster is built, secured and monitored. Replication, schemas and a representative set of connectors are rehearsed on non-production topics.
You receive
Topics are mirrored to the new cluster while applications keep running on Confluent. Lag and offset translation are watched, and consumer groups move one at a time. Both clusters bill while this lasts, so the plan keeps the overlap as short as the testing allows.
You receive
Consumers move once the mirror has drained, then producers. When the last application is across, Confluent is decommissioned and the runbooks and support contract take over.
You receive
Most guides explain how to migrate to Confluent from a self-managed Kafka cluster; this page covers the reverse. Upstream Apache Kafka is the same protocol and the same client libraries, so topics and consumers carry across. What does not carry across is the platform around the brokers. The table is the starting point for the feature map in the assessment.
| Area | On Confluent | On Apache Kafka | What to plan for |
|---|---|---|---|
| Replication between clusters | Cluster Linking; on Confluent Cloud the destination must be a Dedicated or Enterprise cluster | MirrorMaker 2: topics with configuration, consumer group offsets and ACLs | Topic names are prefixed by default; set a replication policy if applications cannot change names |
| Schema Registry | Managed, billed per environment | Confluent Schema Registry run yourself, under the Confluent Community License, or another registry | Preserve schema IDs; the licence permits your own production use but not a competing hosted service |
| Connectors | Managed connectors, billed per task-hour and per GB | Kafka Connect workers you run | Check each connector's licence and offset handling |
| Stream processing | Managed Flink, billed per CFU | Apache Flink or Kafka Streams you run | Re-test state, restarts and delivery guarantees |
| Capacity | Elastic units that scale with load | Brokers sized for peak, or brokers AceMQ operates for you | A capacity plan and a rebalancing routine |
| Support | A Confluent support plan | An independent Kafka support contract | In place before cutover, not after |
Confluent's documentation describes Confluent Platform as software you download and manage yourself, built on Kafka with additional proprietary components. If your clusters are on-prem Kafka under Confluent Platform, they are already yours to operate, so the exit is about the licence and the commercial features, not about where the data lives. Confluent Server, the enhanced broker, is a superset of the confluent-kafka package, and Confluent's documentation names RBAC, Tiered Storage and Confluent for Kubernetes among the commercial features that need it. Each Confluent Server broker also checks the licence set in its confluent.license property at startup. Open source Kafka does not include Confluent's RBAC or its Kubernetes operator, so each commercial feature in use needs an open replacement or a decision to drop it.
Confluent Cloud is the harder exit in a different way. The brokers are not yours, so the target cluster has to be built, sized and secured before the first topic can be mirrored, and the managed connectors, Schema Registry and Flink statements around the brokers move one by one. Data pipelines are the part that takes the time: a typical connector inventory is change data capture sources reading from databases and sinks writing to a data warehouse or another data store, and every one of them is a real-time data flow that must keep running while it moves.
| Confluent Platform, self-managed | Confluent Cloud, fully managed | |
|---|---|---|
| Who runs the brokers today | Your team, on-prem or in your own cloud account, often deployed with Confluent for Kubernetes | Confluent |
| What the move must replace | Commercial broker features such as RBAC and Tiered Storage, plus the licence | The brokers themselves, networking, managed connectors, Schema Registry and Flink |
| First step | Feature map, then a target cluster beside the existing one | Target cluster build and sizing, then replication with MirrorMaker 2 |
| Main risk | Hidden dependence on a Confluent-only broker feature | Connector and schema ID coverage, and paying for both platforms during the dual-run |
Strimzi, a Cloud Native Computing Foundation incubating project, is one way to run an Apache Kafka cluster on Kubernetes in a data centre or a public cloud, and brokers on virtual machines are the other common choice. We scope where to deploy the new cluster in the assessment, because the right answer depends on who will run the platform afterwards.
IBM announced on 17 March 2026 that it had completed its acquisition of Confluent. The announcement describes Confluent as built on Apache Kafka, which remains an Apache Software Foundation project. What the deal changes is who you sign a renewal with, and a renewal is easier to negotiate when you can show a costed alternative. That is the use of a migration plan even if you stay.
Rule we hold
Never move production traffic until the old cluster has been proven recoverable and the new one has been proven stable under real consumer lag. The plan keeps a rollback point at every step.
AceMQ's migration work is scoped and quoted, not priced from a rate card. The drivers are the number of clusters and environments, the connectors and Flink jobs to replace, the volume of data to mirror, the length of the dual-run and the support stage you choose afterwards.
The support side is the independent Kafka support range of about $24,000 to $72,000 a year, depending on cluster count and response tier. Add the infrastructure you will run and compare the total with your Confluent invoice. If the invoice is small and steady, the exit may not pay back, and we say so.
AceMQ support for Apache Kafka is 24/7 under written SLAs: a 15-minute first response on a production emergency, 1 hour for critical issues and 4 hours for high-priority ones. Your team keeps the pager at Stages 1 and 2, with an engineer behind it and, at Stage 2, proactive monitoring. At Stage 3 AceMQ operates the cluster on your infrastructure, and at Stage 4 on AceMQ's.
Customer Success
See how enterprises trust AceMQ for their most critical Kafka workloads.
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
LinuxBanking 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
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
KubernetesEuropean Online Trading Platform
Independent architecture and performance review of RabbitMQ, Kafka, and Redis for an online trading platform.
RabbitMQKafka
RedisAmerican National Insurance
American National Insurance chose a standalone Debezium + RabbitMQ architecture for SQL Server change data capture after judging Kafka too complex to run for the job, keeping operations lean and routing flexible.
KafkaRabbitMQ
DebeziumKubernetesGlobal 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 MQPagoNXT (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.
KafkaRabbitMQEnterprise 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.
KafkaFAQ
Yes. Confluent Schema Registry can be run yourself under the Confluent Community License, which permits your own production use and excludes offering a competing hosted service. The key step is preserving schema IDs when the schemas move, because messages already written reference them. Another registry is also possible, and we review compatibility settings either way.
It depends on the number of clusters, connectors and applications, and on how long the dual-run needs. The assessment takes one to four weeks and produces the plan and timeline; we do not quote a standard duration before that. Connectors and stream processing usually decide the schedule, not the data copy.
Managed connectors are replaced by Kafka Connect workers you run, each with its configuration and offsets moved and its licence checked. Some connectors have direct open-source equivalents and some need a different approach, which the feature map lists before any work starts.
AceMQ provides 24/7 support for upstream Apache Kafka with a 15-minute first response on a production emergency, 1 hour for critical issues and 4 hours for high-priority ones. The same contract covers self-managed, Amazon MSK and Confluent Platform clusters, and AceMQ can operate the cluster for you at Stages 3 and 4.
Confluent's documentation describes Confluent Platform as a distribution of Kafka that provides all of Kafka's open-source features plus additional proprietary components, some of which run inside the brokers through Confluent Server. Topics, partitions and the client protocol are the same, so applications carry over. The difference is the commercial features and the licence, which is why the assessment starts with a feature map.
Usually not. Apache Kafka 4.0, released on 18 March 2025, is the first major release that runs entirely without ZooKeeper, so the new Apache Kafka cluster is built on KRaft from the start. MirrorMaker 2 reads the old cluster as an ordinary client, so you do not need to migrate the old cluster to KRaft first, and the inventory confirms broker and client version compatibility. If you would rather finish a KRaft migration in place first, see the Kafka upgrades service.
Not for the whole migration. Topics are mirrored while producers keep writing to Confluent, consumer groups move once the mirror has drained, and producers move last. Topics that need strict ordering per key may need a short producer pause at their own cutover, which the plan identifies per application.
Let's talk
Tell us which Confluent product you run, how many clusters, and when the contract renews. We will scope the assessment and reply within 1 hour and follow with a timeline and a written quote.
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.