ActiveMQ Support Providers Compared: Classic and Artemis

The short answer

Five providers publish ActiveMQ support. Red Hat sells AMQ Broker 7.13, its own product built on Apache Artemis, as a long-term support release. Amazon MQ runs ActiveMQ Classic 5.18 and 5.19 as a managed service. Perforce OpenLogic and meshIQ sell 24/7 support contracts for ActiveMQ Classic and Artemis, and meshIQ also sells Classic to Artemis migration. OSSeva ships patched builds of Classic 5.15 to 5.18 and Artemis 2.28 to 2.32, the lines Apache no longer fixes, and can run the brokers for you.

The question that separates them is what happens to a broker on a line Apache has stopped releasing. Only some of these providers publish new security fixes for those lines; the others help you run or replace them.

Which ActiveMQ versions Apache still maintains

ActiveMQ is now two Apache projects. The ActiveMQ PMC voted on 19 November 2025 to make Artemis a separate top-level project, so Classic lives at activemq.apache.org and Artemis at artemis.apache.org, each with its own releases.

Apache's download page defines an inactive line as one that has reached end of life and receives no updates. The ActiveMQ Classic and Artemis end-of-life charts track every line, and ActiveMQ vulnerabilities by version lists the advisories that reach the inactive ones.

ActiveMQ support providers compared

Each row reflects what the vendor publishes on its own site as of 6 October 2026.

Two rows need reading closely. Amazon MQ upgrades brokers itself when a version reaches end of support on the service, within 45 days and after at least 90 days' notice, so it keeps you current rather than keeping an old version alive. meshIQ lists CVE patching but does not publish which versions receive patched builds, so ask for that in writing before relying on it for an inactive line.

How the providers differ

Red Hat AMQ Broker

Red Hat's product is the closest thing to vendor support for Artemis. AMQ Broker 7.12 was based on Artemis 2.33.0 and 7.13 on 2.40.0, and 7.13 is designated a long-term support release that receives bug and CVE fixes. It is a Red Hat build, supported on RHEL 8 and 9 and on OpenShift, with an operator for running brokers on Kubernetes. If you already run OpenShift and are moving to Artemis, it is the natural choice. It does not cover ActiveMQ Classic.

Amazon MQ

Amazon MQ runs the brokers for you, and with automatic minor version upgrades turned on it moves each broker to the newest patch release during the maintenance window. Its version policy is the important part. Classic 5.15, 5.16 and 5.17 have already been retired on the service, and when 5.18 is retired, brokers move to the next supported version automatically during the maintenance window. Amazon MQ has no Classic 6.x and no Artemis, so it is not a destination for Jakarta Messaging or for an Artemis migration.

Perforce OpenLogic

OpenLogic supports ActiveMQ and Artemis as part of a catalogue of more than 400 technologies, with Enterprise Architects, configuration and JVM tuning help, and a two-week ActiveMQ training course. Its long-term support product, which supplies patched builds after end of life, does not list ActiveMQ. Our OSSeva vs OpenLogic comparison covers the wider overlap.

meshIQ

meshIQ sells enterprise support for ActiveMQ 5.x and 6.x, Artemis 2.x and Apache Camel 4.x, with a published P1 acknowledgement time of under one hour and service credits if it is missed. It also offers broker health assessments and migration assistance that maps Classic feature usage to Artemis equivalents before cutover.

OSSeva

OSSeva for ActiveMQ Classic backports security fixes onto 5.15, 5.16, 5.17 and 5.18, so a broker stays on the line its integrations, selectors and KahaDB store already work with. Fixes for OpenWire and STOMP transport CVEs and Java deserialization issues are prioritised, and patched activemq-client artifacts ship from the same build so both ends of a connection match. OSSeva for Artemis patches 2.28 to 2.32 across AMQP 1.0, OpenWire, MQTT and STOMP. Assure adds a transport and authentication audit and a costed migration assessment; Operate adds 24/7 queue depth and store monitoring, a 15-minute P1 response and migration execution. Brokers are priced per cluster, not per queue or connection.

Who can help migrate ActiveMQ Classic to Artemis?

Artemis accepts OpenWire clients, so existing JMS applications usually connect on day one. The work is in everything else: the journal replaces KahaDB, addresses and queues replace destinations, and networks of brokers become Artemis clusters. Help is available from several directions:

• meshIQ, which publishes a migration service that maps feature usage to Artemis equivalents and builds a tested cutover plan.
• Red Hat, which supports the destination broker if you choose AMQ Broker on RHEL or OpenShift.
• OpenLogic, which supports both brokers, so one contract can cover the old and new estate during the move.
• OSSeva, which keeps the Classic brokers patched while the migration runs, covers Artemis on the other side, and executes the move on the Operate tier.

Our guide to migrating ActiveMQ Classic to Artemis walks through what changes, and what tends to be underestimated.

Upgrade, migrate or buy extended support?

There are three moves for a broker on an inactive Classic line, and they differ a lot in effort.

Most estates combine them: move what can move to 5.19 now, keep patched builds on the brokers that cannot, and plan Artemis as a separate project. Brokers on 6.1 or 6.2 have a short path to 6.3, which is the active Jakarta line.

Where OSSeva fits

OSSeva covers the ActiveMQ lines Apache has stopped fixing, Classic 5.15 to 5.18 and Artemis 2.28 to 2.32, with signed builds and the option of 24/7 operations while you migrate. See ActiveMQ Classic extended support for the offer and the extended support vendor roundup for how OSSeva compares by technology layer.

Frequently asked questions

What are the best ActiveMQ extended support providers?

For patched builds of Classic lines Apache no longer fixes, OSSeva publishes coverage for 5.15 to 5.18. For Artemis, Red Hat AMQ Broker 7.13 is a long-term support product, and OSSeva patches Artemis 2.28 to 2.32. OpenLogic and meshIQ sell 24/7 support contracts for both brokers, and Amazon MQ runs Classic 5.18 and 5.19 as a managed service.

Which companies provide ActiveMQ maintenance and security patches?

Apache patches Classic 5.19 and 6.3 and the latest Artemis release. Red Hat ships fixes for AMQ Broker, its Artemis-based product. OSSeva backports fixes to Classic 5.15 to 5.18 and Artemis 2.28 to 2.32. meshIQ lists CVE patching in its support. Amazon MQ can apply the newest patch release to the brokers it runs, within the versions it supports.

Who provides extended support for ActiveMQ Artemis?

Red Hat, through AMQ Broker 7.13 LTS, based on Artemis 2.40.0. OSSeva, with patched Artemis 2.28 to 2.32 builds that run on any Linux distribution or container platform. OpenLogic and meshIQ offer support contracts for Artemis 2.x.

Who can help migrate ActiveMQ Classic to Artemis?

meshIQ and OSSeva both publish Classic to Artemis migration services, and OSSeva's Operate tier executes the move. Red Hat supports AMQ Broker as the destination, and OpenLogic supports both brokers during the transition. OSSeva can also keep the Classic brokers patched during the move, which keeps the migration on a planned schedule rather than an emergency one.

How do ActiveMQ support SLAs and coverage compare?

meshIQ publishes a P1 acknowledgement time of under one hour with service credits. OSSeva's Operate tier has a 15-minute P1 response. OpenLogic's SLA depends on the support level bought. Red Hat's terms follow its subscription. Coverage differs more than response times: check whether the contract includes new security fixes for the exact version you run.

Is ActiveMQ Classic end of life?

Not as a product. Apache still releases Classic 5.19 and 6.3. Every other line, including 5.18, 6.1 and 6.2, is marked inactive and gets no further updates.