Subscribe To Our Daily Enewsletter:

Cloud Vendor Lock-in: Myth or Reality?

I’m often asked by clients whether they should restrict their use of the more advanced cloud features, such as certain Platform-as-a-Service (PaaS) capabilities. They share a common concern: the fear of vendor lock-in and lack of portability should they want to change their cloud supplier in the future. So is this a genuine threat or an unsubstantiated barrier to achieving cloud adoption?

In some circumstances, I believe their concerns are well founded. That’s because a degree of vendor lock-in is almost unavoidable, whether it’s due to complex PaaS use, or simply down to different standard compute sizing. But it is a concern that can be turned into an opportunity with a common sense approach and, above all, a well-defined exit strategy.

Having had their fingers burnt by legacy vendor lock-in contracts in the past, CIOs today habitually ask how easy it is to get out of traditional IT outsourcing deals if the situation changes. So why shouldn’t the same apply to a cloud solution? After all, we’re still talking about technology services, whether they’re delivered from the cloud or via traditional means. Put simply, when organizations build their cloud business case, they need to factor in the cost of exit along with the obvious benefits of moving to the cloud, such as agility and flexibility.

This is becoming increasingly important as corporate IT pushes ahead with a cloud-first strategy, gradually shifting the balance from traditional IT to cloud environments. The challenge is always that what is right today won’t, in all probability, be right in two or three years’ time. You only have to look at the public sector IT in the UK, which has transformed considerably in only a few years. What would have been heresy to IT leaders in the business impact level-driven world of just two or three years ago, is now increasingly the norm with the adoption of services on Amazon Web Services and Microsoft Azure, or Google’s analytics cloud platform.

These compelling cloud offerings provide the agility that’s essential in today’s fast-paced digital world, but what about in three years down the line? I would urge thinking twice before being seduced into using a single vendor’s full range of complex services to create a custom build. Why? Let’s say you’re customizing all your front-end CRM with cloud-vendor specific components to drive business agility. Staying ahead of the competition over time in this key customer-facing area may require a switch of vendor for some of the components. This can be costly and time consuming unless the possibility is factored in from the outset.

So when it comes to vendor lock-in, there are some fundamental approaches that can help. One important consideration in “future-proofing” your cloud-based applications is the portability of the data. For example, many applications built today using PaaS, may well be delivered in a Software-as-a-Service (SaaS) model in the not so distant future. Today’s differentiating service can become a commodity service in a matter of months. This means that application portability will be less important than data portability because the application is already created and available. So you need to define a path taking your data from PaaS to SaaS, and try to avoid proprietary formatting of data. Further, documenting business rules must be made easy with a standardized format that can then be exported and coded for a new platform or SaaS configuration.

Spending valuable time coding business rules into an application is an investment that needs to be recoverable in the event of a migration.

At a more granular level, the configuration of an infrastructure-as-a-service- (IaaS) based implementation of any serious complexity also needs to be recoverable. The use of tools such as Terraform, and utilizing Object Relational Mapping (ORM) to create abstraction layers so that the design is portable across vendors, is one way to achieve this. Overall, it all comes down to building in portability from the start.

It’s clear that avoiding the pitfalls of vendor lock-in is all about thinking in terms of how you exit the original deal from day one. That means ensuring your design, data and processes are in a standard format that can be easily applied to your future technology environments. If portability is likely to be required, my advice would be to only use niche cloud vendor-specific services where they absolutely provide definite business benefits and justify the Return on Investment within a two to three years’ timeline.

With careful planning and design, vendor lock-in can be significantly reduced and the risk of unplanned costs in the future reduced. The key is to design portability in from the start and to factor the cost of exit into the initial value case. In time, with the development of technologies that implement abstraction layers, portability at the IaaS layer will become increasingly common if designed in from the outset. But for now, care in implementing as-a-service-based solutions so that they are at least aware of the potential exit and migrations costs will ensure there are no nasty surprises later on.

Practical steps to avoid the pitfalls of vendor lock-in

To summarize:

1. Plan Your Exit
Before you go into a new cloud contract, make sure you have an exit strategy in place because nothing stands still in the world of IT. Only think in terms of a two to three year horizon and include the cost of exit in your cloud value case.

2. Manage Your Data
Ensure your cloud solution is data centric. Is there a service that enables you to extract data economically? And is there a “point of presence” where you can get at it easily? Portability of your data will overtake portability of your applications as a priority as your cloud solution evolves.

3. Define The Business Rules
Visible business rules should be defined and documented in a standardized format. This will ensure that there is no additional need to decipher the code and services to create business rule documents for coding them into the new future platform.

4. Ensure agility but rethink the use of proprietary cloud-vendor specific services
Build your case around business benefit, such as agility. Do not use the proprietary cloud-vendor services simply because they are readily available. Be selective; instead of specific proprietary tools, investigate industry standard tooling and frameworks that could be easily migrated to your future technology platform.

You can read more about Capgemini’s Cloud Advise services on our Cloud Strategy page.

Robert Jackson is head of cloud, digital and integration consulting at Capgemini. Read more Capgemini blogs here.

Return Home



    Chuck B:

    Being locked into a PaaS cloud service may not be that different structurally from being in a traditional SMB infrastructure managed services contract. Both have the vendor (MSP) manage, secure and control the infrastructure, including data, network access and apps. Both also have contracts which are similar as fas as ownership, control and performance. The real difference may be more of imagery – having the hardware and data local may give false comfort to many.

    In some ways, the data accessibility may actually be more defined and readily available in a cloud based service. PaaS and DaaS environments force more structure and technical architecture to implement which may also be more transferable when moving vendors or platforms. Traditional SMB infrastructure is usually made up of multiple vendors, platforms and multi-located data, making change not always less complex.

      Joe Panettieri:

      Hey Chuck: You raise some good points. But how many of those customers actually back up their cloud data to another service, and then know how to restore and/or activate the data on another PaaS provider? -jp

        Chuck B:

        Joe – I am assuming in my examples that the SMB customer actually does little – it is the current provider who holds the keys. Most PaaS or DaaS vendors (through their partners) offer customers archived data upon request. Many will accept provided portable storage hardware to their ops center and return all stored data. Customers would be advised to completely understand that policy, as well as the exact process to obtain their data at will, especially if changing providers.

        For most of the time, the customers provider (MSP) handles these issues, but in the event that provider or his cloud vendor change (voluntarily or not), knowing how to directly get their data can temper much of the fear. If the cloud or datacenter vendor suddenly goes belly up, then having other backup locations would be nice – in the end however it’s all about risk vs. cost. Some of the same issues apply to local infrastructure environments – many SMB customers would not know or be able to access their local data without the providers help (forced or not). In making the switch to a new provider, we have mostly had a good experience with the old provider, but there are cases where the clients data and access can be become entangled in the business issues which come with changing providers, which at times are the result of a dispute or deeper problems.

          Joe Panettieri:

          Hey Jack: Thanks for jumping back into the conversation with some more insights. You raise some great points about SMB customers not knowing how to access even their local data without a partner’s help. Well stated.


Leave a Reply

Your email address will not be published. Required fields are marked *