主流技术企业构建和思考IT解决方案的方式正在发生转变。关注一下厂商的最新发布，就会发现其重点都是“集成”以及“互操作性”。管理服务提供商（MSP）和系统集成商本是各占山头，当他们决定成为伙伴而不是构建自己的云服务的时候，就会变身成一个巨大的云提供商。从技术观点或者是合同的角度来看，这里可能就会导致他们变成云锁定的受害者。但是如果说团队可以在咨询时候询问得当，作出正确的开发决定的话，云锁定的威胁可能就会减缓。

如果我们不能花费足够的经历得出怎么会失去关联，怎样来迁移应用和数据，数据构成的形式以及谁拥有这些数据，这些数据存储在哪里，云锁定肯定就会不请自来。但是很多时候，我们在本地操作这些在进入云环境的时候并没有考虑的足够多，也没有咨询得够仔细。云集成商应该主要关注两类云锁定：隐藏在契约或者服务水平协议（SLA）中锁定；再者技术问题可能对于集成商来说很难，尤其是把应用或者数据从一个云提供商迁移到期望中的另一个云提供商上。我们要明确的是云锁定在我们熟悉环境的情况下说不定也不错，但是这完全取决于场景。

下面我们搜集了一些资料，为云集成商和MSP最小化他们在结合的时候将要面临的困境：

1.评估云提供商财务是否正常。尽管这样做似乎挺正常的，但是不要忽视检查参考资料的需求，并确保所选择的云服务提供商有资本可以继续运营。提供商要是陷入麻烦，他们可能会变卖控制权和资产。

2.确保提供商有完整的数据备份和灾难恢复计划。这一点解决了云锁定的一个不同类型，这种情况下，合作伙伴将用户数据或者自己的数据放到云端，可能由于云提供商忽视保护自己的基础设施导致他们再也看不到数据了。这个和第一点有一定的相关性，但是去年亚马逊Web服务宕机的案例足够让我们警醒。在一些案例中，有些数据的丢失是永久性的。云计算毕竟不是完全成熟的技术。

3.理解数据迁移计划。如果MSP或者云集成商决定让其基础设施随处可需，那么使用数据将会变得多么容易。在很多例子中，可真不是这样。云锁定就涉及到这方面的内容。云会导致锁定，因为数据混合、存储共享，存储和备份数据的方式不同。有时候，迁移数据的流程可能要花费的资金比MSP或者云集成商去另外一个云提供商那里重新开始做一遍都要多。这也正是我们为什么要理解云可移植性和迁移实施的重要性了，可能我们都需要在合同一开始就运行一个测试来看看能不能轻松导出这些内容。

4.研究合同要点。集成商和MSP对云要谨慎，必须理解如果业务需求合理变化时候，是否会在法律上破坏这份合同。比如说，你的客户不在需要服务器或者一些功能了，是否可以以极少的罚金关闭呢？服务器上所使用的任何软件的许可证归谁所有？这些问题都是在遭遇云锁定之前值得反复估量的。

5.避免直接开发云服务提供商专有的应用程序接口（API）。简单地将应用迁移到云托管的服务器上并不是个问题，但是将应用转移到云托管的开发平台可能就会造成问题了（像Azure、Google App Engine）。尽管直接开发具体的API可以获得性能优势，但是集成商和MSP应该考虑下假如他们要一个本地的解决方案的话，这样的迁移如何实现。

上面这些问题是我们对于已有资料的搜索总结，可能在实际情况中，集成商和MSP会面临更多的挑战。但是至少从上面总结的内容上，可以避免一些不必要的麻烦，少走一些弯路。