IBM MQ Alternatives: Eight Options, and What Moves Without a Rewrite

Most lists of IBM MQ alternatives rank products by review scores. Scores say nothing about what a move will cost, because the cost depends on what your applications are written against. A Java service that reaches IBM MQ through JMS can move to another JMS provider with configuration changes and a short list of code edits. A COBOL program that calls MQPUT and MQGET cannot move anywhere without being rewritten.

This guide starts with that question. It works out which interfaces your estate uses, lists the IBM MQ capabilities that a move has to replace, and then compares eight alternatives, each with the case where it is the wrong choice. Kafka gets one section, because IBM MQ vs Kafka already covers what changes when a queue becomes a log.

Redisson is our product, and option 8 is Redisson PRO. The IBM MQ details come from IBM's documentation, product and lifecycle pages, and from the IBM MQ 10.0.1 Java client itself. Details of the other products come from their own documentation. We checked all of it in November 2026.

Why Teams Look for IBM MQ Alternatives in 2026

Teams usually start looking for an IBM MQ alternative when a bill or a deadline arrives, and in 2026 several arrived together.

IBM sells IBM MQ as a perpetual licence measured in Processor Value Units, as a monthly subscription per Virtual Processor Core, and with capacity-based pricing for some cloud options. IBM MQ Advanced, now sold as IBM MQ Advanced with AI Agents, adds Native HA with cross-region replication, Advanced Message Security and Managed File Transfer. We do not quote prices, because yours depend on your agreement with IBM, but the renewal is often where these evaluations begin.

IBM MQ 10.0, the new Long Term Support release, shipped on June 16, 2026, and IBM says it will be supported for at least five years. Base support for 9.3 ends on September 30, 2027, with extended support available until 2031, and base support for 9.2 ended on September 30, 2025. An estate on 9.2 or 9.3 faces an upgrade either way, and an upgrade is the cheapest moment to compare the alternatives.

For cloud moves, IBM offers IBM MQ as a Service, a managed IBM MQ Advanced on IBM Cloud and AWS in shared and single-tenant plans. Teams moving to Azure or Google Cloud, or standardizing on their cloud provider's own services, end up comparing it with those.

Then there is Kafka, which many organizations want as their one streaming platform. Since March 17, 2026 that choice involves IBM as well. IBM completed its acquisition of Confluent that day, and its announcement names IBM MQ among the day-one integrations, describing MQ as "trusted transactional messaging" and Confluent as "high-scale event streaming". Moving from IBM MQ to Confluent's Kafka no longer means leaving IBM.

First, Find Out What Your Code Is Written Against

IBM MQ exposes several application interfaces, and each one leads to a different migration. Count the applications on each before you compare products.

An inventory is mostly a search for:

• Java imports from com.ibm.mq.jms, com.ibm.mq.jakarta.jms and com.ibm.msg.client (JMS with IBM extensions) or of com.ibm.mq.MQQueueManager (classes for Java), and Spring properties that start with ibm.mq;
• JNDI .bindings files, and IBM MQ resource adapter definitions in application servers;
• calls to MQCONN, MQOPEN, MQPUT and MQGET in COBOL, PL/I, RPG and C;
• queues defined with BOTHRESH, TRIGGER, INITQ or PROCESS in MQSC scripts, because those settings carry behavior that the next two sections say has to be replaced.

The Eight Alternatives

Each option below is a real destination for some IBM MQ estates, and each ends with the case where it is the wrong one. Integration platforms such as MuleSoft Anypoint, Boomi and SAP Integration Suite appear on review-site lists of IBM MQ competitors. They compete with IBM's integration products, and none of them is a queue manager, so they are left out here. NATS and Apache Pulsar are covered in our Kafka alternatives guide. Neither is a JMS provider out of the box; Pulsar reaches JMS through DataStax's open-source Starlight for JMS.

1. Apache Artemis (and Red Hat AMQ Broker)

