Migrate from another broker

This hub is the entry point for migrating an application from an external messaging ecosystem onto KubeMQ's wire-protocol connectors. Each guide covers what migrates cleanly, what migrates with caveats, and what does not migrate at all — the endpoint/connection change, the concept-to-pattern mapping, a working code example, the security posture, and a copy-pasteable smoke test. Every guide includes a quick start you can run on your laptop.

Important framing: the nine covered ecosystems are ecosystems, not nine connectors. KubeMQ has seven wire-protocol connectors; several ecosystems ride the same connector. For example, JMS, ActiveMQ-Java, and native AMQP 1.0 clients all use the AMQP 1.0 connector on port 5672.

Ecosystem → Connector Map

Each ecosystem maps onto one (or, for ActiveMQ, several) of the seven wire-protocol connectors. Follow the connector link for that protocol's full reference; follow the guide link in the Guides table below for the step-by-step migration.

Cross-Protocol Comparison

The table below is transposed: axes are rows, ecosystems are columns. Each cell uses ✅ full / ⚠️ partial / ❌ none / N/A (inapplicable — a concept that does not exist in that ecosystem). ❌ means the concept exists in the source ecosystem but the KubeMQ connector does not support it.

Footnotes:

¹ Durable subscription via Events Store; unsubscribe() is node-local (the unsubscribe only takes effect on the node that owns the durable subscription).

² ActiveMQ RPC via the AMQP 1.0 (Qpid JMS) path.

³ Requeued messages re-enter at the queue tail — this is a deviation from RabbitMQ classic queues, which preserve near-head position.

⁴ Set PUBSUB_EMULATOR_HOST=host:8085; Google credentials are not used.

⁵ MQTT 3.1 clients are rejected at CONNECT; use MQTT 3.1.1 (Paho default) or 5.0.

⁶ No client-settable dead-letter queue over this protocol. The AMQP 1.0, STOMP, and MQTT connectors never set a redrive target on published messages, so a poison message exceeding MaxReceiveCount is silently dropped by the broker — it is not delivered to any consumable dead-letter address. Genuine client-facing DLQ exists only for:

• RabbitMQ — DLX, sets a broker redrive target.
• AWS — redrive policy, also sets a broker redrive target.
• GCP — dead-letters at the connector level by re-publishing to the configured dead-letter topic (new message IDs), not via a broker redrive target.

⁷ Kafka transactions / exactly-once semantics (V1 wire surface) are supported at proof-tier T2 — safe for at-least-once delivery plus basic exactly-once semantics — but this is not a KIP-890 soundness guarantee. See the fitness matrix for the full tier breakdown.

Drop-In Levels

Each guide states its drop-in level — how much application change the migration requires:

• endpoint-only — change the host/port or set an environment variable; your existing client library and code are unchanged.
• client-swap — swap the client library (for example, switch your JMS ConnectionFactory to Apache Qpid JMS); application code remains mostly unchanged.
• partial-rewrite — some application-level changes are required beyond the client and the endpoint.

A guide may list a composite level (for example endpoint / client) when the level depends on the client type — the lower level covers simple publish/consume, and the higher level applies only where a specific feature needs it.

Before You Start

The Kafka and RabbitMQ (AMQP 0-9-1) connectors are on by default; the other five — AMQP 1.0, MQTT, STOMP, AWS SQS/SNS and Google Cloud Pub/Sub — are off until you turn them on (see Enabling and disabling a connector). Each guide's quick start turns its connector on in the KubeMQ you started with Try KubeMQ. For a real installation, start at Choose your path.

Guides

The drop-in level in each row tells you, at a glance, how much application change to expect.

"Connector on by default" says whether a stock server already listens for that protocol.