简单地说就是，SaaS方案必须在不改变企业日常模式的前提下满足业务需求。如果变更不可避免，那么对一个通用的SaaS产品做调整将导致高昂的成本。
另外一个方面看，在某些情况下，迁移也可以是很容易的，比如对合同管理或者销售应用来说即是如此。这些应用通常无需定制化，迁移到SaaS方案的工作基本上就是迁移数据并培训用户而已。由于固有的库存控制流程、装配追踪等，一个复杂的数据仓库管理系统的迁移将会存在很大难度。简单地说，某些业务应用由于经过深度定制而不适合迁移到SaaS模式，如果这些应用非常重要的话，可以将其重整并保留在企业内部。
大多数情况下，从业务角度看，把一个较老的应用迁移到SaaS方案是明智的决定，因为这可以获得以前无法达到的生产率和弹性。在顶级SaaS服务提供商的站点上我们可以看到数以百计的成功案例。当然，失败和无法预知的问题总是存在的，我们可以从中汲取向SaaS方案迁移的宝贵经验。
需要重点关注的方面如下：
数据安全：数据的保护措施、访问控制问题、有哪些现成的工具可以提供对交易过程和数据的保护？
可靠性：以什么样的服务级别协议用户对应用和数据的便捷访问？
稳定性：以何种措施来防止数据损坏以及满足灾备的要求？
厂商风险：SaaS厂商是否值得信赖？针对业务中断等故障将提供什么应对措施？如何在厂商方面出现事故时确保应用和数据仍然可用？
性能：为了确保客户的生产率，SaaS产品提供的性能级别？产品的可扩展性如何？
计费：有什么样的价格控制来防止成本的指数型增长？是否存在有隐性的费用、支持和扩容成本、以及其他支出？
支持：技术支持的力度如何？是否包括了相关培训？是否对服务次数有详尽规定？相关文档是否具备？
定制化：SaaS产品是否能够定制？定制工作的责任方是谁？由客户完成，合同外包或者产品自服务？
通过对上述问题的应答，可以帮助可以对厂商的承诺和SaaS产品的可持续性有更深入的了解，从而打消其顾虑。当然，对上述方面的关注还能促进对应用转型本身更深入地研究比如搞清楚谁真正拥有数据，以及相关法律法规的详情。
|
