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