Upgrade Alternatives: How to Manage IBM WebSphere End of Support

WebSphere End of Support doesn’t necessarily mean a move to Liberty. Keep using what you have.

Companies tend to establish a complex relationship with the HCL® and IBM® WebSphere solutions they utilize well before a WebSphere End of Support (EOS) notice comes down the line. It’s a product that sits deep in the architecture. Fully understanding what it does to facilitate a given business’s processes requires a combination of contextual understanding and niche technical skill that can be difficult to source across even a large enterprise.

To their credit, IBM has publicly acknowledged the importance of their flagship middleware, WebSphere Application Server, in many corporate IT stacks and published plans to support certain traditional versions of the product through 2030.

But the real story is a bit more nuanced.

• There’s not just one WebSphere. There’s a cloud WebSphere, commonly referred to as Liberty. There are on-prem versions of WebSphere as well, collectively and unofficially referred to as WebSphere traditional. Some of the latter are supported through 2030, and some are not. Some are technically supported, but only under the proper configuration and dependent software conditions.
• Needing to move is not the same as knowing where to go. If they aren’t aware of other options, businesses with on-prem WebSphere deployments might plan to migrate some or all their workloads over time. But knowing the best technology to land on is a skill in and of itself, and so is building the transition plan from A to B.
• When it comes to support, a rose is not always a rose. WebSphere’s complexity and strongly regimented IBM software support standards can combine to make trouble when a business with unsupported configurations needs help.

Traditional WebSphere Application Server EOS dates

Per IBM, Big Blue will continue to provide standard support through at least 2030 for certain WebSphere Application Server products. This includes:

• WebSphere Application Server V8.5.5 and V9.0.5
• WebSphere Application Server Network Deployment V8.5.5 and V9.0.5
• WebSphere Application Server Family Edition V8.5.5 and V9.0.5
• WebSphere Application Server – Express V8.5.5 only
• WebSphere Application Server for z/OS, V8.5.5 and V9.0.5

Additionally, many current versions of WebSphere in active enterprise use have carried on service despite a lack of official support, including:

As you can see, the WebSphere Application Server family encompasses a huge number of products. In a traditional on-premises deployment, technology and business context play a large role in precisely what products and dependent software are used.

Common IBM® WebSphere support challenges

Released in 1998, the earliest version of WebSphere was primarily a Java servlet engine. Later versions allowed the software to incorporate more open-source frameworks. Businesses that integrated the product brought with them an endless list of use cases, deployment profiles, and dependent software needs.

Now, the same extensibility that allowed organizations to integrate the tool so deeply with key processes and service lines can become a stumbling block for app owners tasked with innovation and roadmap growth. IBM’s 2019 acquisition of Red Hat created more vendor-side pressure to move to cloud, even if companies are happy with the WebSphere Application Server implementations they currently have.

Your business might feel the pressure even if it faces no direct WebSphere End of Support date. Current customers of supported traditional WebSphere versions may use configurations and dependent products that diminish what help the OEM can provide. And that’s to say nothing of the many customers currently using WebSphere versions that have already been designated End of Support (EOS) status. While these customers may have varying levels of comfort supporting an unsupported implementation on their own, problems can and do arise. Some examples include the following:

• Interoperability challenges. Over time, even basic digital transformation and business upkeep tasks can create problems that cause the software to struggle in the new environment. This can lead to outages, poor performance, and expensive fixes that do little but return the company to baseline.
• Security concerns. Trusted points of infrastructure aren’t immune from new security concerns that arise, and long-standing vulnerabilities may be exploited in new ways. Either way, a lack of official IBM software security support can inaccurately lead a company to think there’s no way to secure the estate.
• Limited access to enhancements. Companies might think running an EOS version of WebSphere means missing out on capabilities newer versions offer. Realistically, there are ways to implement improvements that provide the same outcomes, with no costly upgrades or updates required.

Being able to support, secure, and extend the life of the WebSphere implementation you currently have – regardless of OEM support status – gives IT, business, and individual app leadership more control to do what you wish with the software, for as long as your company will need to use it.

Why third-party software maintenance?

Third-party software maintenance (TPSM) providers help companies enhance their current WebSphere implementations by giving them more control over the day-to-day maintenance of the software. Depending on the individual customer’s IT estate, that could mean finding ways to keep using the software, securely and fully maintained, past the OEM’s EOS date; resolving lingering issues the OEM service model seems reluctant to touch; or providing a white-glove source of ticket resolution. With middleware like WebSphere, a TPSM provider can also add value by stopping interoperability issues that technically stem beyond the software itself.

Let’s say a company faces an issue where no change has been made to the WebSphere implementation, but a third-party load balancer has undergone a recent unavoidable update that has caused other systems to stop communicating with WebSphere. When the load balancer is identified to be the culprit, the OEM’s likely suggested fix either fails to provide full resolution or funnels towards a cloud update the customer doesn’t need. In either event, the support the company receives is less likely to resolve the issue at hand the further it gets from the OEM’s product, as is custom in many areas of B2B software.

By contrast, working with a TPSM provider, the same business finds a source of expertise that doesn’t stop at the walls of the middleware, but instead helps the customer solve a problem without needing to move to an officially supported version.

Every business has different long-term plans for WebSphere. But the long-serving software doesn’t need to be an albatross, a financial burden, or a planning blocker. A TPSM can bring WebSphere products back into alignment with the business’s vision, giving it real utility in a modernized tech stack for a long time to come.

Keep WebSphere Application Server running as long as your company sees fit. Get started here with a free consultation.