如果没有采取一些必要的应对措施，向SaaS方案的迁移是无法成功的。首先要考虑的就是SaaS应用是否能满足业务的需求。很多企业都对业务应用进行了定制或调整，以此应对特殊的需求，包括特殊的库存处理、价格管控、路线定义以及客户历史等。简单地说就是，SaaS方案必须在不改变企业日常模式的前提下满足业务需求。如果变更不可避免，那么对一个通用的SaaS产品做调整将导致高昂的成本。

　　另外一个方面看，在某些情况下，迁移也可以是很容易的，比如对合同管理或者销售应用来说即是如此。这些应用通常无需定制化，迁移到SaaS方案的工作基本上就是迁移数据并培训用户而已。由于固有的库存控制流程、装配追踪等，一个复杂的数据仓库管理系统的迁移将会存在很大难度。简单地说，某些业务应用由于经过深度定制而不适合迁移到SaaS模式，如果这些应用非常重要的话，可以将其重整并保留在企业内部。

　　大多数情况下，从业务角度看，把一个较老的应用迁移到SaaS方案是明智的决定，因为这可以获得以前无法达到的生产率和弹性。在顶级SaaS服务提供商的站点上我们可以看到数以百计的成功案例。当然，失败和无法预知的问题总是存在的，我们可以从中汲取向SaaS方案迁移的宝贵经验。

　　需要重点关注的方面如下：

　　数据安全：数据的保护措施、访问控制问题、有哪些现成的工具可以提供对交易过程和数据的保护？

　　可靠性：以什么样的服务级别协议用户对应用和数据的便捷访问？

　　稳定性：以何种措施来防止数据损坏以及满足灾备的要求？

　　厂商风险：SaaS厂商是否值得信赖？针对业务中断等故障将提供什么应对措施？如何在厂商方面出现事故时确保应用和数据仍然可用？

　　性能：为了确保客户的生产率，SaaS产品提供的性能级别？产品的可扩展性如何？

　　计费：有什么样的价格控制来防止成本的指数型增长？是否存在有隐性的费用、支持和扩容成本、以及其他支出？

　　支持：技术支持的力度如何？是否包括了相关培训？是否对服务次数有详尽规定？相关文档是否具备？

　　定制化：SaaS产品是否能够定制？定制工作的责任方是谁？由客户完成，合同外包或者产品自服务？

　　通过对上述问题的应答，可以帮助可以对厂商的承诺和SaaS产品的可持续性有更深入的了解，从而打消其顾虑。当然，对上述方面的关注还能促进对应用转型本身更深入地研究 – 比如搞清楚谁真正拥有数据，以及相关法律法规的详情。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。