Artemis is the closest open-source match for a JMS estate. It implements Jakarta Messaging 3.1, JMS 2.0 and JMS 1.1 in full, supports XA transactions, and speaks AMQP 1.0, MQTT, STOMP and OpenWire alongside its own core protocol. It left the ActiveMQ project to become a separate Apache top-level project in November 2025, and its Maven artifacts moved to the org.apache.artemis group from version 2.50.0. It is also the base of Red Hat AMQ Broker, which Red Hat supports commercially.

For an IBM MQ estate, Artemis keeps the two things most alternatives give up. The full JMS 2.0 API means code that uses delivery delay or shared subscriptions keeps working, and XA means an application that commits a message and a database row together can keep doing so under a JTA transaction manager. Its resource adapter covers message-driven beans in application servers.

Wrong for you if: your applications use the MQI, the .NET classes or the REST API, or you want a broker someone else runs. Amazon MQ runs ActiveMQ Classic and RabbitMQ, not Artemis.

2. ActiveMQ Classic, or Amazon MQ to Run It

ActiveMQ Classic is the original ActiveMQ broker, with OpenWire, KahaDB storage and support for AMQP, MQTT and STOMP clients. Amazon MQ is the simplest way to avoid running it yourself: AWS operates ActiveMQ 5.19 and 5.18 brokers, as well as RabbitMQ, and its FAQ describes migrating applications that use standard APIs such as JMS "without rewriting messaging code".

The catch for IBM MQ code is the JMS level. ActiveMQ documents its JMS 2.0 and Jakarta Messaging 3.1 support as partial, and in 6.4.0 delivery delay, shared subscriptions and asynchronous send still throw UnsupportedOperationException at runtime. IBM MQ has supported JMS 2.0 delivery delay since version 8.0, so code that relies on it compiles against Classic and fails when it runs. The 5.x line that Amazon MQ runs is a javax.jms broker with a client-only jakarta.jms module since 5.18. Classic has also published 25 security advisories in 2026, 17 of them rated important, so keep it patched and its web console off untrusted networks. Our ActiveMQ comparison tests the JMS gaps on 6.4.0, and ActiveMQ alternatives lists which Classic release lines still get fixes and where teams already on Classic are moving.

Wrong for you if: your code uses delivery delay, shared subscriptions or asynchronous send, or you want the 6.x line as a managed service, since Amazon MQ offers 5.19 and 5.18. On AWS, code that uses those features can run on Redisson PRO over ElastiCache or MemoryDB if every client is on the JVM.

3. RabbitMQ (and Tanzu RabbitMQ)

RabbitMQ appears on many lists of IBM MQ alternatives, and it is a closer match than Kafka: both are brokers built around queues and per-message acknowledgement. In an IBM MQ vs RabbitMQ comparison, the difference that matters to a Java estate is JMS, which is not native to RabbitMQ. The open-source RabbitMQ JMS Client works over AMQP 0-9-1 with documented gaps, including no selectors on queues and no XA. Amazon MQ runs RabbitMQ too, and AWS documents JMS 1.1, 2.0 and 3.1 workloads through that client on its RabbitMQ 4 brokers, with the same gaps and without JMSProducer.setDeliveryDelay. The commercial Tanzu RabbitMQ added a JMS queue type in 4.3 and JMS topics in 4.4, supporting Jakarta Messaging 3.1 with listed exceptions, one of which is that neither transacted sessions nor XA are supported. RabbitMQ alternatives compares these routes in detail.

RabbitMQ also runs on a short community support calendar, about nine months per release series, with longer support only in Broadcom's commercial edition.

Wrong for you if: your JMS code uses transactions or XA, or relies on selectors on queues with the open-source client.

4. Apache Kafka, Confluent and IBM Event Streams

