IT管理人员频繁地使用云服务，以此作为摆脱厂商锁定的一种方式。企业要结束对某个厂商的依赖源于其降低成本的需要，以商品驱动的方法获取基础设施服务将是实现上述目标的一种途径。企业的态度不难归咎于厂商昂贵的费用，因为厂商通常按照年度基准提出大额发票，并且几乎没有谈判的余地。然而厂商为何要谈判？企业用户已经依赖于厂商的单源技术。似乎通过创建一个竞争的环境使企业摆脱对单源技术的依赖是一种合理的方式。

在企业的IT生命周期中有两个里程碑是厂商必须要参与竞争的：实施前技术选择（厂商锁定建立于此），以及实施后购买。

诸如服务器硬件这样的组件在市场中是标准化的，然而像内容管理系统（CMS）这样的关键组件又是高度分化的，导致用户只能选择单一厂商的服务。在此过程中并不是所有的决定都依赖于厂商，但是这些厂商仍然起主导作用。操作系统和编程语言的选择并不依赖于特定厂商，但是他们会限制未来的选择。

开始于项目初始阶段的厂商锁定成为不了企业的痛点，直到你进入IT生命周期的采购阶段。企业很快发现他们的主要成本动因是非商品化部分，而那些单源技术厂商此刻占据了符合他们谈判利益的最佳形势。

在服务的后期，上述困难将会变得尤其突出，当巨大的生产收益记忆消退时，企业将只留下对成本的担忧。雪上加霜的是，商品化部分的成本随着时间推移往往伴随着摩尔定律不断降低，同时随着其他可成倍改进的技术，如网络技术和存储技术的发展，迫使这些商品化组件在企业当前的成本模型中占据更小的比重，这一切都使企业更加关注单源厂商的作用。

最直接的做法是向厂商要求结束依赖。但这样做并不能解决所有问题，不要忘记这条原则——相关并不意味着因果。很多企业似乎拥有相关的组织结构来进行针对系统组件的不完备的成本价值分析。供应商管理只能被迫专注于降低成本，但即便如此也不一定能够通过整体迁移以及单源组件扩展估算出相关价值。

在实施过程中可以选择这种组件以期最大化系统价值。但是在项目开始阶段适用的方案在整个项目生命周期中可能并不总是奏效，这就是分析结论一团糟的原因。组件的成本必须经由组件迁移的价值来担保。在此分析下会出现下述两种情况之一——如果组件还有价值，企业就应该支付订单；如果没有，就更换组件。但后者是昂贵的，并且需要大量的评估工作。为了证明能够以降低成本的努力开始一个大型项目，就需要增加新的价值，而这也增加了项目的复杂性和成本。

然而，原有的服务体系是否架构了允许企业在无需重构整个实施框架的基础上替换某一组件的机制，以便企业实现后期的成本降低。最后，厂商锁定是一个实施问题。多年来许多架构模式（如n层客户端/服务器模型，面向服务模型，松散耦合模型等）都允许企业替换组件，但是由于缺乏体系性的远见和严密性，这个领域取得的突破很有限。

这些问题把我们带回到云计算中。当然，云计算提供了一种能够更加高效地迁移一体化技术的方式，比如电子邮件技术。但这其中仍然有很大程度的厂商锁定问题，因为从一个软件即服务（SaaS）厂商迁移到另一个SaaS厂商是一项巨大的工程。另一方面，试图使用基础设施即服务（IaaS）来解除对厂商的依赖将会导致令人失望的投资回报率。

换句话说，把一堆乱七八糟的东西从你的数据中心内迁移到云计算中心并不能使你从厂商锁定中解脱出来，反而会使你陷入更多的厂商锁定问题中。从厂商的专政中解脱的唯一方法是专注于敏捷架构，即在项目生命周期中支持技术的不断更新。