The ActiveMQ Modernization Guide, 2026

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.

Apache marks two ActiveMQ Classic lines as Active, 6.3.x and 5.19.x, and defines every other line as Inactive: reached end-of-life and no longer actively maintained (Apache download page, checked 20 October 2026). The last column is the practical test. Apache's advisory for CVE-2026-74761 names fixed releases only on the two Active lines.

A line with no fixed release is not unpatched by accident: it is where upstream has stopped. Four advisories show what that costs, with scores from the National Vulnerability Database (NVD) and fixed versions from Apache's advisory files:

CVE-2023-46604 was fixed on each of the 5.15 to 5.18 lines. The later advisories were not: Apache lists them as affecting every release before 5.19.4, 5.19.8 or 5.19.11 and the 6.x releases before the fixed versions, so a 5.18 or older broker has no fixed release for any of the three. Artemis is a separate codebase: its download page names 2.57.0 (9 September 2026) as the current release, requires Java 17 or later and gives no end-of-life dates for earlier versions. Apache's Artemis advisories name 2.57.0 as the fix for seven 2026 issues affecting releases up to 2.56.0, among them CVE-2026-67593 (OpenWire queue deletion before authentication, CVSS 9.1) and CVE-2026-57967 (CORE session takeover, CVSS 9.8), both published by NVD on 10 September 2026. On Artemis, staying on the current release is the patch path.

Sources, all checked 20 October 2026: the ActiveMQ Classic download page and security advisories, the Artemis download page and security advisories, and NVD records for each CVE listed.

Classic 6.0 and later clients use the jakarta.jms package; 5.x clients use javax.jms. Apache's JMS 2 documentation calls it a package name change only: ActiveMQ's own package names do not change, but every application that imports javax.jms has to be recompiled against jakarta.jms, and 6.x needs Java 17. The 5.18.1 and later releases include a transitional activemq-client-jakarta module that gives client-only, partial Jakarta Messaging 3.1 support. It cannot share a JVM with the javax client or an embedded broker, so it works against remote brokers only, and it is removed in 6.x. Apache's own caveat applies throughout: verify the JMS features you use in the release notes, because the support is partial.

That makes 5.19.x the lower-risk step for an estate that cannot move its applications yet: it is still javax on the broker, it is Active, and it carries the 2026 fixes. The jakarta move then becomes an application project that can be scheduled separately from the security fix.

Mixed javax and jakarta clients can talk to the same broker over OpenWire, so the broker upgrade and the application move do not have to happen on the same night. Apache's tracker issue AMQ-9418, resolved as fixed in 5.16.8, 5.17.7, 5.18.4, 6.0.2 and 6.1.0, added exception mapping between the two namespaces so javax clients can work with a jakarta-based broker and the reverse. Without it, OpenWire sends exceptions as class names, and a client that cannot load the class falls back to a generic JMSException.

1. Bring every client library to a release that carries the AMQ-9418 fix before the broker changes.
2. Upgrade brokers one at a time, to an Active line, and confirm that existing 5.x clients reconnect and fail over.
3. Move applications to jakarta.jms one service at a time, deploying each against the upgraded broker.
4. Test the failure paths in staging: rejected authorisation, a missing destination and a dropped connection are where the two namespaces differ.

Apache does not publish a compatibility guarantee between release lines on the pages cited here, so treat the order as a rehearsal plan, not a promise.

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 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.

Which fits which situation

• Artemis: the estate is JMS-centric and the Java clients are staying.
• RabbitMQ: polyglot clients, AMQP or MQTT reach, per-message acknowledgement and routing control, or a team that already runs RabbitMQ.
• Stay on ActiveMQ: the application leans on deep JMS 2.0 semantics (message selectors, JMSXGroupID message groups, shared durable subscriptions, JMSReplyTo), uses XA transactions, or the broker is stable and unloved. If the real problem is the application, such as unbounded prefetch or consumers that cannot tolerate a redelivery, a new broker carries it across intact.

From our engagements. In our engagements an ActiveMQ migration almost always starts from one of five triggers rather than a benchmark: Classic end-of-life pressure, polyglot clients, data safety after a KahaDB recovery or a failed shared-storage failover, device fleets sending MQTT or AMQP 1.0, and staffing, the one people underrate. Where the real problem is the application, we would rather keep you on ActiveMQ and fix the application than sell you a migration.

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.

From our engagements. A university ran ActiveMQ and a RabbitMQ cluster several minor versions behind to stream student information system events. AceMQ assessed both estates and designed one RabbitMQ target. Consolidation was expected to roughly double the load on the surviving cluster, so sizing could not be inherited, and because the RabbitMQ version was past community support, the upgrade and the migration became one project, with a parallel cluster for a staged cutover and training for the team that operates it (the case).