Kafka is the alternative that changes the most. It is a partitioned, append-only log rather than a queue, and it is not a JMS provider. Confluent's JMS client for Kafka implements only JMS 1.1, never supported selectors, durable subscribers or transactions, and is deprecated as of Confluent Platform 8.0. Share groups, production-ready since Kafka 4.2, added per-record acknowledgement, and Kafka 4.4 added dead-letter queues for them, so plain queue workloads fit better than they did. Selectors, message priority, delivery delay and XA with a database still have no Kafka equivalent. IBM MQ vs Kafka goes through each of them and what replacing it costs. Kafka is also not the only option here that replays: Redisson PRO's topics keep history too, for readers on the JVM and as much history as fits in memory, as described below.

Who sells it to you has also changed. IBM has its own Kafka distribution, IBM Event Streams, and since March 17, 2026 it also owns Confluent. IBM's Kafka Connect connectors for IBM MQ, a source and a sink under the Apache 2.0 licence, copy messages between MQ queues and Kafka topics, and a commercially supported version comes with IBM Event Streams and Cloud Pak for Integration entitlements. For many estates the realistic plan is both systems, connected, with each workload on the one that suits it.

Wrong for you if: the queue relies on selectors, priority, delivery delay or XA with a database, and nothing ever reads a message twice.

5. Solace Platform

Solace's event brokers come in the same range of forms as IBM MQ: software, hardware appliances, and a managed service in Solace Cloud. Besides JMS, they speak Solace's own SMF protocol, AMQP 1.0, MQTT 3.1.1 and REST. Solace's JMS API is available in both the javax.jms and jakarta.jms namespaces, and its documentation states that "both namespaces provide the same JMS 1.1 functionality."

That matters for IBM MQ code written to JMS 2.0. The simplified API built on JMSContext, delivery delay and shared subscriptions all arrived in JMS 2.0, and in Solace's Jakarta client 10.30.2, createContext() throws UnsupportedOperationException, so code that uses the JMS 2.0 API needs rewriting to the 1.1 API before a move. XA is supported once it is enabled on the XA connection factory and the client profile allows transacted sessions.

Wrong for you if: leaving a commercial messaging vendor is the goal, or your code uses the JMS 2.0 API.

6. TIBCO EMS

TIBCO EMS is the other long-established commercial JMS broker. TIBCO states that EMS is TCK-certified for Jakarta Messaging 2.0 and 3.0, and EMS supports XA transactions and has clients for Java, .NET, C and COBOL, so it can serve mixed-language estates. Version 10.5.1 shipped in September 2026, and since 10.5.0 EMS includes its own transport to Apache Kafka. TIBCO is part of Cloud Software Group.

It is a sideways move, from one commercial licence to another. That makes sense mainly where EMS already runs in the same organization and the goal is fewer messaging products. TIBCO EMS vs Kafka covers EMS's own extensions and its Kafka transport.

Wrong for you if: the licence is the reason you are leaving IBM MQ.

7. Managed Cloud Services: Azure Service Bus, Amazon SQS and Google Cloud Pub/Sub

The cloud providers' own services take the broker out of your operations entirely. They differ sharply on JMS:

• Azure Service Bus Premium supports the JMS 2.0 API over AMQP 1.0 through Microsoft's azure-servicebus-jms library, with selectors (without LIKE or BETWEEN), delivery delay and temporary queues, but no XA and no noLocal. The Standard tier supports only a queue-focused JMS 1.1 subset. We compare it with Redisson PRO in Azure Service Bus vs Reliable Queue and Reliable PubSub.
• Amazon SQS has a Java Messaging Library that covers JMS 1.1 queues only, and SNS adds fan-out. See Amazon SQS vs Reliable Queue.
• Google Cloud Pub/Sub has client libraries for C++, C#, Go, Java, Node.js, PHP, Python, Ruby and Rust, plus gRPC and REST APIs, and no JMS client, so JMS code is rewritten. See Google Pub/Sub vs Redis for messaging, and Google Pub/Sub vs Kafka if Kafka, option 4, is also on your list.

None of the three supports XA, and each ties the messaging layer to one cloud. For AWS estates that would rather keep IBM MQ itself, IBM MQ as a Service runs there too.

