The three words that scare CIOs

There are three words guaranteed to strike fear into the heart of the most battle-hardened CIO. No, not "data center migration". I'm talking about "Vendor lock-in"*

We all REALLY CARE about this. At least, we think we do. But what exactly are we bothered about?

"The vendor will drop support for a product and then we will have to redevelop or migrate."

Good vendors don't make a habit of this. Often it makes more financial sense to maintain support for a product longer term than to lose customers, so the idea of deliberately pushing customers away is pretty unattractive. With a physical product with a well defined service life this may not be such as problem but still annoys customers a lot - home inkjet printers being my personal peeve. If the solution is strategic, maybe get long term support written into the contract. At the least, look for a vendor with a great track record of supporting old versions - we have customers running versions of our software up to 7 years old, still supported.

"If we're forced to change, maybe there won't be anything out there we like"

It may happen. That feature you need just went away or changed substantially. You have a part to play here: tell your vendor what you value about their product. I know, an account manager comes in and we all launch into all the things we can't stand, or are broken, or are slow/ugly/not the way we'd do it. But take some time to tell them about the cool feature, the neat API call, the integration you built. That gets back to the product team and they'll see why it's worth maintaining that thing that's important. If your vendor has a "customer success" team, get to talk to them too. They're often really great customer advocates inside your vendor's business.

"Upgrading commercial solutions is a nightmare, I'll use open source or I'll have little choice"

Some vendors do insist on "forklift upgrades", changing everything from UI to data models, OS platform and so on at once. Again, vendors generally have a good reason for this, but the key question to ask is whether the earliest version they have out in production can be upgraded to the current version and what the effort would be. If it can't, and a migration is needed, is it well documented and reliable? What is the impact of the change?

So is open source another solution to this? I don't think it's a panacea, since the hope is that the rest of the community wants the same level of stability that your organization needs. Although some open source products have good long term support, it's very hard to predict. In a previous role I inherited a strategic solution which was written in-house using Ruby on Rails 2. And then Ruby on Rails 3 came out, which meant every developer wanted to rewrite the code for that - and to make it worse, Ruby skills suddenly became very expensive, so either way we had a big bill to deal with. We went back to PHP for our next major development by the way.

Another example is CentOS. I'm a big CentOS fan, but the fact that I can't upgrade from 6 to 7 is a pain. I'd love to hear your comments on which vendors or open source communities do a good job of this. I'll vote for OpnSense to start!

At least with a commercial solution you have a contract in place, and can get some commercial leverage as protection. And you can see a track record, unless you take the risk with a new entrant into the market - then you're on your own!

"I'm sick of paying for version upgrades when I didn't ask for it to happen. I need to get off this upgrade carousel"

Me too! I still use Office 2010 on my Mac, it does what I need and I don't see a functional need to change. Actually, I'm still not keen on the Ribbon! But after the last MacOS upgrade Word and Excel started behaving unreliably. So now I have a choice: buy new software, or switch to LibreOffice, or Pages etc., or Office 365. And I don't get any trade-in, which is really irritating as I don't think I actually asked for this.

OK, it's a desktop package and I'm not really too bothered after 9 years, but extend this to a major corporate system and it's a much bigger deal. There are a couple of ways you can mitigate this:

Firstly, assuming that upgrading is straightforward, ensure your maintenance contract gets you all major versions as well as minor ones and bug fixes. If your vendor won't do this, that's a PRETTY BIG HINT that upgrade revenue is a significant element of their financials and there's an obvious conflict with your interests. Think very carefully about this vendor.

Second, usage-based contracts tend to get you version updates as the vendor sees it as a way to increase consumption. This is often a mutual interest, and one real way to partner with a vendor to succeed. They may help with adoption in other ways too, such as discounted training, webinars and so on.

"OK, I'm going to make everything vendor agnostic!"

It's an idea... but probably impossible. You want to get away from OS dependency - so go to Linux? Which version - commercial like RedHat, open source - see my experience with CentOS! How about dev language? Ruby was the future once... OK, how about hypervisor? ESX, KVM, Oracle VM, Hyper-V, AHV... Right, let's at least be cloud agnostic! At least that's possible, you can build many of the cloud services in dedicated VMs or containers. Some (like the Gartner analyst I spoke to recently) think companies will just use AWS or Azure, plug into their services and don't worry too much about portability. Others think that's nuts, citing experiences with the multiple versions of HP's cloud, and the constant shifting sands in the industry.

Vendor lock-in (with the right vendor) isn't so bad?

Personally, I think you have to decide on the value of vendor features, and how much you trust them to maintain the stability described elsewhere in this post. Then consider your own time to market, and figure out if the extra value of, say, VMware's DRS is worth the cost. Assume a migration in a 3 - 5 year timescale, and include that in your cost analysis.

Maybe "vendor lock-in" is really all about ROI in the end.

* Yes, I know that's arguably two words.