Guide · ActiveMQ

The ActiveMQ Modernization Guide

ActiveMQ estates are facing a decision they did not ask for: Classic is a mature broker with a limited future, Artemis is the successor with a different operational model, and RabbitMQ is the broker many of the same workloads moved to. This guide takes the decision in order and points to the article that works each step.

Tyler Eastridge

By Tyler Eastridge, Head of Operations

LinkedIn · Updated

2 min read4 sections
On this page
The decision in one paragraph

The decision in one paragraph

Work out which ActiveMQ you run, because Classic and Artemis are different brokers sharing a name. If the estate is JMS-centric and the Java clients are staying, Artemis is the natural successor and the move is mostly configuration and clustering changes. If the estate has outgrown JMS, needs AMQP or MQTT reach, per-message control or a broader client ecosystem, RabbitMQ is the better destination and the migration is an architecture project rather than an upgrade. Either way the work is the inventory of destinations, selectors, transactions and the integrations nobody documented.

Which ActiveMQ you run, and what changed

ActiveMQ Classic and ActiveMQ Artemis are separate codebases with different clustering, persistence and configuration models. Artemis is the successor, built from the HornetQ code base, with a different journal, a different high-availability model and a different address model. Whether Classic is being phased out is a question with a nuanced answer; the practical point is that new development is concentrated on Artemis.

What moving to Artemis changes operationally

Addresses and queues replace destinations, the journal replaces KahaDB, live-backup pairs replace the Classic master-slave model, and the configuration file is new. The JMS clients mostly survive; the operational runbooks do not. Plan the move as a new broker deployment with a migration of state, not as a version upgrade.

When RabbitMQ is the better destination

When the estate is no longer JMS-centric: polyglot clients, AMQP or MQTT reach, per-message acknowledgement and routing control, or an operations team that already runs RabbitMQ elsewhere. The comparison post works the protocols, clustering and performance differences; the honest answer is that a JMS estate with Java clients usually goes to Artemis, and a broader one usually goes to RabbitMQ.

How the migration runs

Inventory destinations, selectors, transactions, virtual topics and the integrations nobody documented; map each to its equivalent; build the target on quorum queues from day one; run in parallel with a bridge; move consumers first and producers last; validate before decommissioning. The RabbitMQ migration guide sequences it.

Frequently asked questions

Is ActiveMQ Classic deprecated?

Not formally, but new development is concentrated on Artemis, and estates on Classic should plan a move rather than assume indefinite maintenance. The Classic vs Artemis post covers the current position.

Should we move from ActiveMQ to Artemis or to RabbitMQ?

Artemis if the estate is JMS-centric with Java clients staying; the move is a new broker deployment but the clients mostly survive. RabbitMQ if the estate needs AMQP or MQTT reach, per-message control, or a polyglot client ecosystem. The comparison post works the trade-offs.

Does RabbitMQ support JMS?

Through a JMS client library, yes, for most of the API. Some JMS semantics map differently onto AMQP, and selectors and transactions need checking case by case, which is why the inventory comes first.

Does AceMQ support ActiveMQ?

Yes, Classic and Artemis, in production, with the same 24/7 model as RabbitMQ, and AceMQ runs the migration to RabbitMQ where that is the destination.

ActiveMQ services

Where this gets done

The work behind this page, run by the same engineers who wrote it.

Next step

Talk to an engineer

AceMQ supports 130+ enterprise clients in 26+ countries. Tell us what you are running and we will come back within a business day.