Last week we spoke about iHealth and its plan to get out from under the costly maintenance programs offered by Oracle. The company likely would have moved much sooner had the migration path been easier, and many others would likely move if they weren't afraid of the unknown costs of moving from one vendor to another.
A few decades ago, I watched hundreds of companies complain about the same thing and then, in a matter of a few years, they broke free and moved off of their IBM mainframes. Ironically, many of them moved to Sun during its infancy and found that its platform at the time was immature and they regretted the move. This wasn't due to lock-in, this was due to not understanding that they were jumping from the frying pan into the fire. At that time, they likely would have been better off negotiating a better plan with IBM or moving to a similar platform from a more aggressively priced vendor. Eventually IBM refreshed its offerings and System Z is one of its most powerful and popular lines today.
Let's talk about vendor lock-in today and how to avoid compounding mistakes.
Lock-in: It's All in Your Mind (Well, Mostly)
On a smaller scale, I've watched for years how people have argued they were locked in to Windows and couldn't live on any other platform. Some of these same people tried an iPad last year and now are using a MacBook as their primary computer. Their lock-in, granted for a PC offering, was all in their mind. However, all platforms provide a way to extract data and if the data can be extracted, it can be migrated. All it takes is time and money, and as iHealth recently discovered, the money (recall that it estimated its payback on the entire project as under three years) is recoverable and removing the aggravation is well worth the effort.
However, the move does not come without cost and risk, and sometimes you don't know the hidden costs. One time my unit wanted to change payroll providers and we took the lowest bid only to find that, after we had canceled the contract, our CEO was on the board of the company we had been using and he took exception to our decision. You'd think someone would have thought to look for something like that, but when you change vendors, how often do you check to see where your executives are active?
It is these relationships that can be the bigger problem. After all, technology can be changed but people are much tougher.
Make Sure Your Destination Is Better
As companies moving off of IBM mainframes to Sun systems discovered, jumping from one problem doesn't necessarily mean that your destination is safe. It is always good to find some folks who have already made the jump and ask them what their experience was. This way, you make sure you learn from their expensive experience instead of from your own pocket.
Also make sure that you have exhausted all avenues of reconciliation. In iHealth's case, it simply became frustrated that Oracle was non-responsive and what Oracle had presented didn't give the company confidence of a safe future. It made a well-founded decision to move, and it didn't move from an enterprise-class vendor to an unknown. It moved to a well-regarded, enterprise-class vendor, IBM. This reduced its risk of unplanned surprises significantly and iHealth was not only able to save tons of money (recall over 50 percent of its maintenance fees), it was able to avoid increases for five years and to consolidate over 250 servers down to two large systems.
Grass always has the tendency to look greener on the other side, but often, and this is particularly true on new and untested systems, it isn't. Do your homework and make sure that what you are getting is really better than what you are giving up.
Wrapping up: Freedom
Moves don't come without risk, but often they are worth it. If a vendor is failing, if it is abusive in its practices or simply non-responsive, you have good reasons to move. You also have a good reason for a "come to Jesus" meeting with that vendor. Though, and this seemed to be the case with iHealth, often you are given no choice but to move. And if that's the case, buckle down, recognize that others have moved before you and seek their advice so you don't miss the frying pan. Don't just learn from iHealth's move, learn from its decision process in making it.