What’s vendor lock-in? Vendor lock-in refers to your inability to easily switch from one vendor’s service or products to another’s.

A quick reality check

I’ve spent 25+ years as a practitioner and during that time I was responsible for delivering services to over 150,000 users across several companies and industries. Around a year ago I joined Banyan Security as the CSO and now find myself in executive discussions related to our ability to be sticky as well as delight our customers.

So, before we talk about lock-in, let’s do a reality check on what drives a customer to look for the exit door. Over the years I’ve been part of these discussions and here’s the top 5 reasons I’ve observed over the years:

  • Price hikes: We once had an IAM platform that we were pretty pleased with, but the company was acquired and the new mothership decided a 50% price hike was what all the customers deserved. We instantly jumped into RFP mode and selected a new partner. This wasn’t a common experience, but understand that any price increase that doesn’t make sense will never go down well.
  • Service availability: All services have issues from time to time. So what’s important is to partner with your customers to ensure there’s transparency on the outage (root cause analysis RCA) with clear plans and timelines to address the issues. Communicate, communicate and then communicate some more. Some of the best cloud services actually post on their site the availability statistics for their services, outage information as well as other important service details. In one of my roles at Adobe in our early cloud days, I participated in our early version of this. It’s now a great example to learn from.
  • Lack of partnership: The difference between a vendor and a partner is building relationships and working together on strategies and tactics that improve both companies and teams. Remember all vendor products and services have issues from time to time or feature gaps. So what’s important is how you work together in a collaborative and transparent way continuing to improve the product for your customers/employees.
  • Feature delivery: Let’s be honest…the Sales team said they can do it all 😉 we even POC’d it, then after deployment realized a few gaps. So, it’s important to partner on what features are important.
    • As the customer, please be realistic; I often noticed my teams asking for our partner to solve world hunger. Not that we didn’t need what was being asked, but sometimes we get a little excited and think it’s the only opportunity to ask for everything. Asking is expected, but consider realistic dates and phase feature requests to be delivered over time.
    • As a partner, delivering something will be key to keeping the customer happy. A happy customer can be a useful one; more likely to participate in your whitepapers, case studies, videos, podcasts etc., etc… An unhappy customer is an entirely different story. They are likely to tell all of their friends and colleagues about their not-so-great experience.
    • Together, document all of the asks and create a dashboard showing what’s agreed upon, what’s parked, what’s delivered and be transparent on the percentage of features delivered versus what was asked.
  • Security, Trust and Transparency: It’s fair to say that these days any vendor can fall foul to a compromise. Your SOC2, ISO, and FedRamp doesn’t mean you’re safe, so being transparent on your security, compliance and other areas that build trust is vital. It not only helps retain customers, but to not lose prospects as well.

A little Banyan “Kool-Aid”

We pride ourselves at Banyan as our retention and expansion rates are both excellent. I learned the term “land and expand”; we do an excellent job at this. This speaks to how our customers see real value in what we deliver and in part the five points above.

So, before we talk lock-in, it’s important to ensure you avoid frustrating your customers to the point where they want to look elsewhere.

Five tips to avoid vendor lock-in

So, let’s get to the juicy part. As practitioners I’m sure we’ve all been through the fun of a love- hate relationship with a vendor. It always starts with the sales team promising the world, being your best friend, inviting you to all sorts of fancy events until finally the deal is done…and like a cheap magician in Las Vegas they disappear in a puff of smoke. Over to the next team, often some overpriced PS (Professional Services) team or a 3rd party solutions provider. Finally, the project is deployed and you realize the Sales pitch, slides and other stuff do not exactly match your new services reality.

Hopefully for you, that’s a rare event – I’ve been blessed to work with some great companies and products over the years as well as hired great people. I think of these relationships not as vendors but as partners – even as part of our team. The reality is we thrive or fail together.

So, even if you know the partner you’re working with, their objective is to make their product sticky and hard to walk away from; while your job is to ensure you can walk away (or migrate away) if things don’t work out.

Here’s my top 5 considerations that should help reduce being locked up tighter than….{insert your own joke here} … well, then you’d like…

First of all, all of these assume the product or service may be on-premises or hosted in a cloud service.

  • Data portability: Remember, it’s your data and you remain responsible. Consider how you store the data, its format, and if it’s replicated, backed up, or somehow copied in other locations. Having an architecture diagram just for the data, where it resides, and what has access to it is critical. If you plan to exit, ideally you take ALL the data with you and ensure the vendor deletes all copies. This means planning for that up front.
  • Standards: Cue the “eye rolling” – yes standards go without saying, but it needs to be said. It’s vital that you dig into standards. Years ago (around 2003) one of my engineers decided we’d jump on that SAML thing. Awesome, I thought. At that time, we used an open source platform for SSO, but as we grew so did our issues until we decided to partner with Okta. Since we followed standards, it was easy to migrate, and fast. We migrated 300 applications in 6 weeks. Of course, I reminded Okta of that – hinting that we could also move away quickly. Being a great partner, that never happened; but the point being – with standards you can act quickly.
  • Dependencies/Integrations: In the same vein as knowing your data architecture, you should also fully understand the dependencies and integrations of the service. Moving away means you know the total cost of such a move; financial and also user experience, workflow changes, and security implications.
  • Multi-vendor approach: Years ago, I learned a little bit about vendor strategies and avoiding lock-in. It was the first time I observed how shopping malls are designed and the strategy of designing a good mall. In order to maximize business there’s two anchor stores – one at each end, then in between a mix of smaller and medium stores and usually a food court. The parallel here is the anchor stores, the mall retained bargaining power with them, enabling them to play one off of the other. Many of us have seen this in recent years with AWS, GCP, OCI, and Azure – four cloud services with AWS being the dominant player, however over time the other three entice customers using a lower cost of entry; which means customers adopted a multi-cloud strategy. Playing them against each other for price, quality, and features. It’s more work for us, but it’s a viable strategy.
  • Developing an exit strategy: I’ve rarely seen anyone do this to any great level of detail, but it’s useful as part of any initial investment to document some ideas about your exit plan. I’ve done this many times over the years; especially on large investments. Of course, it’s impossible to be to detailed, but at a high level, capture some thoughts (and assuming a migration):
    • Cost of replacement products/services
    • Cost of migration (PS, FTEs, including partner/application teams)
    • Duration of a migration
    • Impact to end users
    • Cost savings


Obviously, there’s a battle between a vendor trying to be sticky and the customer trying to avoid lock-in. But the real message is that while both can be true, the real win-win is that of partnership. I’ve been proud of the partnerships my teams have established over the years. In some cases, we’re pushing the vendor to adopt our ideas and sharing code (or examples). In other cases, we helped them into a partnership with other vendors we’ve worked with to integrate and deliver end to end solutions to our employees.

I think I’ve managed to avoid playing some buzzword bingo – isn’t that refreshing! – and hopefully this proves helpful for you. Reach out to me if you have any questions or would like to discuss.

author avatar
Den Jones