We use it as our enterprise messaging bus, not from the transformation use cases. It's mainly from the messaging use cases only. We use it for connecting to mainframes predominantly.
Integration Lead at a financial services firm with 10,001+ employees
Robust, reliable, and has good documentation
Pros and Cons
- "I haven't seen any issues with respect to the message loss."
- "While there is support for API, it's not like the modern API capabilities."
What is our primary use case?
How has it helped my organization?
It was the main messaging bus for us for a very long time. Therefore, we have applications connecting, and even some of the modern applications are still using MQ. From a company's productivity perspective, we see a lot of benefits. It's all point-to-point connectivity. For any point-to-point messaging needs, MQ is very good.
What is most valuable?
The reliability is great. You will not see a case of a message loss in IBM MQ unless there's a queue full or there's some issue with the capacity of the queue. I haven't seen any issues with respect to the message loss. That's the main thing I like about MQ.
It's very robust.
It's a stable product.
Support is helpful and there is lots of good documentation available.
The solution can potentially scale.
What needs improvement?
While there is support for API, it's not like the modern API capabilities. If you want to automate the creation of queues and topics, IBM provides command-line utilities. It does provide API capability; it's just not that complete.
They should make CI/CD available. There is no CI/CD support from the product. Maybe MQ should think about the modern way to handle deep-based development.
Buyer's Guide
IBM MQ
April 2025

Learn what your peers think about IBM MQ. Get advice and tips from experienced pros sharing their opinions. Updated: April 2025.
848,716 professionals have used our research since 2012.
For how long have I used the solution?
As a user, I have about eight to nine users of experience with this solution.
What do I think about the stability of the solution?
Stability-wise, we have no problems. It's very stable.
What do I think about the scalability of the solution?
Scalability-wise, in terms of the implementations that we have currently, it's not quite scalable. The implementations that we had were more active-passive kind of implementations up until now. There are product features that came up that allow it to scale. We understand it is scalable. However, we still need to explore it. There's a new HA capability that has come from IBM, which is a cloud-native replica set way of doing it. It's possible, it's just more difficult how we have it arranged.
We have a user base of millions and maybe 50 to 100 developers working on the solution.
With MQ, we are trying to reduce usage since we have better products to support JMS. Most of the applications are Java-based applications, which have native support for JMS. We only use MQ right now for mainframe use cases. For all the other messaging use cases, we use Solace.
How are customer service and support?
Technical support is quite good. They are some of the best. They are responsive.
Since we've used IBM for a very long time, we need to rely on them less. Most issues can be dealt with by looking at the documentation, which is available online. You often do not even have to reach out to support. That said, if you do, they are great.
Which solution did I use previously and why did I switch?
We did not previously use a different solution.
How was the initial setup?
From an implementation perspective, it was hard for the features that we were using. However, recently, it has become quite easy to implement.
The setup team is a bigger team due to the size of MQ in the company, which is quite huge. We have around 200 managers and the size of the team is around 20 members and they can all assist with deployment tasks.
What about the implementation team?
The initial setup is done by our deployment team. In fact, I currently work in pipeline development for MQ, so it's easy to implement.
What was our ROI?
Returns are quite good for the amount that you pay, since, with IBM products, you see fewer bugs.
What's my experience with pricing, setup cost, and licensing?
I don't have any information related to licensing costs.
We likely have an enterprise license, based on the size of infra that we have. My understanding is it is not very expensive. However, for a new company, it may be pricier.
We get everything in a bundle. There are no extra costs involved.
Which other solutions did I evaluate?
I didn't look into other options. When I arrived at the company, MQ was already there. They've used it for even longer than I have - for maybe 15 years.
What other advice do I have?
We are customers and end-users.
We have various versions that we use, including versions 7 and 9.1. We have both cloud and on-prem deployments and mainly deal with on-premises. 95% is on-premises.
If you're looking for a guaranteed messaging platform, MQ is quite good. That said, it might be expensive for new organizations. If you're looking for a cheaper option, maybe you may need to look for other MQ open-source protocols or open-source products. You may not get the same guaranteed message delivery experience that you have with MQ. However, it might be more affordable. With MQ, from a reliability perspective, you see very few bugs. It's been running in the bank for a long time. We have very few cases where we had to reach out to IBM support. It's just too bad they do not have CI/CD capabilities.
I'd rate the solution nine out of ten.
Which deployment model are you using for this solution?
On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.

