Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Everything Is “Lock-In”: Focus on Switching Costs

Everything Is “Lock-In”: Focus on Switching Costs

With the fast-pace of cloud changes (new services, providers entering and exiting), cloud lock-in remains a popular refrain. But what does it mean, and how can you ensure you're maximizing your cloud investment while keeping portability in mind?

This InfoQ article is part of the series "Cloud and Lock-in". You can subscribe to receive notifications via RSS.

Key takeaways

  • Financial lock-in is one of the hardest to deal with. But don't forget to consider other areas like a dependency on the ecosystem.
  • No product eliminates overall lock-in. At best, a product reduces lock-in for an architectural layer.
  • There are many reasons to embrace lock-in, including when that technology adds significant value and keeps you focused on the right activities.
  • It's time to pay the switching cost when your technology is keeping you from your objectives.
  • Microservices, open source, and API-ready technology can help you improve portability.

Coding in Java, buying SAP, deploying OpenStack, and using Amazon Web Services: each one introduces a type of lock-in. Lock-in–described by Wikipedia as something that “makes a customer dependent on a vendor for products and services”–is always a hot topic of discussion in the technology community. Pundits bemoan vendor lock-in and try to spot technologies that “kill” it. CIOs are disappointed after they realize that cloud services aren’t immune from lock-in risks. Wal-Mart created their own cloud management platform in order to try and free themselves from vendor lock-in. However, it makes no difference how hard you try- some form of lock-in is unavoidable. What matters most is understanding the layers of lock-in, and how to assess and reduce your switching costs.

In a pair of brilliant articles, Battery Venture’s Adrian Cockcroft took a look at the topic of lock-in, and used a relatable metaphor.

Like a marriage, enterprise-IT lock-in—or using only one vendor’s product for key functions, such as outsourced cloud computing—is a good thing if managed well for mutual benefit. But like a divorce, it gets ugly and expensive when things go wrong.

In this article, we’ll take a look at how you get locked-in in the first place, what switching costs you’ll encounter, see descriptions of the layers of lock-in, see when to embrace lock-in, outline reasons why you should pay the switching costs right now, and how to reduce your switching costs in the long term.

How you get locked-in, and identifying switching costs

Lock-in takes many forms, and the switching costs for each can be substantial.

Financial dimension

Commercial software is often accompanied by server or per-seat licensing, paid support agreements, and consultant-driven onboarding costs. Some of these charges are one-time, but many companies experience recurring charges. Hardware costs typically require a significant capital outlay, and depreciate in value in the years to come. Don’t forget about hosting your infrastructure; setting up your own data center or using a co-location / managed service provider is a major financial commitment.

All of these costs are a form of lock-in. Enterprises make a significant investment in technology, and want to get value in return. After spending tens of millions of dollars putting an ERP system in place, few companies are willing to drop it and move to a frisky competitor! CFOs want to squeeze out every ounce of benefit from an asset before paying to replace it. Even the cloud isn’t immune from financial lock-in. While we think of cloud as exclusively a pay-as-you-go model, many providers offer discounts if you make monthly or annual commitments. While this creates cost savings, it also creates a disincentive to leave.

A major financial commitment to a vendor means that switching providers is going to be painful. There may be early termination fees, or reimbursement of upfront discounts. Any wholesale change from one vendor to another typically means that large projects get spun up, and teams spend time on migration efforts instead of other value-added opportunities. There are downstream switching costs that impact your bottom line: new training for staff, changing hosting or support providers if the new technology is incompatible with their model, and purchasing new tools to administer the new asset.

Consumption model dimension

Companies build processes and systems around how they consume a given asset. It’s easy to (accidentally) build tight coupling to the APIs offered by a vendor, software system, or hardware device. Once you do that, it’s challenging to rip out that integrated system without violently impacting countless known (and unknown!) dependencies.

Many companies have centralized processes for planning and purchasing new technology. If you’re locked into this consumption model, then it’s difficult to embrace on-demand technology without going rogue and falling into “shadow IT.” Relatedly, many enterprises set up complex outsourcing and IT support relationships. In these environments, technology is purchased and consumed through pre-defined arrangements. Teams that want to use these managed technologies are locked into whatever process is dictated. Those teams might ache for the flexibility of self-service, but feel constrained by existing investments.

Business data/logic dimension

Most of your intellectual property gets embedded into the various systems used to run a business: algorithms, customer records, historical reports, and business strategies, all coded into database stored procedures, built into components written with whatever programming language is “approved”, stored in data warehouses, or stashed in a content management system. And don’t forget about all the metadata that spells out your permission model, firewall rules, or document change history.

Depending on where this data or business logic resides, it may be locked into proprietary applications, open source databases without a “standard” interface, or being managed by a third-party with no means for extracting it. All of this locks you into whatever system of record or engagement that’s storing this information.

