Should you stay on ActiveMQ Classic or move to Artemis?
If your ActiveMQ 5.x or 6.x deployment works today, with KahaDB or JDBC persistence and a network of brokers carrying your load, stay on Classic and make the change that keeps risk lowest. Consider Artemis when a specific problem you already have maps to its strengths: a non-blocking architecture under heavy persistence load, replication or asynchronous mirroring for disaster recovery, or a protocol-agnostic addressing model that your current JMS-based model constrains. A wish for a newer product is not a migration case on its own. Start the decision with four drivers. First, protocol mix: Classic already supports AMQP, MQTT, HTTP/WebSocket and STOMP alongside JMS, while Artemis supports AMQP 1.0, MQTT 3.1.1, MQTT 5 and STOMP, so list which protocols and client libraries your producers and consumers actually use before assuming either broker is a better fit. Second, clustering and disaster recovery: map your current high availability design, which for Classic relies on shared storage, against the Artemis options of shared storage or network replication, and write down your recovery objectives in your own terms. Third, client library dependencies: check whether your applications depend on Classic-specific features such as virtual destinations, composite destinations or message groups, and whether your .NET or C++ clients use the Apache.NMS.ActiveMQ or CMS libraries, since those are the libraries you would need to re-verify or replace.
The fourth driver is project status. Artemis became its own Apache project after the ActiveMQ PMC voted to establish it, announced on November 19, 2025. That separation matters for roadmap and support planning: confirm with your vendor or internal platform owner which project, release line and security advisory feed you will follow after the move, and check the current Artemis release notes, such as the 2.55.0 OIDC enhancements, against your identity requirements. Classic continues on the 6.2.x series and the 5.19.x maintenance line, so confirm which line your organization is approved to run and how long you expect to stay on it. Before you commit, run a short proof of concept on a copy of your real workload. Measure persistence throughput, failover behavior and the client behavior of your most sensitive applications, and review the Artemis examples to see how your features map. Ask DeployOpen or your own engineers to document the rollback path, because a move that cannot be reversed is a larger decision than a move that can.
Which broker fits which scenario
This table compares the situations where staying on ActiveMQ Classic or moving to Artemis is the better fit, and where the answer is to test first. Read each row for the condition that makes the advantage matter, since most of these differences only decide the outcome when that condition applies to your estate.
| Scenario | Better fit | Why and when it matters |
|---|---|---|
| Stable JMS estate with existing consumers and producers | Stay on Classic | Classic fully supports JMS 1.1 and partially supports JMS 2.0 and Jakarta Messaging 3.1. If your applications depend on Classic-specific behavior, a move adds application testing that the broker change itself does not require. |
| Spring applications that embed the broker | Stay on Classic | Classic can be embedded in Spring applications, and it offers message groups, virtual destinations, wildcards and composite destinations. Confirm that your embedding pattern and those features carry over before planning a move. |
| Apache.NMS, CMS or other ActiveMQ client libraries in use | Stay on Classic | The ActiveMQ project maintains the Apache.NMS.ActiveMQ client for .NET and a CMS client for C++. If these clients are central to your stack, confirm which Artemis client libraries cover the same languages and features. |
| KahaDB or JDBC persistence already tuned and proven | Stay on Classic | Re-tuning persistence on a new broker is a real cost. If your current store meets throughput and recovery targets, the case for moving rests on other needs in this table. |
| Disaster recovery needs asynchronous mirroring between sites | Move to Artemis | Artemis lists asynchronous mirroring for disaster recovery. This matters when you need a second site kept current without synchronous replication across the link. Confirm the recovery procedure and the exact topology with the Artemis documentation. |
| Load distribution across a cluster of brokers | Move to Artemis | Artemis lists flexible clustering and data-driven load balancing. This matters if Classic networks of brokers are hard to size or balance for your traffic pattern. Test the balancing behavior under your real message mix. |
| Low-latency persistence with a journal | Move to Artemis | Artemis offers journal implementations for low-latency persistence alongside JDBC. This matters when your KahaDB or JDBC store is the bottleneck. Benchmark both journal and JDBC options on your hardware. |
| OIDC or modern authentication requirements | Move to Artemis | Artemis 2.55.0 added OIDC enhancements, according to the Artemis website. This matters if your security policy requires OIDC integration. Confirm the exact configuration and supported identity providers with the Artemis release notes. |
| Mixed protocols, MQTT 5 or a new integration surface | Test first | Artemis supports AMQP 1.0, MQTT 3.1.1, MQTT 5 and STOMP, while Classic also supports AMQP, MQTT, HTTP/WebSocket and STOMP. Protocol feature gaps differ per client, so run your own clients against both brokers before deciding. |
What the Artemis project split means for Classic users
The first thing to settle is that ActiveMQ Classic and Apache Artemis are no longer one project. The ActiveMQ PMC voted to establish Artemis as its own Apache project, and that decision was announced on November 19, 2025. For a Classic team, this means the broker you run, its security fixes, its release cadence and its roadmap are set by the ActiveMQ project, while Artemis changes are decided and shipped separately. Treat any plan that assumes Artemis features will appear in Classic, or the reverse, as unverified until a project confirms it.
The release lines that apply to a Classic deployment are the 5.19.x line and the 6.2.x line. ActiveMQ 6.2.0 was released on November 14, 2025 and started the 6.2.x series. The 5.19.x series continues with maintenance releases, including 5.19.11 on September 2, 2026, and the latest 6.2.x maintenance release noted in the project's releases is 6.2.10 on September 22, 2026. Check which line your current installation sits on, because moving from 5.x to 6.x is a version change with its own compatibility review, not a routine patch. On the Artemis side, 2.56.0 was published on August 27, 2026 and 2.57.0, a bug fix release, followed on September 9, 2026. Confirm the current release and version support windows for both projects on their news and release pages before you set a migration date.
Ask each project directly about support windows and roadmap for your specific line, including how long 5.19.x maintenance will continue and whether security fixes will be backported. Ask Artemis maintainers how they handle compatibility for clients that use the JMS 2.0 and JMS 1.1 APIs and for any Classic-specific features your applications depend on, such as network of brokers or KahaDB configuration. Record the answers in your change plan. A written answer from the project, dated and tied to a version number, is far more useful to a CISO or architect than an assumption carried over from the 2025 announcement.
How KahaDB, JDBC and networks of brokers differ from Artemis's non-blocking design
Classic and Artemis both persist messages, survive broker failure and spread load across nodes, but they make different choices about where messages live, how failover happens and how brokers find each other. Each card below marks one of those choices and the checks to run before you decide whether a move changes your operations.
Classic persistence with KahaDB and JDBC
ActiveMQ Classic offers KahaDB and JDBC persistence. KahaDB keeps message data in local journal and index files on the broker host, so disk layout, sizing and backup are broker-level tasks. JDBC moves storage into a relational database, which shifts backup, failover and tuning to the database team. Check which store your brokers use today, how large the message store grows under peak backlog, and who owns restores when a store is damaged.
Classic high availability on shared storage
Classic high availability relies on shared storage: several broker instances point at the same store, and one takes over when the active instance fails. Failover speed and correctness depend on that shared volume staying available and on lock handling between instances. Confirm how your storage vendor handles locks and fencing, test a forced failover in a non-production environment, and record how clients reconnect after takeover.
Classic networks of brokers for load distribution
Classic can connect brokers into a network so that consumers on one broker receive messages produced on another. This spreads load, but each broker keeps its own store and the topology is configured by hand. Operations teams need to track which brokers forward to which, how duplicate or looping demand is prevented, and how a single broker outage affects routing. Map your current network topology before you assume it will carry over unchanged.
Artemis non-blocking architecture
Artemis is built around a non-blocking design and a protocol-agnostic addressing model, so a message can be consumed through JMS, AMQP, MQTT or STOMP without a separate queue definition per protocol. For operators this changes thread and resource tuning, and it changes how you read broker metrics. Check which protocols your clients use today, whether any client depends on Classic-specific behavior such as virtual destinations, and run load tests against the planned configuration.
Artemis journal implementations alongside JDBC
Artemis offers journal implementations for low-latency persistence as well as JDBC. The journal is a broker-managed log on disk, so storage layout and disk performance become the first capacity questions, while JDBC remains available when a database-backed store fits your standards. Decide which store fits your recovery process, confirm whether your existing backup tooling covers journal files, and test restore times with realistic message backlogs.
Artemis flexible clustering with asynchronous mirroring
Artemis supports flexible clustering to distribute load and asynchronous mirroring for disaster recovery, with data-driven load balancing across cluster members. Asynchronous mirroring means a secondary site can lag the primary, so the recovery point depends on replication delay. Define your recovery point and recovery time objectives, confirm how the mirror behaves during a network partition, and monitor replication lag as a standing alert.
Protocol, JMS and resilience features side by side
This table compares ActiveMQ Classic and Artemis on licensing, protocols, JMS support, addressing, persistence, high availability, clustering and developer-facing features. Where the supplied research does not confirm a detail, the cell tells you what to verify before deciding, so treat the dashes and confirmation notes as open questions for your own proof of concept.
| Capability | ActiveMQ Classic | Artemis |
|---|---|---|
| License | Apache 2.0 | Apache 2.0 (apache/artemis repository) |
| Protocols | AMQP, MQTT, HTTP/WebSocket and STOMP alongside JMS | AMQP 1.0, MQTT 3.1.1, MQTT 5 and STOMP |
| Jakarta Messaging and JMS support | Partial for Jakarta Messaging 3.1 and JMS 2.0; full for JMS 1.1 and J2EE 1.4 or later | Full for Jakarta Messaging 3.1, JMS 2.0 and JMS 1.1 |
| Addressing model | JMS-based addressing model | Protocol-agnostic addressing model; confirm mapping of your JMS destinations to addresses |
| Persistence | KahaDB or JDBC persistence | Journal implementations for low-latency persistence, plus JDBC; confirm journal sizing for your volumes |
| High availability | High availability using shared storage | High availability using shared storage or network replication |
| Clustering and disaster recovery | Networks of brokers for distributing load; confirm disaster recovery approach for your topology | Flexible clustering, data-driven load balancing and asynchronous mirroring for disaster recovery |
| Message groups, virtual and composite destinations | Supported, including wildcards and composite destinations | Confirm equivalent constructs and migration path for your destination model |
| Spring embedding | Can be embedded in Spring applications | Confirm embedding and Spring integration against your framework version |
| Client languages | Java clients, with Apache.NMS.ActiveMQ for .NET and a CMS client for C++ | Java, JavaScript, C, C++, Python and .NET |
What each broker licenses and where releases come from
Apache ActiveMQ Classic is the broker in the Apache ActiveMQ project, and it is licensed under Apache 2.0. For a team running 5.x or 6.x, the license question is usually settled by legal review of notice and attribution duties, which you should confirm with counsel. The release question matters more for planning. The project runs two lines side by side, and the line you choose sets your upgrade path.
- Apache 2.0 license. The ActiveMQ README and project pages identify the broker as Apache 2.0 licensed, and the supplied material lists no commercial edition of Classic.
- 5.19.x maintenance line. Maintenance releases continue on this line, with 5.19.11 published on September 2, 2026. Teams that cannot move to 6.x soon will track fixes here.
- 6.2.x line. The 6.2.x series started with 6.2.0 on November 14, 2025, and 6.2.10 followed on September 22, 2026. Confirm that your JMS clients, Spring versions and other dependencies support the 6.x line before you commit.
- Client components. The project maintains Apache.NMS.ActiveMQ for .NET and a CMS client for C++. These matter if producers or consumers are outside Java.
- Download source. Release notes and artifacts are published on the ActiveMQ releases page on GitHub, which is where you should watch for security fixes on your line.
Confirm which release line your application stack and client libraries support, then schedule a review for each new maintenance release on that line.
Apache Artemis is now its own Apache project. The ActiveMQ PMC voted to establish it that way, and the decision was announced on November 19, 2025. The Artemis repository is licensed under Apache-2.0, the same license as Classic, so the license terms match at the source level. The distribution path is different, and that difference belongs in your intake process, your scanners and your change records.
- Apache-2.0 repository. The apache/artemis repository carries the Apache-2.0 license. Treat the source license and the binary distribution as separate items in your compliance file.
- Binaries from the Artemis website. Releases are distributed from the Artemis home page. Point your artifact mirror, vulnerability tracking and approval workflow at that source.
- Recent releases. Artemis 2.55.0, published on June 29, 2026, added OIDC enhancements and a
sslHandshakeTimeoutURL parameter, which are relevant if you integrate with an identity provider. Artemis 2.56.0 followed on August 27, 2026, and 2.57.0, a bug fix release, on September 9, 2026. - Examples repository. The apache/artemis README points to more than 90 examples of client and broker features. They are a practical reference for building test cases during a migration from Classic.
- Client languages and protocols. Clients exist for Java, JavaScript, C, C++, Python and .NET, and the broker supports AMQP 1.0, MQTT 3.1.1, MQTT 5 and STOMP.
Confirm which Artemis version your identity provider and client libraries require, and record the download source for each artifact in your software bill of materials.
Neither project lists a paid edition in the material used for this page, so the license fee for the open-source broker is not the main cost. The main costs are your staff time, the infrastructure you run the broker on and any third-party support contract you decide to buy. Support for either broker, where it exists, comes from third parties rather than from the Apache projects themselves. Ask each provider to name the versions it covers before you rely on it.
- No paid edition identified. This page does not identify a commercial edition of ActiveMQ Classic or Artemis. Confirm that with the projects and with any vendor you consider before a procurement decision.
- Third-party support scope. Ask which broker versions, client libraries and protocols the provider covers, and whether it will handle security patches for your exact release line.
- One-time costs. Migration testing, client updates and translation of broker configuration are one-time efforts. Their size depends on how many applications use the broker and how many features those applications rely on.
- Recurring costs. Applying maintenance releases, retesting clients and watching release channels recur for as long as you run the broker.
- What to request in a quote. Ask for a written scope that names both broker versions, the protocols and clients in use and who owns each patch. DeployOpen plans, implements, hardens and supports self-hosted platforms inside your infrastructure, and it prices work from a written scope.
Before you commit to either broker, write down who answers when a security fix ships for your exact version.
What drives the running cost of each broker
This table breaks down the cost components of running ActiveMQ Classic and Artemis, who is paid for each one, and which costs are one-time or recurring. Read it as a checklist for comparing your own environment and for asking vendors and implementation partners what a quote must include.
| Cost driver | ActiveMQ Classic (5.x or 6.x) | Artemis |
|---|---|---|
| Storage for persistence | KahaDB message store on local or shared disk. Size and IOPS follow message volume and retention. Confirm the sizing guidance for your release line. | Journal implementations for low-latency persistence, plus JDBC as an alternative. Ask which journal type your message pattern needs and what disk the journal requires. |
| Database for JDBC persistence | JDBC persistence adds a relational database to operate, back up and patch. Recurring cost tracks database licensing or hosting, plus the DBA time to tune it. | JDBC is supported as an option, so the same database cost applies only if you choose it. The journal default avoids this cost; confirm which setup your design uses. |
| Network links for mirroring and clustering | Networks of brokers distribute load across links that must be sized, monitored and secured. High availability relies on shared storage, which is a recurring infrastructure line. | Flexible clustering, network replication for high availability and asynchronous mirroring for disaster recovery each add inter-site links. Ask which of these your topology needs and the bandwidth it implies. |
| Skills for tuning and operations | Teams usually already know JMS tuning for Classic, which lowers onboarding cost. Recurring cost comes from keeping that knowledge current across releases. | Artemis configuration (addressing model, journal, clustering, redistribution) is a new set of settings for most Classic teams. Expect a one-time learning cost, then a smaller recurring one. |
| Upgrade effort across release lines | Upgrades within 5.19.x maintenance releases or onto 6.2.x each need compatibility testing against your clients and configuration. Ask the partner which line they will support and for how long. | Artemis follows its own release cadence, including bug fix releases such as 2.57.0. Each upgrade needs regression testing of your addressing and client setup. Ask for the support window in writing. |
| Monitoring and support sources | Monitoring is built from broker statistics and your own tooling. Commercial support, if you buy it, is a separate recurring contract. Ask what the quote covers after go-live. | Monitoring and support follow the same pattern: your tooling plus any paid support you contract separately. Ask which support sources the project and vendors you use provide, and for what term. |
| Client migration effort | Keeping JMS clients on Classic avoids rework. Moving to Artemis is one-time work on clients, selectors, destinations and any Classic-specific features such as virtual or composite destinations. | Protocol-agnostic addressing changes how destinations map to clients. Migration is one-time work, but it recurs for each new application onboarded. Ask the partner for a client inventory before quoting. |
How to move from Classic to Artemis without a big-bang cutover
This sequence moves a Classic estate to Artemis in controlled stages, so each destination, client group and failover path is proven on Artemis before traffic leaves Classic. The output is a retirement decision backed by evidence rather than a single switch-over date.
Inventory destinations, clients and protocols
Your platform or messaging team lists every queue and topic, every producer and consumer application, the protocols each one uses (JMS, AMQP, MQTT, STOMP or HTTP/WebSocket) and any Classic-only features in use, such as virtual destinations, composite destinations, message groups, wildcards, network of brokers links and persistence settings. Record the owner of each client and its release cadence. This step is done when every client appears in one inventory with its protocol and feature dependencies, and the owners have signed off on it. Ask your vendor or integrator to confirm the Classic version you run, since 5.x and 6.x carry different maintenance schedules.
Map Classic features to Artemis equivalents
For each Classic feature in the inventory, the architect identifies the Artemis mechanism that fills the same role and writes a short mapping note. Where no direct equivalent exists, the team records a redesign option, such as changing addressing or moving routing logic into the client. Verify each mapping with a test in a non-production environment that exercises the actual message flow, including ordering and redelivery behavior. The step is done when every feature has a mapping and a passing test, or a documented decision to drop it. Consult the Artemis documentation and your own tests, not assumptions carried over from Classic.
Choose the persistence and high availability design
The architect selects the Artemis journal approach and the high availability model, comparing the options the Artemis site describes: shared storage or network replication for high availability, and journal implementations versus JDBC for persistence. Compare this against your current KahaDB or JDBC setup and your recovery objectives. The output is a written design that names the storage, failover mode and where data lives, reviewed by operations and security. Confirm with the vendor how the chosen design behaves during a network partition before you commit to it.
Build failover tests and monitoring on Artemis
Operations rebuilds what Classic provided in its own tooling: broker configuration as code, metrics and alerts, log collection and dashboards for queue depth and consumer lag. The team then runs scripted failover tests, stopping the primary node and confirming that clients reconnect and no acknowledged messages are lost. This step produces a runbook and a test record for each failure case. It is done when the tests pass repeatedly and the on-call team has reviewed the runbook. Budget time for this step explicitly, because it is work you do again rather than something migrated for you.
Run both brokers in parallel on a bridge path
Deploy Artemis beside Classic and connect them through a bridge or a shadow path, so a copy of selected traffic flows to Artemis while Classic keeps serving production. Start with low-risk queues and a single non-critical producer. Compare message counts, ordering, latency and error rates on both sides, and record any gaps. Treat each gap as a defect to fix or a documented behavior change to accept. The step is done when parity holds for the agreed traffic over a period your team sets in advance. Confirm the bridging mechanism with your vendor, because Classic network of brokers and Artemis clustering are not interchangeable.
Migrate clients in waves
Move client applications in groups, starting with the least critical and ending with the most sensitive. For JMS clients, the code often changes little because Artemis supports JMS 2.0 and 1.1 and full Jakarta Messaging 3.1, but configuration such as connection URLs, credentials and destination names still changes, and each wave needs its own test. Keep a switch that points a client back to Classic. Each wave closes when its owners confirm that the application runs correctly, its alerts fire, and its failover test passes. In-flight messages stay on Classic until drained, so plan the drain for each queue.
Prove rollback, then retire Classic
Before you switch off Classic, the team rehearses a rollback for each wave: pointing clients back, draining Artemis queues, and confirming no messages are duplicated or lost. The rehearsal is documented with timings and outcomes recorded by the team. Only after the rollback is proven for every wave does the team decommission Classic, archive its configuration and retain its persistence data for the period your records policy requires. Confirm retention and audit obligations with your compliance lead before deletion. The sequence ends when Classic is off, the rollback record is filed, and the runbooks name Artemis as the only broker.
Where Artemis and Classic projects usually run long
Projects usually run long in the places the migration plan treats as settled: the configuration and storage tuning of the current Classic broker, the addressing and clustering design on Artemis, and the testing of every client that touches the broker. Expect the Classic side to take longer than the Artemis side when KahaDB or JDBC persistence has been tuned by hand over years, because those settings are often undocumented and each one has to be mapped to an Artemis equivalent. Before committing to a timeline, ask your team to export the live activemq.xml from every broker, list each persistence, memory and destination policy, and confirm which of them have an Artemis counterpart and which need a redesign.
Artemis effort concentrates in the addressing model and clustering setup. Artemis uses a protocol-agnostic addressing model, so queues, topics and their routing have to be designed deliberately rather than carried over from Classic's JMS-based naming. Confirm how your Classic virtual destinations, composite destinations and wildcards map to Artemis addresses, and whether your current networks of brokers need to become Artemis clustering or a different load pattern. Client compatibility testing is the other large block. Test every JMS 1.1 and JMS 2.0 client, every Spring embedding, and every non-JMS client that speaks AMQP, MQTT or STOMP, because each one can behave differently against the new broker. Message selectors deserve particular attention, since custom selectors written against Classic may need to be rewritten or re-verified.
Projects most often overrun in four places: undocumented consumers that read from queues nobody listed in the design, Spring applications that embed the broker or rely on Classic-specific configuration, custom selectors that behave differently after migration, and failover testing that was never performed on the old platform. Disaster recovery drills need their own time. Artemis offers asynchronous mirroring for disaster recovery and shared-storage or network-replicated high availability, but your team must test the chosen mode end to end, including failback. Ask the vendor or your own platform team to confirm which Artemis version you will run, check the current maintenance cadence on the Apache Artemis home page, and agree a written test plan before accepting any date.
Questions buyers ask before moving from ActiveMQ Classic
Is Artemis a drop-in replacement for ActiveMQ Classic?
No, treat it as a migration project rather than a configuration swap. Artemis is a separate broker with its own non-blocking architecture, its own journal and addressing model, and its own configuration files, so Classic settings such as KahaDB, network of brokers topologies and virtual destination patterns need to be re-mapped rather than copied. Both brokers support JMS 2.0 and JMS 1.1 on the Apache project sites, which helps client code, but the broker-side behavior you depend on must be verified in a test environment. Ask your engineers to list every destination type, persistence setting and clustering rule in use today, then check each one against the Artemis documentation before deciding the scope.
What drives the cost of moving from ActiveMQ Classic to Artemis?
The main cost is people time, because both the broker and the client applications change. Costs split into one-time work (inventory of destinations and clients, configuration mapping, test harness build, cutover rehearsal, and documentation) and recurring work (operating the new broker, patching, and monitoring). The biggest drivers are the number of client applications, how deeply they use Classic-specific features such as virtual destinations, composite destinations and networks of brokers, and how strict your uptime and data retention requirements are. Both Apache projects are open source under Apache-2.0, so there is no license fee to move, but ask any vendor or partner for a written quote that lists each deliverable, the environments covered and who performs the testing.
How long does a migration from ActiveMQ Classic take?
The duration depends on scope, and no supplied source gives a reliable timeline, so ask for one tied to a written scope. The schedule is mostly driven by how many applications connect to the broker, how many use Classic-specific features, and how much coexistence you need during cutover. Your team should provide access to a staging environment that mirrors production topology, current broker configuration files, a list of message flows and their owners, test message volumes, and a change window approved by application owners. Plan for a period when both brokers run side by side, because that is usually where the risk sits.
Can our own engineers migrate from ActiveMQ Classic without a consultant?
Yes, many teams do this in-house, provided they have people who know the JMS clients, the current broker configuration and the messaging traffic patterns. The work is manageable when the topology is simple and the client set is small, and it becomes harder with networks of brokers, custom persistence settings, or many independently owned applications. An outside partner is most useful for independent testing, cutover rehearsal and documentation. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside your own infrastructure under a written, fixed scope, so you can decide which parts to keep in-house and which to outsource.
Does Artemis support our Spring or .NET clients?
Check your client libraries against the exact versions you run, because support differs by client stack. The Artemis project lists Java, JavaScript, C, C++, Python and .NET clients, and it supports the AMQP 1.0, MQTT 3.1.1, MQTT 5 and STOMP protocols. Classic is distributed with Spring-friendly embedding and the ActiveMQ project separately maintains the Apache.NMS.ActiveMQ client for .NET. Before you commit, build a small test for each client type that sends, receives, uses transactions and exercises any custom selectors or message groups you rely on, and record which client library versions passed.
What happens to ActiveMQ Classic 5.x support if we stay?
Classic 5.x continues to receive maintenance releases, and the most recent 5.x release in the supplied sources is 5.19.11, published on September 2, 2026. The 6.x line began with 6.2.0 on November 14, 2025, and 6.2.10 was published on September 22, 2026. The ActiveMQ project has stated that 5.19.x maintenance continues, but it is not a promise of indefinite support, so check the ActiveMQ news page and the release notes before setting a long-term plan. Ask your security and compliance teams to confirm how they will track patches for whichever line you stay on, and record that decision alongside your upgrade calendar.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For ActiveMQ Classic vs Artemis, we start by mapping your current broker topology, persistence and client protocols before recommending whether to stay, move or run both.
How we scope
- Written scope covers broker inventory, client protocols, persistence and network-of-brokers dependencies before any work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing up front.
- Scope can separate a stay-on-Classic hardening project from a staged migration to Artemis.
How we build
- We configure the chosen broker, including KahaDB or JDBC persistence or Artemis journal and replication settings, inside your environment.
- We test client compatibility, JMS behavior, failover and recovery against your own applications.
- Where needed, we build bridges or parallel running so producers and consumers can move in stages.
How we hand over
- You receive configuration, runbooks and architecture documentation covering the broker deployment and its failure modes.
- Handover includes backup and restore procedures tested against the broker you actually run.
- We document the compliance evidence your assessors will ask for, without issuing any audit report or certification.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version upgrades across the 5.x, 6.x or Artemis release lines as they ship.
- Ask us to confirm which support windows and release lines apply to your chosen version before you commit.