MQV Admin at Allstate
When you're doing maintenance, you can fail over the entire group of queue managers in that HA group or you can fail them individually if you'd like.
What is most valuable?
I like its ease of administration. We just recently moved to the MQ appliance and the high availability (HA) feature is outstanding. We're really, really pleased with it and the power of the appliance itself. When you throw more work at it, the faster it goes.
For example, when you're doing maintenance, you can fail over the entire group of queue managers in that HA group or you can fail them individually if you'd like. So, it's very helpful that way. But that's the manual fail over. The automatic fail over is what we are really interested in. We did have an appliance go down. Everything failed over and none of our clients knew of it. So it was very good. We were very pleased with that.
The user interface is good. The command line version of it, MQ CLI, is good. The web user interface is really handy; really a good feature.
How has it helped my organization?
It updated everything. We started with Version 7 with Linux and now, with the appliance, it seems to be bringing us more into the 21st century so to speak.
What needs improvement?
We have an M2000. The M2001 has a 3 TB SSD, which is a good feature. I wish they had had it when I started. But as we upgrade, in the future, we'll probably move to that. Everything is working properly with the current version.
The reason the migrations are an issue is, we came from Version 7.01 and Version 7.5. The security in Version 8 was a little tighter. So, there were a few things we had to learn. Be sure that we were up to speed, so that's all.
What do I think about the stability of the solution?
We haven’t had any stability problems at all. Stability has been outstanding. We went from multi-instance queue managers, which worked fine, except they worked often. That wasn't good for us. So it was a perceived outage for our clients. The availability has been outstanding with the MQ appliance.
How are customer service and technical support?
I have used support on several occasions. We were an early adopter, and there are always a few bugs along the way. We did use technical support and we went all the way up to the lab a couple of times. It was outstanding as usual.
Which solution did I use previously and why did I switch?
We have been an MQ adopter since 1998. We were using z/OS, so we have been using MQ along the way. Then we went to Windows, to Unix, to Linux, and now the appliance.
How was the initial setup?
Actually, setup was straightforward. I'm not a hardware person and it was a first-time setup. It was what they said it was. It wasn't a 30-minute setup, but it was pretty easy.
What other advice do I have?
Plan your file systems. Plan your messaging names and your network routes. You want to be ready with everything before you start and once you do that, you're in good shape.
When choosing a vendor, I want knowledge and availability. Those are the two things that are most important.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Buyer's Guide
IBM MQ
April 2025