Switching can be costly, and sometimes nearly impossible without starting from scratch. For instance, if an organization has written a significant amount of processing logic in the Apex language, there’s no opportunity to run that logic elsewhere. It has to be re-coded in another language supported in other environments. Companies that traditionally use relational databases cannot simply migrate that to a NoSQL data store without significant effort. Some commercial software packages and hardware devices don’t expose APIs for extracting data. In those cases, the data either has to be re-created, or somehow parsed from its native, binary representation. A company’s business logic and data is key to daily operations, and switching from one vendor to another is rarely simplistic.

Ecosystem dimension

Make no mistake, when a company buys a technology, they are also buying into the ecosystem that surrounds it. A vibrant technology ecosystem is often a healthy sign. However, a dependency on the ecosystem for training, talent, support, and tooling is an underrated form of lock-in. The ecosystem for Mulesoft isn’t going to overlap with the one for Microsoft BizTalk Server!

An ecosystem impacts your total cost of ownership, so switching technologies means it’s also important to assess the cost of the new ecosystem. Are consultants more expensive? Do useful tools exist or will it be necessary to invest in custom development? Is self-service training available, or is classroom-only the dominant option? Answers to these questions may determine how locked into the ecosystem you truly are.

These are just a handful of dimensions. For a complementary take, see the aforementioned blog posts by Adrian Cockcroft where he considers business, technology, and data lock-in classifications.

The layers of technology lock-in

The best outcome that one can achieve is eliminating lock-in at a particular technology layer. For example, OpenStack eliminates lock-in at the infrastructure layer. Customers can operate their infrastructure management platform across public or private clouds and change underlying providers without incurring a massive switching cost. However, they are now locked into OpenStack and its mode of working. The consumer moved their lock-in to a different layer of the stack with the hopes of achieving additional flexibility.

What are those technology layers where lock-in happens? Here’s a simplistic breakdown.

Infrastructure Layer

Physical assets—including things like data centers, servers, switches, and phones—are the foundation of all the services we create and consume. When a company chooses a hosting provider, for example, they are making a significant commitment that locks them into that provider’s capabilities and strategy. Infrastructure virtualization is a mechanism for reducing the lock-in to a given physical host, but that shifts the lock-in to the virtualization provider.

Cloud infrastructure is also part of this lock-in layer. After selecting a public cloud, companies migrate their data, set up per-cloud network topologies, and set up financial and staffing commitments.

Switching a data center facility, firewall device, or cloud IaaS provider is a major undertaking. Configuration metadata for a given piece of infrastructure is rarely portable to a competing solution. How do organizations reduce their coupling to the infrastructure layer and shift their level of lock-in? They often look to Platforms.

Platform Layer

“Platform” means a lot of things to a lot of people. Let’s work with an understanding that people build upon platforms to generate new services. Platforms frequently abstract away infrastructure components and provide a unified interface to consumers. Using this broad definition, things like SAP, OpenStack, Microsoft SQL Server, NGNIX, RabbitMQ, Kubernetes, and Amazon Lambda could all qualify as platforms.

Platform technologies are frequently portable across different infrastructure tiers. That’s the promise of things like OpenStack, which sells itself as a way to eliminate infrastructure lock-in by creating a management layer that’s infrastructure agnostic. Amazon Lambda is a “serverless” framework which completely shields the developer from any concept of storage, network, or compute. The idea is that platforms free the developer up from worrying about the underlying host, and provide more time to spend building services.

However, platform lock-in has its own complexities. While platform technologies are typically portable between infrastructure hosts, the platforms themselves are difficult to swap out for an alternative. For example, switching ERP systems or messaging engines often requires a ground-up effort. Business logic and configuration data from one system doesn’t seamlessly translate to another. To be sure, some platforms leverage “standard” APIs or use common primitives so that the switching cost is high, but not insurmountable.

Application Layer

At the application layer of a stack, there is custom, open source, and commercial software. This software often represents the system of engagement and system of record for a company. These applications may be built upon platforms, or, run directly on an infrastructure layer.

These applications have their own type of lock-in. For industry-specific applications, there may only be a limited set of providers. Customers are beholden to those providers because the alternative is to build a custom solution, and that’s not for everyone. The data within these applications may be stored in proprietary formats, or unavailable via API. This makes it difficult to plan a migration!

When to embrace lock-in

