Install kmq once. Paste one prompt into your coding agent. It assesses your Kafka cluster, copies topic history into KubeMQ, maps consumer offsets and walks you through cutover, one workload at a time. Kafka keeps serving until you switch.
The installers verify the release checksum. If kmq version is not found, open a new terminal and try again.
Step 2
Copy a prompt into your coding agent
Assess migration readiness
A read-only check of your Kafka topics, consumer groups and workload requirements.
Use kmq to assess my Kafka migration readiness without changing either cluster. Read kmq skills get core and kmq cheat migrate, then check the installed command help. Ask for source brokers, authentication references, and the topics, consumer groups and applications I want to move. Keep secrets out of chat. Run kmq assess kafka and kmq migrate assess --check. Report blockers, unknowns and caveats, explain what still needs validation, and propose next steps. Stop after the assessment; do not create resources, copy data or switch applications.
Start here to understand compatibility. A successful assessment does not qualify data copying or production cutover. Full migration guide.
Migrate to KubeMQ
Move an assessed workload with verification and a controlled switch to KubeMQ.
Use kmq to guide my Kafka migration to KubeMQ. Read kmq skills get core and kmq cheat migrate, then check the installed command help. Ask for source and target details, credential references and workload scope. Keep secrets out of chat. Assess first and stop on blockers or unknowns. Check target identity and strict acknowledgement on every node, preview topic preparation, and save a migration plan. For Kubernetes, use the kmq migrate job workflow. Replicate, verify, translate offsets and rehearse before proposing cutover. Ask before creating resources, writing to the target or pausing applications. Require explicit cutover approval and a rollback plan. Validate application behavior before declaring success; never bypass safety checks.
Data migration requires an operator-managed KubeMQ cluster on Kubernetes; a Docker evaluation is not a migration target. Rehearse before production cutover; review permissions, application behavior and recovery with your operator. Full migration guide.
Before you start
The assessment checks these for you. Knowing them up front saves a round trip.
Compacted topics and more than 256 partitions are blockedBoth stop the assessment. Everything else migrates cleanly or with a stated caveat.
Records up to 1 MBReplication caps records at 1,048,576 bytes by default. Check actual record sizes; the assessment does not read every record.
Committed records onlyAborted transactions and transaction history are not recreated on the target.
Target must use strict acknowledgementEvery KubeMQ node must run with strict acknowledgement before any write. The tools refuse otherwise.
Questions
What changes for our applications?
Keep your Kafka client library and code. Change bootstrap.servers to KubeMQ and set the target’s authentication. The assessment flags any workload-specific adjustments.
Can we keep Kafka running during the move?
Yes. Kafka stays read-only to the tools and keeps serving production until you cut over each workload. You choose the window.
What if something fails mid-copy?
Progress is saved in a state file. Copying is resumable and at-least-once; plan for duplicate handling in your consumers.
Can we run it without a coding agent?
Yes. Every step is a plain kmq command. Run kmq cheat migrate for the full sequence.
Need help with your first wave?
Bring your topics, consumer groups and throughput. We’ll plan the parallel setup and cutover with you.
Start with your Kafka workload.
Your privacy, your choice.
We use essential services to run this website. Optional Vimeo videos may use cookies and only load with your permission. Optional Google Analytics uses cookies to understand site usage and only loads with your permission. No advertising trackers. Privacy notice