Learn what your peers think about IBM MQ. Get advice and tips from experienced pros sharing their opinions. Updated: April 2025.
848,716 professionals have used our research since 2012.
Solution Architect at EPAM Systems
Can work in clusters and scales horizontally
Pros and Cons
- "Using a message queuing solution, we had a banking solution that integrated multiple branches and interbank systems. Different systems for credits, debits, CRM, and others communicated through this message queue solution. It wasn't just about communication; for instance, a CRM application needed to collect information from various banking systems, such as account balances, properties, contracts, and credit cards."
- "The tool is expensive."
What is our primary use case?
I was part of a small team that tested and used the IBM infrastructure in a QA environment. My activities included configuring and creating test environments and finding solutions to monitor the infrastructure.
What is most valuable?
Using a message queuing solution, we had a banking solution that integrated multiple branches and interbank systems. Different systems for credits, debits, CRM, and others communicated through this message queue solution. It wasn't just about communication; for instance, a CRM application needed to collect information from various banking systems, such as account balances, properties, contracts, and credit cards.
These systems were separate, and the message queuing solution combined information from all of them into one message. When a request was made from a workplace for information about a person or company, the message queue infrastructure routed the request to all connected systems, ensuring the workplace did not need to be aware of all configuration details.
The product's most valuable feature is its ability to work in clusters. This allows for creating a cluster of message brokers, providing horizontal scalability. Another important feature is the extensive command-line interface, which allows for comprehensive monitoring and management of the system. This enables the creation of complex scripts to configure, making it a complete and very powerful tool.
What needs improvement?
The tool is expensive.
For how long have I used the solution?
I have been working with the product for four years.
What do I think about the stability of the solution?
The tool is scalable.
What do I think about the scalability of the solution?
IBM MQ is stable.
How are customer service and support?
The tool's support is not cheap and fast. You can't expect a resolution from support.
How was the initial setup?
The setup of message queues in an enterprise trade system is complex, especially when dealing with hundreds of message brokers and thousands of message queues. Configuring such a large infrastructure isn't straightforward and requires tools for testing, validating, and identifying missed components.
We manage a large configuration file, likely an XML file containing thousands of lines. Many teams update this file to reflect changes in their systems. It can be split into multiple smaller files to manage this file, but this complicates maintaining a single point of truth and requires validating all combinations. Systems communicate with each other using these components, needing a common protocol.
What was our ROI?
The benefits of using IBM MQ include buffering your transaction flows, which is useful if you have spikes. For example, it can handle this increased load if you normally have 100 messages per second but expect 10,000 the next day. You can also build clusters of message brokers to scale horizontally.
What's my experience with pricing, setup cost, and licensing?
The license for IBM MQ is commercial and not cheap. You get a multi-platform solution, which is important because it lets you connect systems on mainframes, personal solutions, Unix, Linux, etc.
What other advice do I have?
Applications produced and consumed messages, with the IBM infrastructure serving as the transport and storage for these messages. Messaging was based on IBM MQ, and several other IBM products were involved, though I can't recall their exact names. These products were used for transforming messages, validation, and routing. The infrastructure could route, validate, split, and combine messages.
I rate the overall product a ten out of ten. Our goal was to measure the performance of the integrated system, not just individual components. This involved external systems as well. We used various command-line tools, such as IBM MQ, to collect detailed information about processes and systems. Measurements had to be aligned with configurations, meaning we couldn't use a universal solution. Instead, we had to adjust based on specific requirements and configurations.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Software Development Manager at Reliance Jio
A fast and very stable solution for message routing
Pros and Cons
- "The solution is fast with end data compared to other messaging tools."
- "The solution should offer a freeware version, free vouchers, or certifications for learning purposes and building knowledge base."
What is our primary use case?
We use the solution when connecting with the external system to process messages in a queue-based flow. When the solution receives a message, the flow is triggered to cycle through routing, mapping, and logic to create a pipe delimited, XML, or other formats that send to the end system.
We created the queue-based flow to receive messages and connect them to end systems using a pop-up concept to classify messages by subscription topics.
What is most valuable?
The solution is fast with end data compared to other messaging tools.
With integration tools, the node is connected with the queue manager so there is some dependency. In the solution's latest version, the dependency was removed which allows us to create servers without any interdependencies.
What needs improvement?
The solution should offer a freeware version, free vouchers, or certifications for learning purposes and building a knowledge base. When creating an account to download software, you must provide user details like credit card information. If you exceed the allotted hours or days while trying to learn the solution, your credit card is charged for additional time which is what happened to one of my colleagues.
Learning the solution is not as simple as MuleSoft or APG. Some developers left the market because they didn't know how to learn the solution. Other products provide free vouchers or certifications or learn programs but IBM currently doesn't do that.
For how long have I used the solution?
I have been using the solution for ten years.
What do I think about the stability of the solution?
The solution is an older product and very stable. Our product teams never have issues with it.
What do I think about the scalability of the solution?
We have experienced some issues with scalability because there is a known lag when scaling.
How are customer service and support?
Technical support is rated a ten out of ten because we receive support very quickly but rarely need it.
How would you rate customer service and support?
Positive
How was the initial setup?
The initial setup is easy with no huge steps.
There really isn't any deployment. Creating queues does not take much time and we use them with channels and subscription topics to push and pull messages
What about the implementation team?
The implementation was completed in-house with integration developers doing the important work.
What other advice do I have?
If you want to route messages through a queue-based app, definitely take a look at this solution and research the cost.
Which deployment model are you using for this solution?
Private Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
IBM
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Senior Developer at a comms service provider with 10,001+ employees
I like MQ's simplicity and solid stability
Pros and Cons
- "I like the MQ's simplicity and rock-solid stability. I've never experienced a failure in two decades caused by the product itself. It has only failed due to human error."
- "IBM could revamp the interface. The API is huge, but some developers find it limiting because of the cost. They tend to wrap the API course into the JMS, which means they're missing out on some good features. They should work a little bit on the API exposure."
What is our primary use case?
I work for a company that has an ESB backbone built on the MQ. It's the enterprise bus for the whole company. I was a trainer for IBM products long ago, but I moved to different companies and now I'm a senior developer supporting MQ and IBM.
What is most valuable?
I like the MQ's simplicity and rock-solid stability. I've never experienced a failure in two decades caused by the product itself. It has only failed due to human error.
What needs improvement?
I started using MQ on a mainframe, so I understand the thinking behind it. However, there's a lot of legacy stuff lagging behind. I think a start-up company might find the approach to be outdated.
IBM could revamp the interface. The API is huge, but some developers find it limiting because of the cost. They tend to wrap the API course into the JMS, which means they're missing out on some good features. They should work a little bit on the API exposure.
Support utilities are almost non-existent. MQ is dependent on third-party companies. I write everything I use, like a Linux-based command line interface for all admin stuff.
For how long have I used the solution?
I started using MQ in 1999, so it has been around 24 years.
What do I think about the scalability of the solution?
I rate IBM MQ 10 out of 10 for stability. I can configure the topology on my laptop and copy identical stuff into a multiple mainframe configuration.
How was the initial setup?
Setting up MQ is straightforward. Generally, installing MQ isn't a big deal. It's a simple product. The magic happens when you go configure the topology and do some performance tuning.
I work for a huge company, so the deployment is done by DevOps. We're on the application side. The installation was dodgy in versions 5 or 6, but now you just drop a container. We try to automate as much as possible, so we wrote extended Jenkins jobs to flash install all the virtual machinesWe don't deploy MQ on the cloud, but I'm thinking of migrating it to Azure. I see no benefit in a private cloud.
What's my experience with pricing, setup cost, and licensing?
IBM could lower the price because many companies are abandoning MQ from Mickey Mouse products like RabbitMQ and Kafka. Kafka is horrible but free.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Product Development Manager at Arab Bank
It's easy to set up and scale, but the monitoring and performance could be better
Pros and Cons
- "Setting up MQ is easy. We had a "grow as you go" implementation strategy. We started with a single channel and progressed to multiple queues and channels depending on the systems and integrations with other systems. It was a gradual deployment and expansion as we grew the services interacting with the core system using MQ."
- "The monitoring could be improved. It's a pain to monitor the throughput through the MQ. The maximum throughput for a queue or single channel isn't clear. We could also use some professional services by IBM to assess and tune the performance."
What is our primary use case?
We use to connect the core banking system to several other systems in our environment. We are working on an IBM server with multiple clients sending XML messages through the IBM environment using MQ.
The end users are working on front-end services that are communicating with the servers. We are installing MQ on the backend system to act as middleware. Mainly the users are coming from somewhere else.
What needs improvement?
The monitoring could be improved. It's a pain to monitor the throughput through the MQ. The maximum throughput for a queue or single channel isn't clear. We could also use some professional services by IBM to assess and tune the performance.
For how long have I used the solution?
I started using MQ around eight to 10 years ago.
What do I think about the stability of the solution?
MQ is stable, but we face some limitations with redundancy.
What do I think about the scalability of the solution?
MQ is scalable.
How are customer service and support?
I rate IBM support eight out of 10. We've never had problems with support.
How would you rate customer service and support?
Positive
Which solution did I use previously and why did I switch?
We previously used different protocols like TCP socket connections. Now, most of the services use MQ.
How was the initial setup?
Setting up MQ is easy. We had a "grow as you go" implementation strategy. We started with a single channel and progressed to multiple queues and channels depending on the systems and integrations with other systems. It was a gradual deployment and expansion as we grew the services interacting with the core system using MQ. Maintenance requires two or three admins.
What's my experience with pricing, setup cost, and licensing?
The MQ license is a bit high. I rate IBM MQ six out of 10 for affordability.
Which other solutions did I evaluate?
We are exploring other solutions, including the Kafka platform. There are other services that can do the same thing but maybe offer some additional features, especially on the monitoring side. It may be faster as well.
We are using Confluent Kafka for some other services, and it's a good event-streaming platform. It does almost the same thing as message queuing, but we it has some other features and can do some things better than MQ.
What other advice do I have?
I rate IBM MQ seven out of 10.
Which deployment model are you using for this solution?
On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
A family of message-oriented middleware with a useful trace and tracking feature
Pros and Cons
- "I think the whole product is useful. Their database and all is very good, and the product is fine. The fact that it ensures message delivery is probably the most important thing. I also like that you're able to trace and track everything. If it doesn't arrive at the destination, it will go back to the queue, and no message will be lost."
- "They probably need to virtualize the MQ flow and allow us to design the MQ flow using the UI. It would also help to migrate to the cloud easily and implement AWS Lambda functions with minimum coding. If you have to code, then just with NodeJS or Java."
What is most valuable?
I think the whole product is useful. Their database and all is very good, and the product is fine. The fact that it ensures message delivery is probably the most important thing. I also like that you're able to trace and track everything. If it doesn't arrive at the destination, it will go back to the queue, and no message will be lost.
What needs improvement?
They probably need to virtualize the MQ flow and allow us to design the MQ flow using the UI. It would also help to migrate to the cloud easily and implement AWS Lambda functions with minimum coding. If you have to code, then just with NodeJS or Java.
Many things should be done out of the box, like MQPUT directly to databases or MQGET to link to the main database. MQ should be able to connect to any language and just do it whether you're using mobile apps or web apps. It should be possible.
The other probably more key thing is that to get IBM on-premise is hard because there are no freely available videos and courses. Technical support in Australia could be better.
For how long have I used the solution?
I used to be an MQ specialist 20 years ago, and now I'm a solutions architect and consultant who sometimes recommends this solution to clients.
How are customer service and technical support?
I think IBM technical support isn't too bad. IBM support can be a bit slow. Someone should be able to check on the problem straight away.
I know that IBM in the States is very good. You can get good IBM staff and engineers and architects 24/7 or from 09:00 to 05:00. They have highly skilled and highly experienced staff there. Here in Australia, it feels like it's run by an account manager and run by salespeople. It should be run by architects and engineers and not by the account managers and sales teams.
What's my experience with pricing, setup cost, and licensing?
I think IBM needs to look at its pricing. The prices of IBM products should be simple. The old way of pricing should now be moving on to the cloud to be pay as you go, a plan-based kind of pricing.
To become competitive, they actually need to move to AWS and Azure. If they really want to be highly available, they can have a highly available location, and charge another price.
What other advice do I have?
On a scale from one to ten, I would give IBM MQ an eight.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Websphere MQ Specialist at a maritime company with 10,001+ employees
Easy to use, stable, and offers great technical support
Pros and Cons
- "The solution can scale well."
- "There could be a better front-end GUI interface for us, where we can see things more easily."
What is our primary use case?
The solution is primarily used for business transactions. It's used for financial transactions as well. Those are the two main use cases. We exchange information with our in-house applications before we supply information to our customers and so on.
What is most valuable?
The messaging queue is the main feature that we use. We use other products like publish and subscribe, which are very useful to us as well.
We can share data and other people can subscribe to it.
The solution is very stable.
The solution can scale well.
We've found the installation to be extremely straightforward and well laid out.
It's easy to maintain, easy to administer, and easy to see what's going on there. Overall, it's a good product.
Technical support is excellent.
What needs improvement?
The way the solution provides us with the product and the way we use it gives us what we need. We don't actually have any issues with it.
There could be a better front-end GUI interface for us, where we can see things more easily. However, apart from that, it works well.
The pricing is definitely could be cheaper. Also, the support model, even though it's very good, could be cheaper as well.
For how long have I used the solution?
I've been working with the solution for about 25 years or so. It's a good amount of time. I have a lot of experience.
What do I think about the stability of the solution?
The product offers good stability. There are no bugs or glitches. It doesn't crash or freeze. It's very reliable in terms of performance.
What do I think about the scalability of the solution?
The product scales well. If a company would like to expand, it can do so. It's not a problem.
It's hard to say who exactly is working on the solution at this time. We have around 30,000 people working on it, in some way or the other.
We've got to keep using it for the foreseeable future. We don't see any reason not to as it provides us with a good solid platform. We have no reason to change anything.
How are customer service and technical support?
We have found the technical support to be very good. They are responsive and knowledgeable. They are also very friendly. We are satisfied with the level of support we receive. As soon as we raise any issue, they get in touch with us and sort it out. It's great.
Which solution did I use previously and why did I switch?
We did not previously use a different solution. We started with IBM MQ a long, long time ago and we stuck with it.
How was the initial setup?
The initial setup is not complex. It is a very simple installation. I've been provided with instructions that make the whole solution extremely easy to download and install.
The entire process is very fast. It only takes about 30 minutes to deploy.
We have different departments that can handle deployments. We have about 100 people on our team that can handle this type of assignment.
What's my experience with pricing, setup cost, and licensing?
This is a licensed product. We do pay for it.
While, of course, it would be better if it was cheaper, the service they provide with it, including the maintenance facilities they provide, is very good. We're quite happy. Most people have to use what IBM provides, however, it could be a cheaper license.
What other advice do I have?
We're just a customer and an end-user.
I'd recommend the solution to any organization.
I'd rate it ten out of ten. It really provides everything we need.
Which deployment model are you using for this solution?
On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.

