‘You can check out any time you like, but you can never leave’
A Vendor Lock-In Consideration
Who hasn’t heard the famous song by the Eagles, Hotel California. It happened to play on the radio last week, when my colleague Hermen Vorstenbosch revealed that he had used this song as an analogy for the vendor lock-in phenomenon in the past. I thought that was quite brilliant, but it also got me thinking. How are MSPs navigating the treacherous road to success, which is apparently paved with years-long contracts and vendor-specific scripting tools?
For those wondering, a vendor lock-in is when a company becomes too dependent on a particular vendor, and is unable to switch to another unless they are willing to put in significant time and money.
From my own experience I know a vendor lock in is something to be avoided. Reasons being: you want to be agile, able to move to a new, better solution should one emerge. You want to avoid paying too much. Imagine being 6 months into a 3-year contract and coming across a cheaper solution that does the same thing. Uncool.
I also appreciate that a vendor lock-in doesn’t happen overnight, or even just by signing a contract. Indeed, a vendor-lock in can really sneak up on you. For example: you adopt a new RMM tool, and use built-in functionality to roll out policies and manage devices. Over time, you create additional scripts and solutions based on this platform-specific model. This is usually a gradual process, until one day you realize that most of your IP is based on this specific RMM tool. Switching to a different tool would mean losing all that you’ve built. Barring a massive amount of time, effort, and money, you’re now well and truly locked in, even should you be free to ‘check out’.
What are MSPs doing to avoid a vendor lock-in?
It may seem quite straightforward, but one of the things MSPs are doing to avoid getting locked in, is staying away from vendor specific automation and instead using the industry standard. In a Windows administrative scenario this is PowerShell. You can use PowerShell in combination with any RMM tooling, and any IP you build with PowerShell is yours and yours alone, even when you decide to switch tools once your contract is up for renewal. Additionally, any CTO worth their salt should, from time to time, take inventory of their vendor relationships, and consider how much it would cost in terms of effort and money to move away from them, and what the fallout of such a decision would be. Doing this will help businesses stay on top of exactly how dependent they are on vendors. Just like in a romantic relationship, it’s important that you would still be fine if your partner decided to leave. Difficult and unpleasant, sure, but ultimately fine. Treat your business the same way.
Leveraging PowerShell with Spinpanel Workspace
Not entirely coincidentally, the modern workspace solution provided by Spinpanel, Spinpanel Workspace, actually supports the use and roll-out of PowerShell scripts to devices, and allows this in a multi-tenant setup. One script to rule them all, so to speak. With Spinpanel Workspace you can go all-in and create the most amazing PowerShell script that you then roll out to different customers at once, perhaps with some tweaks per customer or department. So, not only do you not have any commitment contract-wise (you can cancel on a month-to-month basis), but also the IP you build and use with Spinpanel Workspace is yours, and reusable should you ever decide to look elsewhere. Though we think you won’t want to.
It seems strange that a way to promote a solution can be by describing how easy it is to get rid of, yet here we are. So once more for the record: Spinpanel Workspace does not require a contractual commitment beyond one month. You’re free to try out our solution and decide for yourself if the benefits outweigh the costs. Check out any time you like!
Author: Rianne van der Heijden, Customer Success Manager at Spinpanel