Wrong for you if: you need XA, run on premises or across clouds, or, in the case of Pub/Sub, want to keep your JMS code.

8. Valkey or Redis With Redisson PRO

Redisson PRO is the commercial edition of Redisson, a Java client for Valkey and Redis, and its JMS implementation is the one option here without a separate broker process: Valkey or Redis becomes the message store. Its documentation states that JMS 2.0 (JSR 343), JMS 3.0 and JMS 3.1 implementations are available and that it "successfully passes all TCK tests". Queues and topics are stored in the Valkey or Redis deployment you already run, which can be a managed service such as Amazon ElastiCache or MemoryDB. On AWS, that makes it a way to run JMS 2.0 and 3.x code that uses features Amazon MQ lacks, such as delivery delay, without operating a broker. For a Java estate whose IBM MQ use is JMS queues and topics, that means one system fewer to run, provided Valkey or Redis is set up for messaging, with persistence and an eviction policy that never removes messages. Its topics also keep their history, so readers that need to replay can share a topic with queue-style consumers instead of moving to a second system.

The licence includes 24x7 technical support with an SLA, and you can try it for free against your own Valkey or Redis. The section below maps IBM MQ settings onto it, covers AWS and replay, and lists what it does not replace.

Wrong for you if: anything outside the JVM talks to your queue manager, a JMS send has to commit in one XA transaction with a database update, or your backlogs can outgrow memory.

IBM MQ Alternatives Compared

If Your MQ Estate Is Java and JMS

Some IBM MQ estates use little beyond standard JMS: Java services sending to queues, durable subscriptions on a few topics, a backout queue for poison messages, and no XA. If Valkey or Redis is already in the stack, Redisson PRO can take those workloads without a separate broker. The JMS code stays, the connection factory changes, and the queues live in Valkey or Redis.

Queues are backed by Reliable Queue and topics by Reliable PubSub. Applications on javax.jms use the pro.redisson:redisson-jms-20 artifact, and those on jakarta.jms use redisson-jms-30 or redisson-jms-31. Code can build a JNDI context with RedissonInitialContextFactory, the counterpart of the file-based context behind IBM's .bindings files; the documentation does not describe registering the factory in an application server's own namespace. Most IBM MQ settings have a counterpart:

In Spring Boot the switch is a few dependencies and one bean. IBM's starter, com.ibm.mq:mq-jms-spring-boot-starter, brings Spring's JMS support with it and is configured with ibm.mq properties:

# Before: IBM's starter connects to the queue manager
ibm:
  mq:
    queue-manager: QM1
    channel: APP.SVRCONN
    conn-name: mq1.example.com(1414),mq2.example.com(1414)
    user: orders
    password: ${MQ_PASSWORD}

Replace IBM's starter with spring-boot-starter-jms and pro.redisson:redisson-jms-31 (or redisson-jms-30), add Redisson's Spring Boot starter for the RedissonClient, and declare the connection factory. The Redisson documentation says that defining a RedissonConnectionFactory bean is sufficient, because Spring Boot's JMS auto-configuration detects it and creates JmsTemplate and the default listener container factory. Import it from org.redisson.jms, because Redisson's Spring Data integration has a class with the same name:

import java.time.Duration;
import org.redisson.api.RedissonClient;
import org.redisson.api.queue.QueueConfig;
import org.redisson.jms.RedissonConnectionFactory;
import org.springframework.context.annotation.Bean;

// After: no IBM starter. Spring Boot builds JmsTemplate and the
// @JmsListener container factory from this bean.
@Bean
RedissonConnectionFactory connectionFactory(RedissonClient redisson) {
    RedissonConnectionFactory cf = new RedissonConnectionFactory(redisson);
    cf.setQueueConfig("ORDERS.IN", QueueConfig.defaults()
            // Was BOTHRESH(5) on the IBM MQ queue.
            .deliveryLimit(5)
            // Was BOQNAME. Without it, a message past the limit is deleted.
            .deadLetterQueueName("ORDERS.BACKOUT")
            // IBM MQ has no such timeout. An unacknowledged message returns
            // to the queue when this expires, so keep it above the slowest
            // handler.
            .visibility(Duration.ofMinutes(5)));
    return cf;
}