Buyer's Guide
Download our free IBM MQ Report and get advice and tips from experienced pros
sharing their opinions.
Updated: April 2025
Product Categories
Message Queue (MQ) Software Business Activity Monitoring Message Oriented Middleware (MOM)Popular Comparisons
MuleSoft Anypoint Platform
ActiveMQ
VMware Tanzu Data Solutions
Amazon SQS
Red Hat AMQ
PubSub+ Platform
Amazon MQ
EMQX
Oracle Event Hub Cloud Service
IBM Event Streams
Aurea CX Messenger
Memphis
Red Hat JBoss A-MQ for xPaaS
Buyer's Guide
Download our free IBM MQ Report and get advice and tips from experienced pros
sharing their opinions.
Quick Links
Learn More: Questions:
- What are the differences between Apache Kafka and IBM MQ?
- What is the pricing of IBM MQ for 1 license and 2 cores?
- What Is The Biggest Difference Between ActiveMQ and IBM MQ?
- What is the biggest difference between IBM MQ and RabbitMQ?
- How does IBM MQ compare with VMware RabbitMQ?
- When evaluating Message Queue, what aspect do you think is the most important to look for?
- What Message Queue (MQ) Software do you recommend? Why?
- What is the best MQ software out there?
- What is MQ software?
- Why is Message Queue (MQ) Software important for companies?