IBM MQ Consulting & Services
AceMQ's IBM MQ engineers have supported 160+ enterprise customers across banking, healthcare, and government. We cover architecture, performance tuning, security hardening, and 24/7 incident response with a 15-minute emergency SLA.
A senior engineer, not an SDR. No sales sequence attached.
Without a forced migration off IBM MQFor production incident cover, see AceMQ IBM MQ 24/7 support.
Customers
Partners
The Problem
Eight IBM MQ problems that teams bring to AceMQ, from a queue manager log that fills before anyone is alerted and channels stuck in retrying, to dead-letter queues with no owner and a multi-instance failover that was never tested. If one describes your week, that is where the review starts.
The queue manager fills its log and stops accepting messages before anyone sees an alert
Channels drop into a retrying state after a network blip and need a manual restart to recover
Messages sit on the dead-letter queue and the reason codes have never been mapped to owners
A queue-full condition on one application backs up an unrelated line of business
Client applications are on a level whose TLS cipher specs the queue manager no longer accepts
Multi-instance queue managers were configured at install and the failover has never been tested since
Licence and support costs keep rising while the workload on the estate has not
The people who designed the MQ estate have retired and the topology exists only in their heads
A good fit if you run IBM MQ in production, on distributed platforms or z/OS, and want senior engineers who stay on a problem until the root cause is written down, whether you plan to stay on IBM MQ or move off it.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy IBM MQ.
How it breaks, and the fix
A unit of work that stays open pins the oldest log extent the IBM MQ queue manager still needs. Persistent messages from every other application keep writing to the same log, so when the log files run out, persistent puts fail on every queue, not only the batch job's.
One open unit of work, one shared recovery log
Two applications, one IBM MQ queue manager, three queues
Queue manager logAll three queues drain as they fill. Log use rises and falls as the queue manager reuses its log extents.
The statement batch job reads messages for an hour without committing. The oldest log extent stays pinned, the log fills, and persistent puts fail for both applications, including payments, which had nothing wrong with it.
The batch job commits in bounded batches, the log is sized from measured peak use, and the statements queue has a maximum depth. Payments keep putting messages and only statements waits.
A full recovery log is one of the incidents that brings teams to AceMQ for IBM MQ, and the cause is rarely a lack of disk. The fix is a few settings and one habit: find the connection holding the oldest unit of work and commit or roll it back, change the job to commit every fixed number of messages, size the primary and secondary log files from measured peak use, set a maximum depth on queues that can back up, and alert on log use and on the age of the oldest unit of work. AceMQ also reviews dead-letter handling and channel recovery on the same visit.
Our Services
AceMQ runs four IBM MQ service lines: architecture and design, performance tuning, migration planning and upgrades, and security and compliance. A senior engineer leads each one, and any of them can roll into 24/7 support with a 15-minute emergency SLA.
We design IBM MQ deployments that meet enterprise reliability, compliance, and throughput requirements — from single queue manager to multi-site RDQM clusters.
IBM MQ performance depends on a complex interplay of channel parameters, queue depths, and system resource allocation. We know every tuning lever.
Whether upgrading IBM MQ versions, migrating to the cloud, or moving to a modern messaging platform — we plan every step to eliminate risk.
Regulated industries trust IBM MQ — we ensure your deployment meets the security posture those environments require.
Named senior engineers on your account — 15-minute emergency response, no ticket routing, no junior triage.
24/7 Support
AceMQ IBM MQ support gives you a named senior engineer and a 15-minute first response when production is down, 24/7, on distributed platforms and z/OS. Lower severities get 1-hour, 4-hour and next-day responses, and every P1 ends with a written root-cause analysis.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Every ticket is handled by a senior SME assigned to your account — not a pool of anonymous agents. Zero cold-start. No re-explaining your environment.
Any ticket can be escalated to a live session with your named engineer via calendar booking. No gatekeeping, no approval required — direct access, always.
Quarterly health checks on your deployment plus shared intelligence from our support customers — we surface risks before they reach production.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
How It Works
An AceMQ IBM MQ engagement runs in four stages: a queue manager assessment of 1 to 2 weeks, written findings within a week, changes made with your engineers and staged per queue manager, then a handover with runbooks for channel recovery, dead-letter handling and a tested failover.
1–2 weeks
We review queue manager configuration, channel and cluster definitions, log and persistence settings, TLS configuration and dead-letter routing across the estate — then show you which parts your current traffic genuinely stresses.
Within a week
Prioritised findings with the reasoning attached, written so they hold up in front of an architecture review board as well as an engineering team.
Scoped per engagement
We apply MQSC and channel changes, TLS updates and queue policy changes with your engineers rather than around them, staged per queue manager and reversible.
Ongoing
Runbooks for channel recovery, dead-letter handling and a tested multi-instance failover, plus 24/7 support with a 15-minute emergency SLA if you want it.
A senior engineer, not an SDR. No sales sequence attached.
Customer Success
IBM MQ work from AceMQ: migrations off IBM MQ, support model and cost assessments, and production incident cases. Each card links to the full write-up: the environment, what AceMQ assessed or changed, and the result.
Enterprise Financial Services Organizations
AceMQ advises enterprises transitioning IBM MQ workloads to modern messaging platforms, routing workloads to Kafka for event streaming or RabbitMQ for transactional messaging based on specific use case requirements.
Kafka
IBM MQ
RabbitMQAmerican National Insurance
AceMQ led the phased migration of American National Insurance's IBM MQ infrastructure to RabbitMQ, including legacy code refactoring and HIPAA-compliant data handling across Windows and mainframe queue environments.
IBM MQRabbitMQ
KubernetesGlobal Technology Enterprise
AceMQ and a global technology partner developed a joint motion for displacing IBM MQ in enterprise accounts, leveraging RabbitMQ as a cost-effective open-source alternative with AceMQ's commercial support model.
IBM MQRabbitMQKafkaFinancial Services Organizations
AceMQ helps financial services organizations replace costly IBM MQ deployments with RabbitMQ, providing the commercial support and SLA guarantees that regulated industries require while dramatically reducing messaging infrastructure costs.
IBM MQRabbitMQGovernment / Law Enforcement Agency
AceMQ provided a support model and SLA comparison for a government agency evaluating alternatives to IBM MQ support, including 48-hour critical patch response commitments and compliance documentation capabilities.
IBM MQEnterprise Organizations
AceMQ's IBM MQ TCO assessment quantifies licensing, operational, and risk costs of IBM MQ deployments and presents a structured comparison against open-source alternatives with AceMQ commercial support.
IBM MQRabbitMQSolutions
AceMQ covers IBM MQ end to end: queue manager consulting and upgrades, 24/7 support and incident management, proactive monitoring, managed queue managers on your infrastructure or on AceMQ's, cover for versions past IBM standard support, a fixed-price health check and migration off IBM MQ.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running IBM MQ for you.
Compare the four IBM MQ support tiersSide by side
IBM MQ support comes in three forms. IBM Software Subscription and Support covers versions inside IBM's standard window. IBM Extended Support is a paid, limited extension for versions past it. Third-party support from AceMQ covers operations and incidents on any version and runs alongside IBM or on its own. Each row below answers one question.
| Question | IBM Software Subscription and Support | IBM Extended Support | AceMQ third-party support |
|---|---|---|---|
| What does it cover? | Fix packs, new versions and IBM support for a version inside its support window. | A limited scope and a limited term for a version past standard support. | Operations, troubleshooting and incident response on any IBM MQ version, IBM MQ Advanced, the IBM MQ Appliance and older WebSphere MQ. |
| Which versions are included? | Versions inside IBM's standard window. 9.3 is inside it until 30 September 2027. | Versions IBM has moved to Extended Support. For 9.1 it runs to 30 September 2027 and for 9.2 to 30 September 2029. | Any version, including those IBM no longer supports. |
| Who answers an incident? | IBM support, under your entitlement and its severity rules. | IBM support, within the limited scope of the extension. | A named senior AceMQ engineer, within 15 minutes for a P1, 24/7. |
| Where do fixes come from? | IBM ships fix packs and new versions. | IBM, within the limits of the extension. | AceMQ does not ship IBM fixes. It applies what IBM has released and gives workarounds and mitigations where official fixes are no longer available. |
| Can it run alongside IBM support? | It is the IBM entitlement itself. | It extends the IBM entitlement for one version. | Yes. It runs alongside IBM support or on its own. |
| What happens when a version runs out? | Upgrade to a supported release. | Use it as a bridge while an upgrade or migration runs, not as the plan. | A dated plan: support for the version you run today and a tested upgrade, with IBM MQ kept where it still fits. |
For the full upgrade or migrate decision, read the IBM MQ modernization guide. To see who supports IBM MQ, RabbitMQ, Kafka and other brokers in production, see message broker support options compared.
One partner, not five
IBM MQ rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
Guides from AceMQ engineers on IBM MQ end of support dates, support options, licensing cost and moving to RabbitMQ or Kafka, plus the AceMQ services for the brokers that usually run next to it.
FAQs
Seven answers on IBM MQ from AceMQ: supported versions and end of support, who answers when a queue manager fails, how an engagement starts, working with your team, why logs fill and channels retry, IBM support versus third-party support, and whether to upgrade or move.
Still have questions about IBM MQ? Email an Expert
AceMQ supports IBM MQ on any version, including IBM MQ Advanced, the IBM MQ Appliance and older WebSphere MQ. Per IBM's lifecycle page, 9.0 left standard support on 30 September 2021, 9.1 on 30 September 2023 and 9.2 on 30 September 2025. 9.3 reaches that point on 30 September 2027. IBM publishes no end-of-support date for 9.4.
A named AceMQ senior engineer answers within 15 minutes, 24/7, when an IBM MQ queue manager is down in production. Lower severities get a first response within 1 hour, 4 hours or the next day. The engineer who takes the first call stays on the case until it is resolved, on distributed platforms and z/OS alike.
An AceMQ IBM MQ engagement starts with a free consultation with a senior engineer, booked in our reply within 1 hour. Next comes a queue manager assessment of 1 to 2 weeks covering configuration, channels and clusters, logs and persistence, TLS and dead-letter routing. Written findings and a plan follow within a week, before anything changes.
Yes. AceMQ assigns a named senior engineer from its team of 11+ who works with your engineers rather than around them, applying MQSC, channel and TLS changes together. Every change is staged per queue manager and reversible, and you keep the runbooks for channel recovery, dead-letter handling and failover when the work is done.
A filling log is usually one long-running uncommitted unit of work pinning the oldest log extent. Channels stuck in retrying are usually a CHLAUTH rule, a TLS CipherSpec mismatch, an instance limit, or a firewall dropping idle connections. AceMQ engineers read the queue manager error log and the reason codes first, then change settings.
IBM Software Subscription and Support, bought through Passport Advantage, gives fix packs, new versions and IBM support inside a version's window. IBM Extended Support is a paid, limited extension for a version past it. Third-party support, which AceMQ provides, covers operations and incident response on any version and runs alongside IBM or on its own.
It depends on the workload. Flows that need z/OS queue managers or XA transactions usually stay on a supported IBM MQ release. Work queues and request/reply traffic move well to RabbitMQ, and event streams to Kafka. AceMQ assesses the estate, routes each workload on evidence, and phases the move so IBM MQ stays where it still fits.
Yes. AceMQ works on IBM MQ in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your IBM MQ environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how IBM MQ is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
Our senior IBM MQ engineers handle architecture, security hardening, and production incidents — with a 15-minute emergency SLA. Contact us today and we reply within 1 hour to scope an assessment.
Production incident right now?Email an IBM MQ Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
