If you’re paying for vendor maintenance, it makes sense to use that to your advantage

Last month, I wrote a piece called “Know Where Your Maintenance Stands.” The article focused on IBM-provided maintenance. Consider this a lengthy addendum. This time, we’re talking about vendor maintenance. We’re talking about upgrade problems. We’re talking about being caught in an unsupportable nightmare. It’s a cautionary tale.

Given that IBM i 7.4 was released a few short weeks ago, I’ve been talking to many customers about when they’ll be upgrading to it. Many who’ve come to 7.3 recently feel little tension for change. Those on 7.2 feel the crunch a little bit more. They understand 7.2 is a little longer in the tooth and wanted to wait for 7.4 to make the move. And there are some stragglers on 7.1 who paid double their software maintenance this last year or so and they want to do get to 7.4. For them, we’re talking about a two-step upgrade because you can’t go directly from 7.1 to 7.4. They’ll have to go to 7.2 or 7.3 before going to 7.4.

What about shops running older versions of IBM i? They’re still out there. I brought a company from 6.1 to 7.3 in a two-step upgrade about a week ago.

What about even older than that? What if you’re on something like V5Rx? Some people are wriggling uncomfortably in their chairs while reading that sentence. Yes, there are systems out there running some V5Rx currently. And they need help.

It’s not an insurmountable feat to move people forward from those very old operating systems to modern-day supported releases. They just need supported hardware or cloud to run it on. I’ve brought a couple of V5R4 customers to 7.3 in the cloud in the last year. Luckily, passing the object observability tests weren’t an issue. In order to get to 6.1 or above, your objects must be observable. You need to have a couple of PTFs on so that the operating system knows what 6.1 is and enables you to run an Analyze Object Conversion (ANZOBJCVN). If you pass that test, your objects can be recovered to a new version. For those customers, vendor software tied to serial numbers weren’t an issue either. Some vendors base their license keys on the serial number, processor tier, processor core count, and/or even the partition ID. If something changes, the software either stops working or kicks out messages to the QSYSOPR message queue nonstop.

This is where leaving your system back on a very old release can get problematic. I’ll give you a couple of examples.

Customer X is running a POWER5 with V5R4. They wanted to move to a POWER9 and get back on IBM maintenance. The absolute first thing I did was run an Analyze Object Conversion. Lo and behold, there were issues with three vendor packages. All the custom objects were fine. So for the next few hours I acquainted myself with vendors the customer didn’t even know were still in business. I had never heard of them either, but I initiated my Google-Fu and put in some calls to vendors in the UK, Florida, and Minnesota. All three of them were still in business and were amazed at the old versions still being used in production. One of those vendors had a serial number tied to their license keys. The cost for new keys? $150 USD. The other two vendors wanted the customer back on yearly support to get the post-6.1 observable objects. The cost? $600 USD combined. And they agreed to assist with migration issues if they came up. Very reasonable. The customer has no idea how lucky they were. It could’ve been much worse.

Customer Y is also running a POWER5 but with V5R2. They have one vendor solution on the system, and everything else is homegrown. The customer tells me they wanted to move about 10 years ago, but the cost of migrating the vendor solution was too large to justify due to the manual object change work that would have to be done. So they figured they’d run out the clock on the software and system, hoping the business would find another solution. Fast-forward to 2019 and the customer is still paying hardware maintenance on this machine to IBM. The yearly cost of maintenance far exceeds the cost of the original migration. They ask me to see what I can do. They did not pass the Analyze Object Conversion test. If the vendor can help them, then they’re open to go cloud or POWER9. And the horsepower on the POWER5 is so weak compared to a POWER9 S914 that it wouldn’t take much of a machine to accept the workload.

So I track down this vendor who still exists and still supports that product as part of their “legacy” code base. The software is tied to the serial number. But the support the vendor offers isn’t on that version. It had been rebranded twice and bolted onto another package in the last 20 years. When the customer inquired 10 years ago, they were already 10 years out of support. The vendor took two days to find someone to even identify the product was something they actually made. The vendor says it would take about $1500 to put the customer back on maintenance again. Not bad. But here’s the rub: the software version is so old that they claim to be unable to even generate license keys for it anymore. That means the customer is past the point of no return. They’re left with iron too expensive to maintain, with no helping hand to get them to a less-costly solution. And their plan of running out the clock continues until they replace the product with another one, leaving IBM Power Systems behind and spending far more than if they had kept their investment up to date every couple of years.

Modernization can mean many things. Slow and steady progression is one of them. If you’re paying for vendor maintenance, it makes sense to use that to your advantage. Vendors don’t want to leave any customer behind, and many will do whatever they can to keep an existing customer. Customer X is a great example of that. There are some who are more expensive than others, and when I was a customer I hated the idea of paying money because my serial number changed. But when you look at it in retrospect, you can see the one-time cost can be a drop in the bucket compared to, like Customer Y, being 15 to 20 years out of date on both hardware and software and looking for a path forward.