@JmsListener(destination = "ORDERS.IN") methods and JmsTemplate calls keep working with the same destination names. The documentation does not say where selectors are evaluated, how transacted sessions and QueueBrowser behave, whether temporary queues are available for request-reply, or whether a JMS send can join an XA transaction, and it describes no resource adapter for message-driven beans. Selectors, browsing, transacted sessions and temporary queues are part of the API the TCK covers, but test them against your own workload before you plan around them. Start with transacted sessions if you use Spring Boot, because its default listener container uses them when no JTA transaction manager is present. A free trial licence is enough for that test, and JMS messaging over Valkey and Redis, the Jakarta Messaging 3.1 walkthrough and dead letter queues and topics with JMS cover the API in more detail.

It does not fit every IBM MQ estate:

• It is a JVM library. MQI programs in COBOL, C, PL/I or RPG, .NET services, and CICS or IMS programs on z/OS have no counterpart here, so they stay on IBM MQ or move to a broker with clients for them.
• IBM MQ extensions in JMS code, such as report options, MQMD access and targetClient for non-JMS consumers, change on any provider, and the consumers behind them need a new contract.
• XA is documented for RMap, RMapCache, RLocalCachedMap, RSet, RSetCache and RBucket through Redisson's XAResource, not for JMS sends. An application that commits a message and a database row together needs that confirmed first, or a move to the outbox pattern.
• Messages live in memory. Size Valkey or Redis for the deepest queue you expect, turn on AOF persistence or, on AWS, use one of the durable services described below, and choose an eviction policy that never evicts messaging data.
• Message-driven beans bound through IBM MQ's resource adapter need another way to receive, because the documentation describes JNDI lookups rather than a resource adapter.
• The JMS implementation is a Redisson PRO feature. The feature comparison shows what the open-source edition includes.

JMS on AWS Without Running a Broker

AWS's own managed broker is Amazon MQ, and neither of its engines implements all of JMS 2.0. Its ActiveMQ brokers have Classic's gaps, and on its RabbitMQ brokers the RabbitMQ JMS Client has no selectors on queues and no JMSProducer.setDeliveryDelay. If the estate already runs Amazon ElastiCache or MemoryDB, Redisson PRO can keep the messages there instead. AWS still operates the servers, no broker is added, and JMS 2.0, 3.0 and 3.1 code keeps the API it was written against, XA aside. Redisson on ElastiCache and Redisson on MemoryDB cover the connection settings.

On AWS, durability comes from the service rather than from an append-only file, which ElastiCache does not support:

• MemoryDB stores every write in a Multi-AZ transactional log before acknowledging it, and AWS states that its strong consistency is preserved across primary failovers.
• ElastiCache for Valkey 9.0 or later has done the same since June 2026 when durability is on in synchronous mode. It needs a node-based cluster with cluster mode enabled and at least one replica per shard, adds 18 percent to the node-hour price and, since October 2026, can be switched on for an existing cluster that uses encryption in transit. In asynchronous mode, up to 10 seconds of acknowledged writes can be lost in a failure.
• Without durability, ElastiCache replicates asynchronously, so the caveat in the table above applies. ElastiCache Serverless offers neither durability nor the WAIT command, so test what syncMode confirms there.

On any of them, check that maxmemory-policy is noeviction and size memory for the deepest backlog you expect. The durability section of our Kinesis comparison goes through these options and what they cost.

If Replay Is Why Kafka Is on the List

IBM MQ keeps no history to replay. Once a message is consumed it is gone, and durable subscriptions and streaming queues deliver copies only to readers configured before the message arrived; a retained publication keeps just the latest message on a topic. That gap is often what puts Kafka on the shortlist. Reliable PubSub, the object behind Redisson PRO's JMS topics, fills it for estates whose readers run on the JVM.

