WebSphere MQ vs IBM MQ

Job postings, old runbooks, and vendor contracts often use two different names for what is essentially the same middleware: WebSphere MQ and IBM MQ. If you are new to the ecosystem, that dual vocabulary can sound like two competing products. It is not. IBM MQ is the current name for the queue manager technology that was sold for years as WebSphere MQ and, before that, as MQSeries. This page explains the naming change, how version numbers connect across the rebrand, what stayed the same for administrators and developers, and what actually changed when the WebSphere label came off the box.

Same Lineage, Three Names

Think of the product as one continuous line. MQSeries (1990s) established message queuing as an IBM brand. WebSphere MQ (2000s–2014) aligned the product with the WebSphere application platform marketing family. IBM MQ (2014 onward) reflects a simpler portfolio name while the runtime remains a queue manager with queues, channels, and the Message Queue Interface. Skills, object types, and disaster recovery procedures transfer directly; you are not learning Kafka when you move from WMQ 7.5 to IBM MQ 9.3—you are upgrading the same class of system.

What the Naming Change Was (and Was Not)

The change from WebSphere MQ to IBM MQ was primarily branding and packaging. IBM did not replace MQI with a wholly new protocol in 8.0. Queue names, channel definitions, and authority records still live in the queue manager's object repository. Application programs that MQPUT and MQGET using the same buffer layouts and options continue to work after upgrade testing, subject to IBM's compatibility statements for each release pair.

What did change across the 8.0 and 9.x era includes default security (more emphasis on TLS), new administration surfaces (REST API, container images), licensing and installation paths on some platforms, and documentation URLs on ibm.com instead of websphere.ibm.com. Those are evolutionary improvements, not a different product category like switching from FTP to SFTP versus switching from FTP to email.

WebSphere MQ vs IBM MQ at a Glance

Version Continuity: 7.5 → 8.0 → 9.x

Version numbers are the clearest proof of continuity. WebSphere MQ 7.5 was a long-term support release widely deployed before the rebrand. IBM MQ 8.0 was the next marketing generation; sites upgrading from 7.5 to 8.0 followed IBM migration manuals, often taking a full backup of the queue manager data directory (or CCSDS and logs on z/OS) and applying the installation image. IBM MQ 9.0 introduced continuous delivery (CD) with more frequent feature drops; 9.1, 9.2, and 9.3 LTS gave enterprises a slower patch rhythm with extended support.

When someone says "we are on MQ 9.3," they mean the IBM MQ product—not WebSphere MQ 9.3, which does not exist. Conversely, "WMQ 7.5" never becomes "IBM MQ 7.5" in official naming; the IBM MQ line starts at 8.0. That jump confuses beginners, but it is only a renumbering at the marketing boundary, similar to how other IBM products skipped version digits when branding changed.

Branding vs Integration with WebSphere

Removing "WebSphere" from the product name did not remove integration with WebSphere Application Server or Liberty. Java EE and Jakarta applications still use JMS connection factories that point at an IBM MQ queue manager. The name change clarified that MQ is infrastructure you can run without WAS—useful for microservices on Kubernetes that only need messaging—but many enterprises still colocate MQ with WebSphere stacks in the same data center.

IBM Integration Bus (now IBM App Connect) and other integration products also connect to IBM MQ queues. The word WebSphere on those products is independent of whether the queue manager is called IBM MQ. When reading architecture diagrams from 2010, replace the box label mentally: "WebSphere MQ" box → "IBM MQ" box, same arrows.

What Administrators See Day to Day

• MQSC — DEFINE QLOCAL, ALTER CHANNEL, DISPLAY QMGR still work; syntax gained new attributes in 9.x (TLS ciphers, authentication policies) but the command language is recognizable.
• Queue manager name — Still 1–48 characters; still the hub for local queues and channels.
• Default listener port — Still commonly 1414 for TCP; always confirm in your environment because security standards often move TLS listeners to other ports.
• z/OS — The queue manager runs under the CSQ subsystem; operators use /d mqm and MQ console commands familiar from the WebSphere MQ era.
• Logs — AMQ* messages on distributed, CSQ* on z/OS; error code format unchanged in spirit (reason codes on MQRC).

What Developers Should Expect

COBOL, PL/I, C, Java, and .NET programs link to the same MQI entry points (MQCONN, MQOPEN, MQPUT, MQGET, MQCMIT). JMS code using com.ibm.mq.jms packages may need dependency updates when moving to newer client versions, but the destination is still a queue name or topic string. Spring and Jakarta Messaging configurations that reference a WebSphere MQ connection factory bean should be updated to current client jars labeled IBM MQ, not rewritten around a different messaging model.

New in IBM MQ 9.x for developers: REST messaging and administration for some patterns, AMQP channel support in selected configurations, and improved client reconnect behavior. None of that invalidates classic MQI; it adds options.

Licensing and Support Language

Procurement documents may still list "WebSphere MQ entitlements." Renewal conversations should map those to IBM MQ 9.x LTS or CD subscriptions. IBM publishes end-of-support dates per version; running WMQ 7.0 without extended support means no security fixes. Planning a move to IBM MQ 9.3 LTS is a support lifecycle project, not a rip-and-replace of integration patterns.

Tutorial: Display Queue Manager Description (MQSC)

Whether the queue manager was installed as WebSphere MQ years ago or as IBM MQ last month, you inspect it with the same MQSC command interface. The example below uses runmqsc on distributed Linux; on z/OS you issue the equivalent from the MQ operations console. DISPLAY QMGR returns attributes such as PLATFORM, VERSION, and DESCR (description).

1
2
3
4
5
6
7
8
9
10
11
# Start MQSC for queue manager QM1
runmqsc QM1
 
# Inside MQSC, show queue manager attributes
DISPLAY QMGR ALL
 
# Show only version-related and descriptive fields
DISPLAY QMGR VERSION DESCR PLATFORM
 
# End MQSC session
end

VERSION shows the running queue manager code level (for example 0000000903000000 for 9.3.0.0 in some displays). DESCR is a free-text field administrators often set to document environment ("Production payments hub"). PLATFORM identifies the OS family (UNIX, Windows, z/OS). None of these fields changed meaning between WebSphere MQ and IBM MQ—they are the same object model.

Explain Like I'm Five: WebSphere MQ vs IBM MQ

Your favorite toy company renamed a toy truck from "WebSphere Truck" to "IBM Truck." The wheels, bed, and trailer hitch are the same; only the sticker on the side changed. If you learned to load boxes in the back when it was called WebSphere Truck, you still load boxes the same way on the IBM Truck. Newer trucks might have seat belts (TLS) and a radio (REST), but they are still trucks that carry boxes between friends' houses.

Practice Exercises

Exercise 1: Vocabulary Translation

Rewrite this sentence for a 2026 architecture document: "OrderService puts to WebSphere MQ queue ORD.IN on QM.PROD." Use current product naming without changing queue or queue manager names.

Exercise 2: Version Logic

A colleague says they need "IBM MQ 7.5." Explain politely why that version number does not exist under the IBM MQ brand and which release they might actually mean.

Exercise 3: DISPLAY QMGR

If you have lab access, run DISPLAY QMGR VERSION and DESCR. If not, write what you expect each field to tell you and how it helps during a support call with IBM.

Exercise 4: Migration Talking Points

List four objects (for example local queue, sender channel, listener, authority record) that you would expect to migrate unchanged in definition name and purpose from WMQ 7.5 to IBM MQ 9.3, subject to compatibility testing.

Test Your Knowledge