如果你经历过，一定知道：更换服务供应商谈何容易!如果你没经历过，试想下单是改变电话公司、互联网供应商或者手机服务商就已经麻烦重重了，结束与服务供应商之间的协作关系总是比其它决策行为更为艰难繁杂——当然，这也是商业活动中不可避免的惯例。
让我们正视现实吧。服务供应商们通常不愿为用户提供无缝切换机制，毕竟把用户拱手送给竞争对头实在不是那么令人痛快。但客户则很有可能并没有足够地意识到，服务供应商同样有能力且确实会设下种种障碍留住消费者——无论这个供应商有多粗心大意。也就是说，他们很容易就能通过设计刻意提高交接工作的难度，借以提高客户对自己的依赖程度(也就是所谓用户‘粘性’)。
这种情况在云计算领域当然同样存在：再次强调，即使是表面上并不工于算计的云服务供应商有时也会故意增加交接流程的难度，而最常见的手段之一就是安全控制。
安全控制的目的在于限制使用者对数据的访问方式，而这往往成为服务供应商最有力的挡箭牌。“安全要求”这一借口堪称屡试不爽之法宝，有了这面大旗、供应商就可以堂而皇之地拒绝(有时是不能、有时是不愿)为用户提供关键性数据模块，并最终达成阻挠平稳交接的目的。
有鉴于此，我们需要通过一系列问题来弄清当前安全控制架构的具体情况，这样才能避免陷入云计算供应商们的“留客”陷阱。大家不妨通过以下几个问题及对应策略帮助自己摆脱已购服务及相关数据的纠缠，从而按照预定计划调整业务流程。
应对云供应商“留客”陷阱提问一：数据究竟归谁所有?
头一个重要议题，同时也是不容含糊的内容——我们发送至服务供应商处的数据到底该归谁所有?除非大家在服务合约上明确规定了生成数据的所有权划分，否则这个问题的答案恐怕比我们的想象更加复杂。信誉显著的服务供应商会将数据的所有权毫不犹豫划归用户，但事实上并不是每家供应商都如此注重信誉。请大家务必在合约中注明，由业务流程生成的所有数据在协作周期内都归用户方所有，这非常重要。
应对云供应商“留客”陷阱提问二：服务供应商如何将数据返还给用户?
假如我们已经明确了自己对于数据的所有权，接下来的问题就是：服务供应商将以怎样的形式向用户返还数据?返还数据又会采用何种格式?我们发现当合作关系结束之后，供应商往往会以相当麻烦的格式将数据提交给用户，导致大家无法轻易加以使用。举例来说，专门寻找一种用户不具备的工具制作出备份磁带。为了避免这一难题，我们需要在合约中明确数据应以哪类格式进行返还，而且***是那种无论何时都能轻松使用的格式。另外，通过测试确保供应商有能力满足约定，这样才能避免在实际过渡时发生意外事故。
应对云供应商“留客”陷阱提问三：用户能真正访问数据吗?
请注意，包括加密在内的多种数据安全控制机制都能防止用户对数据进行逻辑访问，即使数据的归属权并无争议。举例来说，如果数据本身经过加密，我们是否有权访问加密密钥?再次强调，请务必通过测试确保自己对数据拥有访问能力。特别强调：请注意那些可能在特定元素中采取列级加密(column-level encryption)的数据库结构。因为***，这一特性可能不会在信息输出时被马上察觉;第二，一旦加密机制被部署至应用程序层，我们将只能通过供应商手中的密钥方可访问。大家不妨考虑自己保留一份密钥(当然，前提是安全得到保障)，这样当供应商不再提供服务时，我们就不必把宝贵数据的命运交由态度消极的前合作方加以摆布。
应对云供应商“留客”陷阱提问四：资源访问如何处理?
对于基础设施即服务(简称IaaS)领域，当数据成为虚拟镜像的一部分时，大家需要确保自己同时拥有对应用程序与底层操作系统进行管理员级访问的能力。一旦失去管理密码，我们不仅很难访问系统、甚至对物理硬件也会失去控制。因此如果供应商将数据以虚拟机镜像形式返还，请保证自己能够真正访问服务的操作系统及应用程序层。
应对云供应商“留客”陷阱提问五：能否访问用户数据?
请记住：除了原始数据之外，我们可能还需要其它辅助信息才能真正实现服务的无缝转移。举例来说，如果大家的服务供应商打造了一套用于容纳用户信息的数据存储体系(包括用户ID、角色、权限以及身份验证信息等)，我们自己也需要建立同样的体系。确保自己有能力将包括用户信息在内的所有备份数据重新导入服务流程，因为这部分数据很可能被单独保存在应用程序数据之外。
毫无疑问，没有哪家服务供应商愿意主动提供简单便捷的平台交接方案。但为了避免落入供应商那些防不胜防的留客陷阱(至少是给交接流程设下的各种障碍)，我们必须通过测试总结出一套清晰顺畅的交接机制，从而在挑选合作伙伴时占据主动、真正以业务需求出发走上适合自身的发展道路。
