ActiveMQ Classic vs Artemis: What Actually Changed

ActiveMQ Classic and ActiveMQ Artemis are two different broker implementations, not two versions of the same product, and as of late 2025 they are governed as two separate Apache top-level projects. Neither is deprecated — both shipped active releases through mid-2026. The practical question for teams on Classic isn't whether Artemis will replace it, but what changes operationally if you move.

Artemis isn't a rewrite of Classic — it's the HornetQ codebase donated to Apache and built to a different internal model. Apache's own migration documentation is specific about where the two diverge architecturally. Classic's I/O layer offers a choice between synchronous tcp and non-blocking nio transports; Artemis standardises on Netty, so the non-blocking path is simply the default rather than an option.

The message store differs more. Classic's KahaDB pairs a journal with an index so the broker can page messages in from disk when memory runs short, tracking their position with a maintained index. Artemis keeps the whole journal in memory and dispatches from it directly; paging happens on the producer side before messages ever reach the broker, and the on-disk journal is only replayed sequentially at startup. Apache's docs call this "one of the main differences between ActiveMQ 5.x and Artemis," and it changes how you tune memory and disk for the workload.

Addressing is the third divergence. Classic is OpenWire-centric — JMS queues and topics are first-class, and other protocols get translated internally into OpenWire. Artemis implements only queues internally and builds topics, point-to-point delivery and everything else on top of address-based multicast and anycast routing, applied uniformly across every protocol it speaks.

As of writing, no — and the governance change actually points the other way. On November 19, 2025, the Apache ActiveMQ PMC voted to split into "two distinct Apache Top-Level Projects: Apache ActiveMQ and Apache Artemis," stating plainly that "both projects are highly active with vibrant communities," and that the goal was "greater clarity and dedicated focus for our communities," with each project moving forward under its own governance rather than one absorbing the other.

Release activity backs that up. Classic shipped 6.3.1 in August 2026, with parallel maintenance releases on the 6.2.x and 5.19.x lines in the same window — three concurrent supported series is not what a sunset project looks like. Artemis, on its own new domain, released 2.55.0 in June 2026. We're stating this as what Apache's own project pages and release notes show as of this writing, not as a permanent guarantee — check the current activemq.apache.org and artemis.apache.org release pages before you plan around it.

Configuration, HA and tuning don't transfer, because the underlying models don't match.

Storage and paging. KahaDB data does not migrate into Artemis's journal format. Because Artemis pages on the producer side instead of caching from an indexed store, memory-pressure symptoms that used to show up as index contention on Classic show up differently on Artemis.

High availability. Classic's master/slave pairs lean on shared storage — a SAN or a shared database. Artemis pairs a primary with a backup under shared-store or replication policies, with its own split-brain protections. Your runbooks need rewriting, not renaming.

Client connectivity. Artemis documents OpenWire support specifically so existing Classic and 5.x clients can keep connecting while you migrate broker-side, which is the one piece of this move that isn't a redesign.

Build tooling. If you're on Artemis 2.50.0 or later, the Maven groupId is org.apache.artemis, not org.apache.activemq. Apache is publishing relocation POMs at the old coordinates for a transition period, but new builds should reference the new groupId directly.

We're not publishing a number, because any number we gave you would be wrong for your workload. What's fair to say architecturally: Artemis's non-blocking Netty I/O and simpler journal-only store were built to handle higher connection concurrency than Classic's cursor-and-index model. That's a design intent, not a benchmark result. Persistence settings, message size and acknowledgement mode move throughput more than the broker name does — test both against your own traffic before treating speed as the deciding factor.

Yes, and it's worth saying plainly: a Classic-to-Artemis move is a real migration, not an upgrade. Storage, HA and addressing are all being redesigned regardless of where you land. If that redesign cost is already sunk, it's a natural moment to also evaluate RabbitMQ rather than assuming Artemis is the only destination because it shares a name with what you're leaving.

We cover the protocol, JMS and clustering trade-offs between ActiveMQ and RabbitMQ in full in ActiveMQ vs RabbitMQ — including where RabbitMQ's routing model and AMQP-first design fit polyglot estates better than either ActiveMQ broker.

Weighing a Classic-to-Artemis migration, or wondering whether RabbitMQ should be in that evaluation? AceMQ runs assessments that cover both paths honestly, including the option of staying on Classic. Start with RabbitMQ consulting and support, or talk to an AceMQ engineer.

• Apache Artemis — "ActiveMQ PMC voted to establish Apache Artemis Project" (Nov 19, 2025)
• Apache ActiveMQ Artemis — Key Differences from ActiveMQ 5
• Apache Artemis — TLP Maven groupId migration
• Apache ActiveMQ — News and release history
• Apache Artemis — Downloads and current release
• Apache ActiveMQ Classic — Component overview