Migrate from ActiveMQ Artemis to Apache Kafka

The count of destinations, and how many of them carry selectors, sets the size of the mapping work more than raw message volume does. Each JMS queue or topic must be mapped to a Kafka topic, a partitioning key, and a consumer group design, and each selector-based subscription must be rewritten as consumer-side filtering or split into separate topics. This mapping is a one-time design effort. Ongoing work recurs whenever new destinations are added, so ask the quote to list every destination, its consumers, and each selector by name.

Yes, they usually need the most design attention. Local JMS transactions and XA transactions that span Artemis and a database do not carry over directly. Kafka offers idempotent producers and transactions between Kafka topics, but a transaction spanning Kafka and an external database needs an outbox or similar pattern. Any service that relies on two-phase commit will need a changed consistency model, so the quote should name every transacted flow and the systems involved.

Ordering guarantees within a Kafka partition are strong, but they do not match Artemis message priority or global ordering across a destination. Priority has no direct Kafka equivalent, so consumers that depend on it need a new scheduling approach. Ordering that must hold per entity can be achieved with a stable message key, which affects partition count and rebalancing behavior. Ask for a list of the flows where ordering or priority is a business rule, since these take the longest to verify.

Artemis handles redelivery counts, delayed redelivery and dead-letter addresses on the broker side, while Kafka consumers track their own offsets and error handling. Each consumer needs a retry policy, a dead-letter topic or equivalent, and a way to replay failed records. Teams often underestimate this because it touches every consumer. Ask the quote to cover retry limits, poison message handling, and the tooling used to inspect and replay dead-lettered messages.

Yes. Large messages, binary payloads, and mixed formats such as JMS object messages increase conversion and testing effort. Kafka brokers and clients have their own size limits that must be set deliberately, and Java object serialization in JMS messages typically needs replacing with a documented format. Ask for an inventory of body types, average and maximum sizes, and any use of JMS object messages, along with the schema approach agreed for the new payloads.

Each client application is a separate unit of work: it needs a new producer or consumer, tests, and a cutover step. Clients written in several languages need several client libraries and their own conventions for offsets and error handling. Ask for a list of applications with their language, JMS API version, owner, and whether the code can be changed. Applications that cannot be changed may need a bridge, which adds recurring operation.

JAAS login modules, TLS listeners, and broker roles do not transfer as-is. In Kafka, clients authenticate with SSL or SASL, and the documented SASL mechanisms include GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, and OAUTHBEARER. Authorization in KRaft clusters is handled by the StandardAuthorizer, which stores ACLs in the cluster metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Each Artemis role must be mapped to explicit Kafka ACLs, and that mapping is a one-time task that must be tested per application. Confirm the chosen identity source with your security team.

One-time costs include discovery, destination mapping, transaction and ordering redesign, client changes, the bridge build, security mapping, and cutover testing. Recurring costs include running the Kafka cluster, the Camel JMS Artemis source connector while the bridge is in use, monitoring, certificate and credential rotation, and upgrades. Count each environment separately: development, test, staging, and production each repeat the verification work. In the quote, ask for the one-time and recurring totals to be shown as separate lines.

The cost depends on the scope agreed in writing, and no figure is given here. The main components are the discovery of queues, topics and consumers, the design of topics and partitions, the build of producers and consumers, the bridge or connector work, testing, cutover and handover. Infrastructure is a separate line: Kafka itself is licensed under Apache-2.0, so the recurring spend is compute, storage, network and the people who run the cluster. Costs rise with the number of JMS destinations, the number of consumer applications that need code changes, the amount of ordering and redelivery logic that must be reproduced, and the number of environments. Ask any provider for a quote that lists one-time work separately from recurring support, upgrades and testing.

The timeline is set by the number of destinations and applications, not by the broker itself. Teams usually need time to inventory JMS queues, topics, selectors, durable subscriptions and message formats, then decide which consumers can move first. Other drivers are how many consumers rely on JMS-specific behavior such as per-message acknowledgment and redelivery, whether the bridged period needs both systems running, the change windows available in your production environment, and the approvals required for new infrastructure. Agree on milestones and the exit criteria for each cutover phase before work starts, and confirm durations with your own environment rather than with generic estimates.

Yes, many teams do, provided they have engineers who know both the JMS API and Kafka's consumer model. The gaps usually appear in three places: translating queue semantics into partitions and consumer groups, reproducing acknowledgment, retry and dead-letter behavior in application code, and operating a KRaft cluster with TLS, authorization and monitoring. Ask whether the team has done a bridged cutover before and who will own the cluster after go-live. A partner can take on a fixed scope, such as the topic design, the connector setup and the cutover runbook, while your team keeps ownership of the business logic.

Developers need to name the JMS consumers and producers, describe their acknowledgment and retry logic, and say where message order matters. They also need to confirm message bodies, headers and property names, because these become the Kafka record format and the contract consumers depend on. Operators need to provide the network paths between Artemis and Kafka, identity and certificate sources, the monitoring and alerting stack, backup expectations, and the change calendar. Both groups should agree who signs off on each cutover step, and who can roll a consumer back if a redelivery problem appears in production.

Yes, a staged move is normally planned so that Artemis keeps serving existing consumers while Kafka takes over one flow at a time. A bridge can copy messages from JMS destinations into Kafka topics using the Camel JMS Artemis source connector, so that new consumers read from Kafka while legacy consumers finish draining Artemis. The period in which both systems run is a cost and risk factor: it adds infrastructure, duplicate-processing checks and reconciliation work. Confirm with the Camel and Kafka Connect documentation how the connector acknowledges messages, and test failure and restart behavior in a non-production environment before the first production flow moves.

Kafka guarantees order only within a partition, while a JMS queue delivers messages to competing consumers in a way that does not map one to one onto partitions. If a consumer depends on strict order for a business key, the topic needs a partitioning key that keeps that key in one partition, and the consumer group must be sized so that partitions are not reassigned mid-stream without care. Redelivery also differs: Artemis tracks acknowledgment per message, while Kafka consumers track offsets per partition, so a failed message usually needs retry topics or a dead-letter pattern written by the application team. Test these paths with real failure injection before cutover.

Ask for a written inventory of the destinations in scope, a list of consumers and producers with their acknowledgment and ordering requirements, and a topic and partition design that each consumer owner has reviewed. Ask how the bridged period will be tested, how rollback works for each flow, what evidence is delivered at cutover, and who operates the Kafka cluster afterward. Ask which upgrades and security testing are included, and whether support or retainers are priced separately. Confirm all of this in writing, since a fixed-scope agreement is the document that defines what is delivered.