Upgrade Alternatives: What To Do When Your IBM MQ Has an EOS Date

The IBM® MQ (Message Queue) family is a prominent example of enterprise middleware with users in every corner of industry. Businesses rely on it to keep secure, continual, often asynchronous communication flowing between points in infrastructure, even when current circumstances prevent transmission.  

The tool’s central role, its flexibility, and the sheer number of essential communications it facilitates give it a continual presence in business, but those same traits can create strife when an end of support (EOS) notice comes down. In this update, you’ll learn a bit about MQ’s business use cases, the issues that arise when licensing and security needs become more complex, and ways to use third-party software maintenance (TPSM) to sidestep some of the most persistent resulting issues.  

What is IBM® MQ? 

Think of MQ as a facilitator. The messages it handles are by and large automated communications between technology systems, which tend to be highly distributed and specialized for different tasks. MQ sits in the middle, taking messages the one side sends and making sure those messages reach the other, even if the second point is currently unable to receive it.  

ATMs underscore one example of the value solutions like MQ provide. When a customer withdraws $100, the machine must make sure the central computer(s) handling balances are immediately updated with the change in balance. Keeping all possible users’ data active and up-to-date locally at each ATM isn’t viable for any number of technology and security reasons. That opens the gate to a tool that can:  

• Ensure messages with accurate account debit info reach the central computer, utilizing redundant measures to counteract almost any form of intermittent physical/software failure 
• Promote data hygiene, consistency, and the ability to forensically research, such as providing send receipts 
• Offer up-to-the-minute information on the user’s side, like account balances 

Of course, MQ is used well beyond the banking and finance worlds. A manufacturer in a supply chain might use it to ensure employee-facing systems that interface with production subsystems always have accurate information. Meanwhile, the retailer buying from them might use the same tool or infrastructure to instantly confirm product availability before placing a seasonal order, then again to create fluid communication between central systems (finance and inventory, for instance) and employee-/customer-powered endpoints, including checkout counters or self-checkout kiosks.  

IBM® MQ EOS dates 

Keeping aware of support lifecycles is an important part of avoiding unwelcome middleware security risks, along with potential unexpected costs and downtime. 

IBM® MQ products going EOS in 2023

What do IBM® MQ EOS dates mean for your business?  

When a product goes to EOS status, IBM no longer provides fixes or security patches for new threats that will emerge past the defined date. Without a viable backup support strategy in place, complex issues follow, most of them stemming from the central, bus-like nature the middleware plays in many enterprise implementations.  

Businesses with active IBM Software Subscription & Support (S&S) have the option to upgrade to an officially supported version of the MQ product they’re using. However, in a situation where MQ works well in its current state and an upgrade is not a part of your current IT roadmap, you might not want to throw the baby out with the bathwater. Upgrading often introduces more problems and risks, particularly with cybersecurity, where a patch, for example, can actually do more harm than good.  

Security is a top-level concern here, but not the only one. By the very nature of what it does, MQ’s tendrils tend to run deep anywhere it’s present in the enterprise estate. New issues and regressions are a constant source of concern any time a big-ticket or high-importance implementation faces a mandatory upgrade. Considering the delicate, mass-scale, highly distributed communications MQ facilitates, it’s easy to understand why a company might want to stand pat with the software it has already purchased and trusted for some time.  

For some of these customers, paying an additional fee for enhanced IBM support (alongside current S&S expenses) is a way to meet new concerns that might arise or take the edge off performance concerns. Of course, this option isn’t cheap, and diminishing service levels are almost to be expected. IBM’s move to cloud also logically means their revenue model works better with companies locked into a subscription-based, cloud-powered alternative instead of the currently implemented option.  

Is third-party software maintenance a reliable option for MQ?  

If upgrading or making substantial change to MQ is a cause for concern for your business, there’s a good chance your operations depend heavily on the family of middleware tools in some capacity. Or on the other end, a low-maintenance, relatively low-impact implementation that still carries important operations may create interoperability issues with larger systems if upgraded.  

On these grounds alone, TPSM is worth pursuing in the event of changing MQ licensing, security, or support. Gartner recommends the model in large part because it helps companies pick and choose the points of infrastructure they keep instead of potentially upgrading themselves into more headaches.   

With MQ, a middleware family that can intertwine quite deeply with fundamental aspects of day-to-day operations, the difference between an invested level of support and a merely costly one is apparent. Companies in the TPSM arena tend to preach a proactive, holistic approach to security and maintenance because that’s what creates the best, most secure outcomes. TPSM services also cost less than S&S or extended service contracts, outpacing OEM megavendors by up to 50% of their standard fees.  

In most cases, keeping a long-serving MQ install running past its EOS date is a matter of having a failsafe in place – someone on-hand to respond to emergencies and answer questions that, while important, aren’t worth paying the significant dollars OEMs might charge for extended service. Other times, a small bit of software security advice the OEM wouldn’t think to offer might be all it takes to justify the change. The TPSM model does well with all types of software, but the comprehensive approach thrives with an overarching bit of middleware like MQ.