Vendor Lock-In Shouldn't Be A Barrier To Digital Transformation
Vendor lock-in can be a huge worry for anyone thinking about Cloud Migration. Knowledge (and the right partner) is key to mitigating that risk
Whilst the entire world seems to be going through a Cloud-Migration at the moment, all looking for the awesome benefits over their competitors (such as increased agility, flexibility and huge cost savings) that it brings, many still shy away from it for a variety of reasons.
One of the biggest is something called Vendor Lock-In.
After all, having the bedrock of your entire IT infrastructure in the hands of a third-party would give anyone pause, right?
What Is Vendor Lock-In?
The classic definition of vendor lock-in is an organisation that finds itself in a situation where the cost of switching to a different vendor is so high that they’re basically ‘stuck’ with their original vendor permanently, normally occurring due to over-reliance on said, single vendor.
It’s still technically possible to leave (assuming no contracts with fixed terms are in place) but it just isn’t economically viable to do so.
Small organisations (for example a small charity or membership organisation) are especially vulnerable to this kind of situation, as, at the start of a cloud-migration journey, they might opt for an ‘out of the box, one size fit’s all’ solution, only to find that, as they grow, it’s no longer fit for purpose but still far too expensive to move away from.
So, is vendor lock-in just another cost of doing business? Impossible to avoid if an organisation wants to migrate to the cloud?
If that was the case this would be a much shorter article!
For anyone doing their due diligence correctly, there are a number of steps that can be taken ahead of a cloud-migration that will let your organisation retain the flexibility it might need to adapt to changes in their sector as they grow.
Why Is Vendor Lock-In Such A Big Deal?
Before we start though, it’s probably worth just going into a little more detail on why vendor lock-in can be so bad.
Why that is will depend very much on who you speak to within your organisation.
Your finance team will give you a completely different answer than your IT team will (though both will be in agreement it’s bad).
It could be the loss of control of the organisations key systems or data.
There could be concerns over cloud-based security or server uptime.
Finance might be worried on the reliance to a single vendor for so many business-critical systems.
The board might have concerns around what happens when the organisation grows… will the current solution be suitable, can it grow as you do and if it can’t, can you get out of the agreement?
What happens if your cloud-provider goes out of business? Can you just pick up and move then? How will you be affected?
There’s a lot of issues there so let’s try and unpack some of the more commonly asked about risks in a bit more detail…
VENDOR LOCK-IN & DATA SECURITY
Take it from us… shifting data from one Cloud Service Provider (CSP) to another is not easy! Trying to do so always leaves you with a pile of complicated questions…
- Whose responsibility is it to extract all the data from its current locations? The existing CSP or the new one? This can be made even more difficult if there’s any bad blood between the existing CSP and yourself as they won’t exactly be bending over backwards to be helpful.
- What format is the data even going to be in? This can be particularly problematic if, for instance, you’ve made the choice to shift from AWS to Azure as quite significant changes to the data might need to be made to make it compatible.
- Can the data be transferred without any down time to the organisation’s day to day activities?
- How long, and more importantly, how much will all this cost?
There have been moves in recent years to standardise data interchanges… this was the driving force behind Microsoft’s Common Data Model for instance, but no two organisations are ever alike so it’s never a perfect fit.
APP TRANSFER WITH VENDOR LOCK-IN
If your organisation has Apps or Bespoke Software at play, all leveraging your CSP’s proprietary tech, then reconfiguring all of that can be a scary proposition.
Let’s say you’re running Microsoft’s Power BI on Azure for example, but have also layered it with Microsoft’s Machine Learning, datalakes analytics and Robotic Process Automations (RPA’s).
Where do you even start in getting all that to run efficiently on a different CSP?
THE ‘PERSONAL ELEMENT’ TO VENDOR LOCK-IN
No one Cloud Service Provider does something the same as the next. Those differences in service can be subtle (but very present) or they can vary wildly.
If your organisation has been with a CSP for a long period of time it’s likely they’ve picked up a lot of background knowledge as to how that CSP’s systems run and can be configured.
Moving CSP’s therefore will mean your IT Team’s need to quickly consume a whole new subset of operating data, other departments will need to learn about new User Interfaces; in short, if you’re not careful… it can be chaos!
7 Tips For Preventing Vendor Lock-In
Now we’ve a better understanding of what vendor lock-in is and why it can be so damaging to an organisation with growth aspirations, let’s talk about some active steps that can be taken to stave off the risks associated with it.
Migrating to the Cloud is absolutely the right thing to do. Before you do it however it’s vital you make sure both yourself and your IT teams do their due diligence to mitigate as many vendor lock-in risks as possible.
Ask yourself… why are you moving to the cloud now, what do you need a CSP to achieve right now and, perhaps most importantly, what might you need it to do in twelve months or five years’ time?
Can your chosen CSP service all those requirements?
If it can only match some of those needs you’ll have to prioritise what’s important, compare it to other CSP offerings and decide what’s best, whilst perhaps taking some of the other steps below to leave you in the strongest possible position.
When it comes time to signing the contracts, make sure you’ve put in place something called Target State Architecture. Agree in advance what the ideal solution looks like and make sure everything after is incrementally building towards that.
If you’re strict on governance and what’s in scope and keep all your vendor(s)/developers/engineers singing from the same hymn, you shouldn’t go too far wrong even if priorities change over time.
Make sure everyone knows what the big picture is and what they’re working towards. Making everyone accountable to the foundations of your Digital Transformation means they have to integrate, have to be open, and anything bespoke is built to ‘play nice’.
SEE IF YOU CAN SIGN A PRE-NUP
No, we’re not joking (well not really).
A cloud migration can be a little like a marriage. Fingers crossed you’ll both be happy together and live to a ripe old age but… should the worst happen it makes sense to have taken steps to protect yourself.
When looking at the contract make sure you’ve studied the exit costs and that these are factored into any ongoing transformational strategy as a potential cost to growth.
It’s also important when entering into an agreement with a CSP that you go over their exit polices with a fine-tooth comb.
Doing that will be less about the technical aspects and more about your/their legal/financial obligations. Putting data into the cloud is normally quite an easy ‘lift n shift’ process but taking it back out can be a very different matter.
There may be hidden fees for migrating data away from them, it may be in different format that’s unusable elsewhere or there may be IP that can no longer be used.
Understanding all of that will be vital to any successful exit strategy/cloud migration.
DESIGN YOUR APPS, PROCESSES & GOVERNANCE WITH AN EXIT IN MIND
When you (or a third-party software partner) are designing your organisations apps and processes bear in mind the possibility you might need to leave your CSP one day by creating them as platform agnostic as possible.
Make sure you’ve great documentation describing all your tech, with staff you’ve specifically up skilled in its use. Then, if you and your provider do ever part ways you won’t have to waste time and resource figuring out what it’s meant to do or reverse engineering it.
With that in mind, it’s a good idea to choose a CSP on an Open Platform so you can see the code behind the service, with API’s that can communicate with it.
WATCH HOW YOUR DATA GETS FORMATTED
When migrating, it’s always an organisations data that causes the biggest issues.
Different CSP’s all use different data formats and models, none of which are very compatible with each other.
As we’ve already mentioned, great strides have been made in recent years into standardising data, but the guidelines and protocols unfortunately aren’t always followed or adhered to.
Therefore, if you want to maximise the portability of your data you need to make sure you avoid any proprietary formatting with your CSP.
Data lock-in is the hardest part of vendor lock-in to overcome so taking steps to mitigate these risks at contract stage pays dividends later on.
JUST USE MULTIPLE CLOUD SERVICE PROVIDERS
No one ever said you were only allowed to use one.
More and more organisations are moving to a multi-cloud solution, leverage different CSP’s offerings and tools for different functions within their organisation.
Having a layer of AI from one CSP, your data storage from a second and your processing power from a third leaves you much less vulnerable to vendor lock-in whilst allowing for a cherry-picking of tools that gives you a ‘best of all worlds’ solution.
There is a downside though (isn’t there always?).
Multiple Cloud Service Providers means there’s a much greater strain on your Development Team making sure they can all talk to each other, if you’re not careful your security might not be as strong and of course there may be additional licensing costs.
TREAT YOUR CLOUD-MIGRATION LIKE LEGO
It’s ok we’ve not gone crazy, nor are we suggesting you try and build a castle or spaceship with your CSP (although…)
What we’re talking about here is something called component-led development.
Build things in isolation, that fit together after… like Lego.
That way, if you decide to stop or change, you’re not stuck without the missing final piece of the puzzle. You’ll also get the great benefit of being able to reuse components for other features.
MAKE SURE YOUR INTELLECTUAL PROPERTY IS REALLY YOURS
When we talk about IP in terms of Cloud Service Providers, we’re talking about the unique dev work you’ve done to make everything compatible with your organisational needs.
One of the risks with cloud migration you need to head of early is discovering that they own critical parts of your system meaning you either need to stay put, negotiate to continue using that element or re-build it all from the ground up.
You can contract your way out of this, coming to an agreement whereby you own all your own custom development, but you need to come to that agreement at contract stage.
Finishing up, getting locked into a single vendor can be a painful and expensive experience for an organisation.
We absolute don’t want to scare you away from migrating to the cloud, we believe it’s 100% the right thing to do but before you do it it’s important you do your due diligence and make sure the move is both right for you now and will be in the future.
That’s why having an independent third-party partner to guide you through the process can be so important.
- Make sure it’s right for you now and in the future (Build Future)
- Make sure you have an exit strategy just in case
- Avoid proprietary formatting
- Consider a multi-cloud function
- And above all work with the right partner.
Finally, don’t try and reinvent the wheel.
If there’s already a solution out there, don’t rebuild it if you can avoid it, integrate it into your new platform.
Follow those steps and you’ll be well on your way to your own Digital Transformation!