I started my career in late 90s selling Microsoft Application Platform that included the servers and the developer tools. One of the most common customer objections that I used to handle was “vendor lock-in”. Every time I pitched MS SQL Server or Visual Basic, the immediate concern from the customers was getting locked into the Microsoft platform.

A decade later, “Vendor lock-in” still remains a hurdle that the technical sales rep has to go through. But the landscape has changed significantly. Now the vendor lock-in argument has shifted to the Cloud. I often hear lock-in in the context of Amazon Web Services. AWS competitors use the lock-in factor to create FUD among the customers with a hope to increase their sales prospects. But how much of this is a real concern? Should businesses be really worried about getting locked into one platform?

In my opinion, every technology decision involves some level of lock-in. My Hyundai car came with an in built MP3 player that makes it difficult for me to upgrade to a better audio player. For a long time, I lived with a HTC phone that had a proprietary headphone socket that prevented me from plugging in the powerful Bose headset into it. All of us tolerate certain level of lock-in across the devices and technologies that we use.

Vendor lock-in can be avoided to a large extent in the IT world. But, it is a huge trade off between performance and portability. Let’s consider the example of Microsoft SQL Server as the database. Like most of the enterprises databases, SQL Server comes with a lot of built-in optimizations that can be exploited for enhanced performance. To leverage these optimizations, one has to encapsulate the business logic in the stored procedures written in T-SQL, which is a native SQL variant used by MS SQL Server. This gives the database developers and the DBAs a chance to extract the best possible performance from SQL Server. So, what’s the trade off here? This makes it extremely hard to move the data tier to Oracle or DB2 at a later point.