IBM MQ End of Support: Every Date Lands on September 30 — 9.2 Crossed Last Year, 9.3 Is Next, and 9.4 Has No Date Yet

By Scott Bissett  ·  Published: August 12, 2026  ·  EOL Watch — deadline coverage  ·  Policy verified against IBM's MQ LTS/CD support FAQ (document 713169) and IBM's Software Support Lifecycle Policies page; version dates from our tracked lifecycle data (IBM's per-version End of Service technote, document 79401, is login-gated) — methodology

IBM MQ is the software nobody demos and everybody depends on. It is the message backbone under a remarkable share of the world's payments, core banking, insurance policy systems, and airline operations — the queue manager that was configured a decade ago, moves money every night, and appears on no roadmap because it never breaks. Ask a team what MQ they run and the honest answer usually requires logging in and typing dspmqver. This article is about what that command's output means now, because the support clock under those queue managers keeps striking on the same day of the year: September 30.

The rhythm is not a coincidence — it is written policy. IBM's Software Support Lifecycle Policies page commits to giving "at least 12 months of notice prior to an IBM branded product release's EOS date" and adds: "we endeavor to coordinate most EOS dates to occur on 30 April or 30 September." MQ has picked September every time since the 9.0 era. The consequences, per our tracked data: MQ 9.2's standard support ended September 30, 2025 — ten and a half months before this article's publication — the same day MQ 9.0's paid extension ran out entirely. MQ 9.3's standard support ends September 30, 2027, 414 days out — the same day MQ 9.1's paid extension dies with it. MQ's support dates go two at a time.

How the IBM MQ lifecycle actually works: LTS vs CD

Since MQ 9.0 (2016), IBM ships MQ in two release streams, and the support model differs enormously between them. Per IBM's MQ FAQ for Long Term Support and Continuous Delivery releases:

LTS (Long Term Support) releases are "for systems which demand the highest levels of stability." The policy: "IBM MQ software products LTS duration is 5 years from general availability" — formally IBM's Support Cycle-5 lifecycle policy — and "a LTS release is supported for at least five years from the point that it is made generally available." During that window, LTS releases receive fix packs (functional and security fixes, two or three per year) and Cumulative Security Updates between them. After end of support, "Extended Support is available for up to an additional 4 years with defect fixes in the first year only" — a real option, but note the asymmetry: years two through four of an extension carry no new defect fixes at all.

CD (Continuous Delivery) releases "add new function to MQ on a regular cadence" — and live fast. The FAQ's rule: "defect fixes for a CD update may be requested if it is one of the most recent two CD updates, or within 12 months of General Availability, whichever is longer." Elsewhere it is blunter: "Fixes are only provided on the LTS and two most recent CD Releases." A CD release is not a smaller LTS; it is a moving walkway, and stepping off means updating forward — "If a CD update is no longer eligible for defect fixes, update to a package that is eligible."

The version number tells you which stream you are on, and this is the part worth teaching your CMDB: in MQ's V.R.M.F scheme, the third digit — the modification level — is 0 for LTS. So 9.4.0.11 is the 9.4 LTS release at a Cumulative Security Update level, while 9.4.1 and 9.4.2 are CD releases with a support life measured in months. Two installations can both answer "9.4" and sit years apart in support reality — the same trap, one layer down, that we documented for AIX Technology Levels on the Power estates where much of this MQ actually runs. Cadence, per the FAQ: "LTS releases approximately every two years and CD releases every few months." The observed record matches: 9.0 shipped June 2016, 9.1 July 2018, 9.2 July 2020, 9.3 June 2022, 9.4 June 2024, 10.0 June 2026 — a metronome.

IBM MQ release dates and end-of-support dates: every version

Every MQ release line we track, newest first, with live status — the release dates on the left answer "when did it ship," the two right-hand date columns answer "when does IBM stop fixing it, and when does even the paid extension end." Dates are from our tracked lifecycle data (verification pass 2026-08-12); IBM's per-version End of Service technote (document 79401) sits behind a login, so this table exists in the open partly because that one does not. Each release links to its lifecycle page with live status and risk score.

Dates from our tracked dataset (verification pass 2026-08-12), which mirrors the community-maintained endoflife.date IBM MQ table; policy cross-checked against IBM's MQ LTS/CD support FAQ. "Not announced" reflects that IBM has published no end-of-support date for 9.4 or 10.0; "Available" means IBM's policy provides Extended Support for the release but its end date is likewise unannounced. Rows are LTS release lines (plus the pre-9.0 versions): CD releases such as 9.4.1 or 9.4.2 are not tracked as separate cycles because their fix eligibility expires under the two-most-recent-CD rule rather than on a calendar date. Extended Support windows shown are per tracked data; IBM's FAQ notes defect fixes are provided in the first year of an extension only.

The September 30 rhythm — and what 9.4's missing date actually tells you

MQ 9.4 and 10.0 have no end-of-support dates. That absence is not a data gap — it is how IBM's lifecycle works, and it carries usable information. Three published facts bound the answer. First, the notice period: IBM commits to "at least 12 months of notice prior to an IBM branded product release's EOS date" — so the day 9.4's date appears in an announcement letter, you have a minimum of a year. Second, the calendar convention: IBM coordinates most EOS dates onto April 30 or September 30, and MQ has been a September product since 2015. Third, the floor: an MQ LTS release "is supported for at least five years" from general availability — for 9.4, GA June 18, 2024, that arithmetic forbids any end of support before mid-2029.

What we will not do is print a predicted date — that is how wrong numbers get laundered into procurement documents. What the record shows, as observed fact: every 9.x LTS release has received its end of support on the first September 30 slightly more than five years after it shipped — 9.0 (June 2016 → September 2021), 9.1 (July 2018 → September 2023), 9.2 (July 2020 → September 2025), 9.3 (June 2022 → September 2027). When IBM announces 9.4's dates, our data layer picks them up and this table is corrected at the next site build — that is how this site stays honest about dates that move.

One caution against reading comfort into the blank cells: "no announced date" describes the 9.4 LTS release. A 9.4.x or 10.0.x CD installation is on the CD treadmill regardless — fix-eligible only while it is one of the two most recent CD releases or under 12 months old. The unannounced LTS date protects the estates on 9.4.0.x; it does nothing for a forgotten 9.4.2.

Who runs MQ — and why a dead queue manager is a compliance finding

MQ's install base is the definition of load-bearing: payment switches and core banking batch at retail and central banks, insurance policy administration, airline departure control and cargo messaging, manufacturing and logistics backbones — very often running on the same AIX-on-Power estates whose Technology Level clocks we covered this week, next to the Db2 databases with their own 2027 deadline. These are precisely the systems where "the queue manager just works" for a decade, where the middleware layer belongs to no application team, and where nobody's dashboard shows a V.R.M.F string. The IBM enterprise stack ages as a unit, and MQ is its quietest member.

The stakes are structural rather than dramatic, and we say that with a checked record: no IBM MQ entry appears in CISA's Known Exploited Vulnerabilities catalog as of the August 10, 2026 catalog release — we searched before writing this. (The catalog's MQ-sounding entries — Apache ActiveMQ and RocketMQ — are unrelated Apache projects; IBM's own KEV entries are Aspera Faspex, Data Risk Manager and WebSphere Application Server, not MQ.) But MQ does not need an exploitation headline to make an unsupported version expensive. IBM publishes security bulletins for MQ routinely, and the fixes ship as Cumulative Security Updates and fix packs to releases in support — a 9.2 queue manager without an Extended Support contract is outside that delivery machinery entirely, an unpatchable layer directly underneath the money. For an EU financial institution, that status has a regulatory name: under DORA's legacy-ICT provisions (in application since January 2025), unsupported ICT in critical functions is exactly what the framework makes management accountable for, and for essential entities NIS2 reads the same way. An auditor does not have to exploit a queue manager to write it up — IBM's published dates make the finding for them.

The honest-answer moment: dspmqver

Like oslevel -s on AIX, one command replaces the estate's belief with its state. On every MQ host, run dspmqver — the version line is the whole diagnosis. Read it against this article: 9.2.0.x or lower means paid-extension-or-unsupported today; 9.3.0.x means 414 days of standard support and a migration to schedule on your calendar rather than IBM's; a nonzero third digit (9.4.2, 9.3.5) means a CD release whose support depends on what IBM has shipped since, not on any date in this table. For the fleet view, DISPLAY QMGR CMDLEVEL VERSION in runmqsc does the same job from the queue manager side, and on z/OS the level is in the CSQY000I startup message.

The migration mechanics favor acting early, because MQ moves in one direction only. Per IBM's FAQ, queue managers migrate forward from any in-support release to a later one — but there is no going back: on distributed platforms backward migration is not provided, and "It is not possible to rollback any CD install." The saving grace is interoperability: queue managers at different versions interoperate in clusters and over channels, so an estate upgrades queue manager by queue manager, no big bang required. For a 9.2 or 9.3 estate the landing zones are 9.4 LTS (mid-lifecycle, dates unannounced) or 10.0 LTS (current, the longest runway) — and the same one-way-door logic that makes rollback impossible makes waiting for 9.3's final September a plan with no reverse gear.

We track IBM MQ and 480+ other products against vendor-verified dates — every IBM MQ release with live status, check any version in seconds, or see what else hits end of life this quarter.

Frequently Asked Questions

Related

• All IBM MQ releases with live status · IBM MQ 9.3 — dates and risk score
• IBM AIX End of Life: the Technology Level Clock — the operating system under most of these queue managers, with the same version-inside-a-version trap
• IBM End-of-Life Dates: The Complete Enterprise Matrix — z/OS, IBM i, Db2, and the Service Extension economics
• IBM Db2 End of Life: 11.5's 2027 Deadline — the database on the other side of the same estates
• DORA and Legacy ICT · NIS2 and EOL Compliance — what EU regulators expect when the vendor stops fixing
• The 2026 EOL Calendar — everything else with a September date