Is lock-in a bad thing? Not necessarily. There are a number of reasons why a company should recognize and embrace the lock-in they have.

  • There’s major business value with the status quo. First and foremost, if the current technology is meeting the business need without significant downside, then you’re getting good value. Yes, many AWS or Google cloud services are proprietary. Does that truly matter if your business is getting a competitive advantage because of those services? It’s important to (smartly) capitalize on your technology versus living in fear that you’ll become too dependent!
  • The technology can serve a need for many years. Some technologies will be foundational or don’t need to change very often. In those cases, there’s a low risk that lock-in will negatively impact your business. Nowadays, the useful shelf life of software seems to be decreasing, but a base technology like Ubuntu is a safe bet!
  • The ecosystem and vendor continues to add post-purchase value. A company should fear lock-in less when they see a vibrant community. You might have to commit to a mobile phone for years, but that doesn’t feel so risky when the OS is updated regularly and new applications continue to flood the marketplace.
  • There’s a significant investment in existing skills. What if your company perceives an incremental benefit if they switch from being a Java shop to a .NET one? Is it really worth it? Sometimes it’s going to make sense to stay with a given technology product or stack because there’s already significant in-house knowledge about it.
  • Strategic value by partnering with a particular vendor. Look at Microsoft. Are they the absolute best of breed with everything in their portfolio? Of course not. But there’s value to companies to use a majority of their offerings because of the financial and strategic benefits of working with a single provider.

When to pay switching costs

There are times when a company should cut the cord and prepare to switch technologies. Even if the switching costs are high, it can be worth it in both the long and short run.

  • Not enough available talent. If there is “an expert” at your company for an important technology, and that’s it, then it might be time to consider alternatives. Especially if we’re talking about a niche skill set. There’s simply too much risk to your business if you don’t believe you can predictably staff the development and support of key technologies.
  • Slow moving innovation by the vendor. Technology is a competitive advantage. If a company’s current investments aren’t keeping up with the industry leaders, it may actually be hurting the bottom line. This applies to all the layers of lock-in. If your firewall device provider is a laggard, your cloud provider isn’t keeping pace, or application platform can’t accommodate your mobile ambitions, it’s important to plan a move.
  • Unsustainable cost model. Based on your ambitions, using existing technologies to scale your business may not work. Can you really use that expensive enterprise service bus at all your edge data processing locations? Should you keep paying per sever core for a relational database when sufficient open source options exist? Randy Bias recently made some excellent points about lock-in and how open source helps companies take back the power from vendors. That concept applies here. As organizations look to spend their budgets wisely, it often makes sense to overinvest in people and spend less on commercial software.

Improving portability and reducing switching costs

How can you take full advantage of your technology investments while keeping options open for switching in the future? Other articles in this InfoQ series will touch on this topic, but here are a few suggestions:

  • Avoid long term vendor contracts. Financial lock-in is one of the hardest to overcome because you spend so much effort fighting the “sunk cost fallacy.” Companies that make major long term investments are wary to switch until the term is up.
  • Be wary of converged systems. It’s convenient to have these bundled systems that provide a unified interface and intentional coupling of internal components. However, it also makes it hard to swap out any one layer, and forces you to swap out the entire system when making a strategic shift.
  • Do not use any technologies that don’t expose an API. Whether hardware or software, try to avoid purchasing any technology that can’t be manipulated with an API. Whether a storage device or CRM system, it’s critical to be able to load/extract data through automation.
  • Work in a microservices model. The more shared, centrally owned assets you have, the harder it is to swap them out. Instead of having two key databases, maybe you should have three hundred—one for each service that needs one! Obviously this is one that requires great care and consideration, but by localizing control of the stack to each service that needs it, switching costs also become localized. We’re after smaller services, built for portability across hosts or runtimes.
  • Embrace abstractions. Tools like Ansible and Terraform help teams work across different technologies using a plug-in model, versus learning each system’s native API. If your company builds all its virtual servers using Terraform, switching providers becomes that much easier. Likewise, using a lightweight message bus between systems instead of tightly coupling their databases or APIs means that endpoints can change without necessarily changing all of the integrated systems.
  • Leverage open source software. Open source doesn’t eliminate lock-in. But as Bias says, it does shift the power structure and reduce your switching costs. Companies have more control when using OSS, but still stand to get locked into support contracts or release plans of the contributors.


Whether you’re married or buying Dell servers, there’s lock-in. And that’s ok. What’s critical is to not become so paralyzed by fears of lock-in that you miss out on the powerful native benefits of your technology investments. But it is important to understand what layers you’ve gotten locked into, and monitor the conditions that might warrant a change. Along the way, consider technological and business choices that can reduce your switching costs if the situation arises.

Agree? Disagree? Have other reasons to embrace lock-in or strategies to reduce switching costs? I’d love to hear your feedback in the comments below.

About the Author

Richard Seroter is a Senior Director of Product at Pivotal, a 9-time Microsoft MVP, trainer for Pluralsight, speaker, and author of multiple books on application integration strategies. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter



With the fast-pace of cloud changes (new services, providers entering and exiting), cloud lock-in remains a popular refrain. But what does it mean, and how can you ensure you're maximizing your cloud investment while keeping portability in mind?

This InfoQ article is part of the series "Cloud and Lock-in". You can subscribe to receive notifications via RSS.

Rate this Article