By default a Reliable PubSub topic stores every message, whether or not any subscription has processed it, with no expiry. Each subscription is an independent reader with its own offset, so new readers can be added without affecting existing ones. A subscription created at Position.earliest() starts from the oldest message the topic still holds, and seek() moves an existing one to the earliest or latest message, a message ID or a timestamp. Inside a subscription, consumers share the messages and acknowledge each one, with a visibility timeout, delivery limit and dead-letter topic set per subscription. One topic can therefore serve the applications that need queue semantics and a new reader that starts from the beginning of the history.

It stops short of Kafka in three places:

• The history lives in Valkey or Redis memory, where Kafka keeps it on disk, so how far back you can replay depends on how much RAM you pay for. A timeToLive on the topic sets the window. To rewind a subscription over messages it has already acknowledged, create it with retainAfterAck(); without it, the subscription discards each message it acknowledges.
• Replay is part of Redisson's own API, because JMS has no call to rewind a subscription. The messaging documentation creates a subscription at Position.earliest() through that API and registers it on the connection factory, but its JNDI properties have no position setting.
• There is no stream-processing library to match Kafka Streams, so windows, joins and aggregations are application code, and readers outside the JVM cannot use any of this.

Apache Kafka vs Reliable PubSub compares the two feature by feature.

Running IBM MQ Alongside Its Replacement

Few IBM MQ estates move in one step, and the mainframe side often never moves. The usual plan connects the old and new systems and moves applications across a few queues at a time.

To Kafka, IBM's own connectors do the work. The MQ source connector copies messages from an IBM MQ queue to a Kafka topic and needs IBM MQ 8 or later, and exactly-once delivery needs Kafka 3.3.0 or later. The sink connector copies records from Kafka to an IBM MQ queue and needs IBM MQ 9 or later.

To another JMS provider, a bridge is a consumer on one side and a producer on the other. Apache Camel and Spring Integration both do it, and so does a short program of your own. Receive inside a transaction on the IBM MQ side and commit only after the send succeeds, and make the receiving consumers idempotent, because a bridge that fails between the send and the commit delivers that message twice.

Move consumers first and producers second, one queue at a time: a consumer on the new provider reads what the bridge forwards while the old producers keep writing to IBM MQ, and once the producers have moved too, the bridge for that queue goes. Leave until last the queues that use triggering, report messages or XA, and keep IBM MQ for the mainframe.

How to Choose

Work down the table and stop at the first row that describes you.

Most estates fit more than one row, so decide workload by workload. For the broker-versus-log question in more depth, see Is Kafka a Message Queue?, and for the JMS specification levels, the JMS broker comparison.

Frequently Asked Questions

What Can I Use Instead of IBM MQ?

It depends on what your applications are written against. For JMS code, the closest replacements are Apache Artemis, which offers XA and full JMS 2.0, ActiveMQ Classic or Amazon MQ, TIBCO EMS, Solace, and Redisson PRO on Valkey or Redis if every client runs on the JVM. Kafka suits stream processing and long replayable history but is not a JMS provider, and for JVM estates whose history fits in memory, Redisson PRO's topics replay as well. Azure Service Bus and Amazon SQS take the broker off your hands, without XA. Programs that use the MQI from COBOL, C or PL/I usually stay on IBM MQ.

Is There a Free Version of IBM MQ?

Yes, for development. IBM MQ Advanced for Developers is a free download that includes a queue manager, but it is not licensed for production. IBM MQ as a Service also has a free Lite plan limited to 10,000 messages a month. For free production use you need an open-source broker instead, such as Apache Artemis, ActiveMQ Classic or RabbitMQ.

Who Are IBM MQ's Main Competitors?

