We reviewed what eight commercial ActiveMQ support providers publish on their public pages. Not one gives a number for how many Apache committers it employs. Six of the eight publish no pricing at all. Five say nothing about compliance obligations. And not a single one explains what happens to your patched broker binaries on the day your contract ends.
That silence does not make them bad vendors. It does mean the burden of asking sits entirely with you. What follows is a vendor due diligence checklist built for ActiveMQ specifically, with the ten questions that pull specifics out of a sales conversation, what a strong answer sounds like, and the follow up that tests whether the first answer was real.
If you are still deciding whether paid support is worth the budget at all, start with our breakdown of open source versus commercial Apache ActiveMQ® support, which covers the cost side. This article picks up afterwards, once the decision is made and you need to choose between providers.
Why Generic Open Source Support Falls Short for ActiveMQ
A vendor can know Java, JVM tuning and general messaging patterns and still be unable to help you when it matters. Apache ActiveMQ® is really three separate support problems wearing one name.
Two Different Brokers: Apache ActiveMQ®, meaning the 5.x and 6.x lines, and Apache Artemis™ are different pieces of software with different internals, as our ActiveMQ and Artemis comparison sets out in detail. Apache’s own migration documentation states plainly that their message stores are not interchangeable. A vendor fluent in one may have limited depth in the other.
Three Different Integration Paths: Apache Camel, the integration framework that moves messages between systems, ships camel-activemq for ActiveMQ 5.x, a separate camel-activemq6 component for 6.x, and directs Artemis users to the generic JMS component instead. Those are three distinct skill sets at the boundary where most real incidents actually begin.
A Fast Moving Security Surface: Apache’s security advisory pages now list 52 CVEs for ActiveMQ and 20 for Artemis. Twenty five of the ActiveMQ entries were published during 2026 alone, and several exist only because an earlier fix was incomplete. Our Apache ActiveMQ® CVE guide tracks the full list.
Generic open source support services cover the first layer well enough. The questions below test for the rest.
The 10 Vendor Due Diligence Questions
Each question below includes why it matters, what a credible answer contains, and one follow up designed to test the first answer rather than accept it.
1. Are your engineers Apache committers or contributors?
These two words are not interchangeable, and the gap between them is where this market is least precise. A contributor is anyone who has submitted code. A committer holds a formally granted role at the Apache Software Foundation, with the right to merge changes into the project.
Across the eight vendors we reviewed, several claim committers in a headline and contributors in the body copy on the same page. Not one names an individual. Not one gives a number.
What a strong answer sounds like: named engineers, their Apache role stated precisely, and a clear description of who works a broker level defect rather than who takes the first call.
The follow up that tests it: “Which of your engineers appear in Apache’s public committer records, and can we verify that ourselves?” Apache publishes this information openly. A vendor who cannot point you to it is asking you to take a credential on trust.
2. Which exact versions and brokers do you support?
Ask for a version table, not a reassurance. Several vendors name ActiveMQ and Artemis as supported technologies while publishing no version floor, no ceiling, and no policy on what happens when a line stops receiving upstream updates.
This is also where you should check a common piece of misinformation. As of 27 October 2026, Apache lists three actively supported lines, which are 6.4.x, 6.3.x and 5.19.x, with the latest 5.19 release shipping on that same date. Any vendor telling you that all of ActiveMQ 5.x has reached end of life is wrong. What is genuinely inactive is 5.18.x and older, plus 6.0.x, 6.1.x and 6.2.x.
What a strong answer sounds like: a table listing each broker line, marked as fully supported, best effort, or migration only, checked against Apache’s download page with a date attached.
The follow up that tests it: “We run this exact version. Is it fully supported, and what changes the day Apache marks that line inactive?”
3. What are your response times by severity, and is 24/7 staffed by engineers?
A headline response number means very little on its own, and comparing two of them is worse. One vendor in this market publishes a 15 minute emergency response and states explicitly that this covers first response only. Another publishes a slower first response alongside an actual target of 72 hours to a solution or workaround. The faster number is attached to the weaker promise.
So separate the two commitments before you compare anything. A first response is an acknowledgement. A resolution target is a commitment to fix.
Very few vendors in this market publish a severity grid at all. The ones that do break response down by severity band and by coverage window, so an urgent issue carries one target on round the clock cover and a slower one on business hours only. Treat a published grid as the minimum you should be given in writing, rather than something a vendor does you a favour by sharing.
What a strong answer sounds like: severity definitions in writing, separate first response and resolution targets for each band, time zone coverage, a named escalation path, and what the credit is actually worth when a target is missed.
The follow up that tests it: “Walk us through a broker outage at 3am with message loss in play. Who picks it up, what can they do in the first hour, and when does a senior engineer get involved?”
4. How do you handle CVEs, and will you backport a fix we cannot upgrade to?
This is the sharpest question on the checklist, because it has an external deadline attached to it.
Under PCI DSS 4.0.1, requirement 6.3.3 gives you one month from release to install critical security patches. Requirement 12.3.4 obliges an annual review confirming your technologies are not end of life. If you are in payments, the question of who produces a fix for a version you cannot upgrade is already on an audit clock, which makes your upgrade and patching strategy a contractual matter rather than an internal one.
The history here is unforgiving. CVE-2023-46604, a remote code execution flaw in the OpenWire protocol, was scored 9.8 by NVD and 10.0 by Apache itself. Exploitation attempts were observed on the day of public disclosure, and the flaw was used to deliver HelloKitty, LockBit and TellYouThePass ransomware. Three days after disclosure, roughly 3,300 of the 7,000 internet exposed ActiveMQ instances the Shadowserver Foundation counted were still vulnerable. A second flaw, CVE-2026-34197, reached CISA’s Known Exploited Vulnerabilities catalogue on 16 April 2026, with exploitation attempts observed two days before it was listed.
Note what that last detail means in practice. A patching process keyed to the CISA catalogue is already running late.
Backporting is where vendors diverge most. Some ship signed builds with backported fixes for older lines. At least one large open source support provider supports ActiveMQ generally while excluding it entirely from the long term support catalogue that covers end of life versions, which means no backports there at all.
What a strong answer sounds like: a stated triage window from CVE publication, direct customer notification, analysis against your exact deployment, and a written commitment on backported builds naming the lines they cover.
The follow up that tests it: “Show us what you sent customers during CVE-2023-46604 and CVE-2026-34197, and how long after publication it went out.”
Running a Broker Version You Cannot Upgrade Yet?
5. Do you support our deployment model?
The broker is rarely the whole problem. Persistent volume behaviour, pod scheduling, network policy, load balancers and storage layer faults all surface as broker symptoms, and a vendor who only reads activemq.xml will stall there. If you run brokers in containers, our guide to ActiveMQ on Kubernetes shows how much of that surface sits outside the broker process.
Cloud managed options carry their own constraints worth raising early. Amazon MQ for ActiveMQ currently supports only the 5.19 and 5.18 engine versions, offers no 6.x option, and makes no mention of Artemis anywhere in its version documentation. When a version reaches end of support, AWS automatically upgrades brokers within 45 days during your maintenance window. That is a meaningful difference from a self managed broker, where nothing forces the change.
What a strong answer sounds like: named coverage for your actual environment including the storage and networking layer, not only the broker process.
The follow up that tests it: “Who owns the incident when the broker is healthy but Kubernetes storage or networking is dropping client connections?”
6. Can you take us through an upgrade and an ActiveMQ to Artemis migration?
Treat any vendor offering this as open ended time and materials consulting with caution. A credible migration offer has a defined shape to it.
The work is larger than most estimates allow, and the reasons are documented rather than speculative. The two brokers use incompatible message stores, so you cannot point Artemis at an existing KahaDB directory. Configuration schemas differ with no automated translator between them. Every Camel route touching the broker changes components. Virtual topics and composite destinations do not map cleanly onto Artemis addressing. JMX management trees and metric names differ, so dashboards, alerts and runbook scripts all need rebuilding, which is routinely the most underestimated line in a migration plan.
One structural fact about this market is worth knowing before you ask. Some of the largest commercially supported distributions in this broker family are built on Artemis across every release, with no supported commercial build of ActiveMQ 5.x or 6.x on offer at all. Their published lifecycles can also be short, with long term support running two years per release and anything outside that track receiving no CVE fixes once superseded. If you intend to stay on your current broker for longer than that, confirm the vendor can actually support it rather than assuming a migration is optional.
What a strong answer sounds like: a current state assessment, a client and protocol compatibility analysis, a message store transfer plan, parallel run and rollback criteria, and performance baselines taken before and after cutover.
The follow up that tests it: “Is migration scoped at a fixed fee or billed hourly, and what is the rollback plan if throughput regresses after cutover?”
7. Do you bring monitoring, or only a ticket queue?
Ticket based support begins after something has already gone wrong. The useful question is what the vendor gives you before that point, which is where monitoring and alerting setup stops being a nice to have.
This matters more than it sounds. Platform engineers reviewing ActiveMQ publicly report disabling the bundled admin console as inadequate, being unable to see actual message counts, and finding audit logging through Jolokia thin. A support contract that leaves you blind during the incident you are paying to survive is a poor trade.
What a strong answer sounds like: broker health and queue depth visibility, consumer lag and message age alerting, memory and journal and disk headroom, and integration with whatever observability stack you already run.
The follow up that tests it: “Which ActiveMQ specific conditions do your alerts catch that a CPU and memory dashboard would miss?”
Would You Know a Broker Was Failing Before Your Users Did?
8. Do you cover Apache Camel and the integrations around the broker?
A large share of incidents filed as broker problems are not broker problems. Route misconfiguration, consumer concurrency, transaction boundaries, dead letter queue handling and incompatible client libraries all present as messaging failures.
If Camel routes produce or consume through your broker and the contract excludes Camel, you have bought a vendor who can tell you the broker is fine. That is a long way from a vendor who can tell you what is wrong. Confirm that Apache Camel support is inside the contract rather than an adjacent service line.
What a strong answer sounds like: named coverage of Camel 4.x routes, the specific Camel component your broker version uses, client library and protocol issues, and dead letter queue and retry behaviour.
The follow up that tests it: “If messages are consumed but never processed, how do you work out whether that is the broker, the route, the client or our application?”
9. Can you support our compliance obligations?
Compliance is the emptiest column in this market. Of the vendors we reviewed, none publishes a SOC 2 or ISO 27001 attestation tied specifically to its ActiveMQ support practice. If you are regulated, you will be extracting these commitments in the contract rather than finding them on a website, and you will want your own security hardening baseline documented before the conversation starts.
Two regimes make this concrete right now. DORA, the EU Digital Operational Resilience Act, has applied to financial entities since 17 January 2025 and requires a register of contractual arrangements with ICT third party providers, including contract dates, annual value, governing law and termination provisions. A broker running critical payment flows with no support contract has no entry to register. PCI DSS adds the patch window and the annual end of life review described in question four.
What a strong answer sounds like: audit logging of support access and administrative actions, documented patch records with timestamps, change management evidence, breach notification terms, and support for restricted or air gapped environments where you need it.
The follow up that tests it: “What evidence pack can you hand our auditor after an emergency patch?”
10. How is pricing structured, and what does it cost to leave?
Vendors meter this differently, which makes quotes genuinely hard to compare. Published models include per incident, per server, per core on the Java process running the broker, and an annual fee scaled by clusters, nodes and environments. Normalise every quote onto one denominator before you negotiate.
Few vendors publish a price at all, so you are comparing blind. The figures that do exist put business hours cover for a small estate in the low thousands a year, and round the clock cover with named engineers well into five figures. If a quote lands far below that while still promising 24/7, ask who is staffed overnight and what they are authorised to do.
The other half of the cost shows up on the day you leave, and nobody in this market addresses it publicly. If you have been buying backported patches, those builds come from the vendor’s private repository rather than from Apache. When the contract ends your access ends with it, and your brokers revert to community releases that still carry the vulnerability you were paying to have fixed. That is a migration you did not plan and did not budget for.
What a strong answer sounds like: a clear billing unit, what is included versus billed as professional services, renewal increase caps, and written terms on what you keep at termination.
The follow up that tests it: “If we leave, what happens to patched binaries already running in production, and do we retain our configuration documentation?”
The One Question Almost Nobody Asks
Here is the question that shows up in real production failures and on no vendor’s website.
Search the Apache mailing list and issue tracker and one pattern recurs. Brokers running KahaDB, the message store ActiveMQ uses on disk, sitting on NFS or shared network storage, hitting journal corruption after a storage event, and then failing to recover. In one case from the users list, recovery ran for roughly two and a half hours before failing on a corrupt record, and the only route back to a running broker was discarding around 8.7 million stored scheduled messages. The thread ends with diagnosis and no confirmed fix. Storage choice is the root of it, which is why our high availability architecture guide treats shared storage as a design decision rather than a detail.
So ask this one directly.
| “Our store is this size and sits on this storage. If the journal corrupts, how long does recovery take, and can you recover the messages rather than discard them?” |
A vendor who has done this work will answer with recovery times, storage configurations they refuse to support, and the mechanics of extracting messages from a damaged store. A vendor who has not will talk about backups.
Scoring the Answers
Score each of the ten questions on a simple three point scale and compare totals across vendors.
| 0 | Vague, sales led, or nothing you could put in a contract |
| 1 | Partial capability, significant caveats, or heavy escalation elsewhere |
| 2 | Specific, demonstrable, and willing to go in the contract |
Resist weighting the questions by percentage. The weighting that matters depends entirely on your situation. A payments team on an older broker version should treat questions two, four and nine as close to disqualifying. A team mid migration should weight six and eight. A team where one engineer holds all the broker knowledge should weight one and three.
Red Flags in a Support Proposal
- Claims to support all messaging technologies without naming ActiveMQ versions or engineers
- An SLA that guarantees acknowledgement and commits to nothing beyond it
- No written policy on versions Apache has marked inactive, and no backport commitment
- Kubernetes support that stops at the broker process and excludes storage, networking and failover
- Migration offered only as open ended time and materials
- No direct CVE notification, so you find out from a news article
- Apache Camel and client side issues written out of scope
- Nothing in writing about what you keep when the contract ends
Choosing Well Comes Down to Specificity
A capable ActiveMQ support vendor will answer these questions with version numbers, dates, named people and contract language. A weaker one will answer with adjectives.
None of the ten questions above is difficult to ask. They are simply rarely asked in order, and vendors are not incentivised to volunteer the answers. Take them into your next three conversations, score them the same way each time, and the shortlist tends to make itself.
Put These Ten Questions to Us
Frequently asked questions
No. Apache support is volunteer community support through mailing lists and the issue tracker, with no response commitment attached. Apache’s site lists commercial providers separately, and that listing is a self service entry rather than an endorsement or a quality check.
No. As of 27 October 2026, Apache lists 5.19.x as an actively supported line alongside 6.3.x and 6.4.x, and all three received releases on that date. The lines marked inactive are 5.18.x and older, plus 6.0.x, 6.1.x and 6.2.x. Apache publishes no sunset date for 5.x, so any specific date you are quoted is a vendor interpretation rather than project policy.
Some will and some will not, and the difference is rarely visible on a vendor website. At least one major open source support provider supports ActiveMQ generally while excluding it from the long term support catalogue that covers end of life versions. Ask for the commitment in writing, with the specific broker lines named.
Not automatically. Apache Camel support is a separate scope decision, and it matters because Camel uses three different components depending on your broker. ActiveMQ 5.x uses camel-activemq, ActiveMQ 6.x uses camel-activemq6, and Artemis users are directed to the generic JMS component.
There is no industry standard, and published figures range from 15 minutes to a next business day depending on severity and tier. What matters more than the number is whether it commits to a first response or to a resolution. Ask for both, defined separately, for every severity band.
This is the question the market does not answer publicly. If your vendor supplied backported binaries from a private repository, you lose access to them at termination and your brokers revert to community releases. Settle this in the contract rather than at renewal.