2009年2月，云服务商Coghead在一封写给客户的电子邮件中宣布该公司”由于受到经济挑战的影响”，将立即终止基于云的开发平台服务。随后，ERP巨头SAP收购了Coghead的知识产权，但停止继续支持这种开发平台，并让原有的Coghead客户在2009年4月30号之前取回他们的应用和数据。Hekademia Consulting公司的创建人兼负责人Shockey花了差不多4个多月才把他的CRM应用从Coghead移植到了Intuit的QuickBase数据库中。这件事足以警示人们，一家云服务商可以倒闭得有多快。

　　2008年8月，在线存储厂商 Linkup(以前叫MediaMax)公司的倒闭引发了网上一场谁该对丢失客户数据负责的激烈辩论。2009年3月，惠普关闭了其Upline存储服务。这类服务的终止让人们开始疑虑，是否能信任基于云的存储提供商，或任何基于云的服务提供商。

　　不管你打算是将数据，还是关键应用，或者你整个的应用开发工作都托付给云，你都可以采取以下4个步骤来确保云服务商的死亡不会毁掉你的企业。

　　第1步：审慎选择云服务商

　　第一种风险，也是最显而易见的风险，就是云服务商发生财务问题。在与云服务提供商签约前，你需要开展你在与任何厂商签约时所进行的”健康”检查，例如审查他们的收入、赢利能力、手头的现金和客户数量。

　　此外，一些分析师建议，将业务分散到多个云服务提供商以分摊风险。这也更容易迫使服务商降价，虽然由于需要管理多家厂商而导致你的总体成本节省不会那么高。

　　第2步：备份你的云数据

　　在云计算中，服务商将你的重要数据、服务器，甚至整个应用保持在你无法直接访问的位置上，通常是虚拟化或专有环境中。你惟一访问它们的途径是，通过厂商自己的下载工具或API。因此，你必须确保你备份了你的关键资产，选择备份在本地或备份到另一家云服务商，你必须确保可以在任何时候访问你的数据、虚拟机、应用等。

　　许多云服务商含蓄地承认，他们的服务可能会失败，因此他们支持客户很容易地定期备份数据。例如，Intuit公司的QuickBase Desktop服务，允许客户随时可将数据由QuickBase备份到客户本地的Accesss数据库中。

　　IBM在它的离线备份服务中提供SLA(服务水平协议)保证，其中规定了可供客户随时恢复数据的有效、可恢复的拷贝数量。Salesforce.com支持数据复制和每周数据输出服务，其Web服务API也使客户可以自行编写数据输出/输入程序。

　　此外，有些云服务提供商采用专有数据格式来保存客户数据，以便提高性能或节省硬盘空间。因此，一定要询问你的云服务提供商，是否以标准、通用的格式保存你的数据。否则，如果他们倒闭了，你即使取回数据，你的应用程序也有可能读不了。例如，电子邮件托管服务LiveOffice将数据保存为可供Exchange和其他许多邮件应用程序都能使用的.EML文件。

　　第3步：保持随时可供使用的存储空间

　　另一种特别的云计算是通过Web从Amazon Elastic Compute Cloud(EC2)服务这样的提供商那里购买”裸”服务器的使用权。

　　一旦某家云服务商倒闭的话，如果拥有可供随时使用的额外存储空间(不论这存储空间是你自己，还是来自另一家云提供商)，就可以减少应用的停机时间。

　　随着虚拟化越来越普及，把服务器由一家倒闭的云服务商转移到一个新平台上将变得比较容易，因为虚拟化的服务器是以能够在物理服务器之间移动的文件形式存在的。相比之下，重新恢复原先利用云厂商的API或开发平台所编写的应用程序可能更具挑战性。

　　第4步：为应用可移植性做准备

　　云中最困难的挑战是，云服务商倒闭时移植你的基于云的应用。把一个应用移植到一个新的云平台，可能需要访问应用的运行时间库、应用的业务逻辑、支持应用的数据库，以及你的用户已经输入到应用中的数据。云服务商使用的平台越专有，云服务商完成的应用管理越多，移植应用的难度就越大。

　　例如，Salesforce.com宣称它使客户摆脱了购买、管理和把CRM软件安装在他们自己硬件平台上的麻烦。一旦客户签约，他们可以通过任何安装了Web浏览器的计算机访问Salesforce.com网站，以及成百上千种在Apex开发平台上利用Salesforce的API所编写的应用程序。

　　但是，这种高度专有的模型意味着客户只能在Salesforce平台上运行Salesforce.com应用，包括他们利用那些应用程序在网页上所做的任何定制。

　　虽然有些工具(例如Force的Toolkit)让开发人员可以利用Force的API创建离线运行的Web应用。但是，虽然用户可以离线修改数据，但大多数应用在数据库、业务逻辑和工作流功能上必须定期与Salesforce网站保持同步。因此，你仍依赖Salesforce.com。

　　独立技术顾问Ben Bloch指出，由于Salesforce的Apex类似于Java，还是有”把应用移植到另一平台”的机会。重用一些逻辑、用户界面和其他元素也许是可能的，但开发人员仍必须重做在Salesforce平台上已经做过的很多工作。例如，要重新构建应用所需要的数据，而且还包括设计和部署数据，以及其他描述应用与数据关系的模型。

　　Salesforce的平台研究主管Peter Coffee认为，这种移植的工作量没有多大。他说，Apex开发语言在设计上与Java相似，因此翻译用Apex编写的组件和使用该公司的Visualforce 用户界面构建器来连接新目标平台，仅需占用项目成本的很小一部分。他表示，更多的工作量是在编写执行应用的新代码方面。

　　另一项挑战是恢复包含在应用内的业务逻辑和用户工作流。Hekademia Consulting公司的Shockey表示，他在最近的开发工作中大量使用QuickBase公式域来创建和更新流程数据。”这样，如果我们需要输出数据，我至少保证在我的数据模型内拥有这些流程信息。但是，由于实际的业务逻辑嵌入数据库的在域公式内，因此，如果我们再一次改变系统，比如放弃QuickBase，我仍可能失去这种逻辑”。他说。

　　当然，使用开放Web标准将能使 IT部门轻松地将应用从一个云平台转移到另一个平台，或自己的数据中心。有一种云平台证明了这是行之有效的。SugarCRM的产品营销主管Martin Schneider表示，由于SugarCRM的开源CRM应用基于PHP脚本语言和MySQL开源数据库等开放标准，应用迁移更加容易。用户只需为SugarCRM平台上的数据、以及定制或应用添加件拍摄快照，把它们保存在硬盘上，然后再把它们上载到选择的服务器中即可。

　　不管你选择什么平台，Shockey都建议，开发人员应当根据服务商承诺的当自己倒闭时提前发出通知的时间量，来制定移植自家应用的应变计划。在打算采用一种云开发平台前，Bloch建议，用户不仅要向云服务商询问它的业务模型的优势和财务状况，还要询问其发布API新版本的流程，以及会向开发人员提供哪些技术与支持。