Among commercial products, Solace Platform and TIBCO EMS are the closest equivalents, and Red Hat sells support for Apache Artemis as AMQ Broker. Kafka platforms compete for the same budgets, although Confluent became part of IBM in March 2026. The cloud providers compete with managed services: Amazon MQ and SQS on AWS, Service Bus on Azure and Pub/Sub on Google Cloud. Review sites also list integration platforms such as MuleSoft and Boomi, which compete with IBM's integration products rather than with the queue manager.

What Are the Key Differences Between IBM MQ, Kafka and RabbitMQ?

IBM MQ and RabbitMQ are message brokers: each message goes to a consumer and is removed once acknowledged, apart from RabbitMQ's streams, which keep a log. Kafka is a log that keeps messages for a retention period, so any number of consumers can read and replay them. IBM MQ implements JMS natively, can coordinate XA transactions with a database, and runs on z/OS and IBM i. RabbitMQ is built around AMQP routing and reaches JMS through a client library. Kafka is not a JMS provider at all.

Is IBM MQ the Same as WebSphere?

IBM MQ is the product IBM sold as WebSphere MQ from 2002 until 2014, and as MQSeries before that. On its own, WebSphere usually means WebSphere Application Server, a separate Java application server that can use IBM MQ as its JMS provider.

Does IBM Own Kafka?

No. Apache Kafka is an Apache Software Foundation project. IBM owns Confluent, the company founded by Kafka's original creators, having completed the acquisition on March 17, 2026, and it also sells its own Kafka distribution, IBM Event Streams. IBM lists IBM MQ among Confluent's day-one integrations and presents the two as complementary: MQ for transactional messaging, Confluent for high-scale event streaming.

Can Amazon MQ Replace IBM MQ?

For Java applications written to JMS, often yes. Amazon MQ runs ActiveMQ Classic 5.19 and 5.18, and AWS describes migrating applications that use standard APIs such as JMS without rewriting their messaging code. Check three things first: ActiveMQ Classic's JMS 2.0 support is partial, so delivery delay and shared subscriptions fail at runtime; IBM MQ extensions in your code have no equivalent; and MQI, .NET and mainframe applications need a rewrite or stay where they are. Amazon MQ can also run RabbitMQ, where AWS documents JMS workloads through the RabbitMQ JMS Client, without delivery delay or selectors on queues, and IBM MQ itself is available on AWS as IBM MQ as a Service. If your code needs JMS features that Amazon MQ lacks, every client runs on the JVM and you already use ElastiCache or MemoryDB, Redisson PRO can keep the messages there instead, so AWS still runs the infrastructure.

When Does IBM MQ 9.3 Reach End of Support?

IBM's lifecycle page gives September 30, 2027 as the end of base support for IBM MQ 9.3, with extended support available until September 30, 2031. Base support for 9.2 ended on September 30, 2025. The two current Long Term Support releases are 9.4, from June 2024, and 10.0, released on June 16, 2026, which IBM says will be supported for at least five years.

How Much Does IBM MQ Cost?

IBM prices IBM MQ in Processor Value Units for perpetual licences, per Virtual Processor Core for monthly subscriptions, and in capacity units for some cloud options, with IBM MQ Advanced priced above IBM MQ. These metrics apply to distributed platforms; IBM MQ for z/OS is licensed separately. IBM MQ as a Service has its own plans, including a free Lite plan. What you pay depends on your agreement with IBM, so use your renewal quote, and add the cost of migrating each application when you compare it with an alternative.

Similar articles

• IBM MQ vs Kafka: When Kafka Replaces a Queue, and When It Cannot
• TIBCO EMS vs Kafka: Key Differences and What Breaks When You Migrate
• ActiveMQ vs Valkey & Redis Based Reliable Queue and PubSub
• ActiveMQ Alternatives: Seven Options and What Happens to Your JMS Code
• RabbitMQ Alternatives: Seven Options, and What Each One Breaks
• Apache Kafka Alternatives: 7 Options Compared
• Azure Service Bus vs Valkey & Redis Based Reliable Queue and PubSub
• JMS Messaging Over Valkey and Redis