遗留应用对于绝大多数企业来说是一种必要的负担：承担着业务运转的重任，但是又阻碍了技术的进步。然而由于业务流程的改变或者与新系统集成的需求，替代或改进遗留应用的时机已经到来了。此时，就必须有一个应用转型的规划。
应用转型同时意味着挑战和机遇：重构应用所需的成本;新应用带来的生产率和可用性提升。在挑战和机遇之间要做出很好的权衡，以此判断重构应用是否可行。
幸运的是，有许多转型或迁移应用的途径可供企业选择。尽管各种方法之间存在差异，但是都可以用通用的IT实践经验来加以评判。这样就能有助于减少各选项存在的不确定性。
应用转型的方法
首先，IT总监可以用系统设计周期(system design lifecycle，SDLC)的方法来确定应用转型的可行性。最直接的效果是，如果一个IT系统、流程或应用的维护成本超出了替代成本，该方法就会提示进行升级或换代工作。
SDLC概念非常容易理解，但是运用难度却很大。在应用开发方面，SDLC能计算出必需的显性和隐性成本。显性成本以每小时人工、必要的系统以及其他支撑因素等来描述，而隐性成本则通常等同于生产力的提升。
关于应用的升级或替代还有另外的一些理由，比如法规监管的要求、工作环境转型(虚拟办公室、移动办公、合同工)、系统平台重构(服务器变更、数据库升级、桌面操作系统更新)等。
通过各种所获取的信息，IT经理很容易对应用转型的费用形成清晰的认识。然而，转型的过程是充满挑战的，最终的结果可能和预期大相径庭。为了减少结果的不确定性，对过程的正确理解以及对潜在风险的充分评估是非常重要的。
应用转型的第一步应该是决定应用的交付模式：运行在桌面系统上、外部托管、基于Web或是基于云?另一个要考虑的重要方面是应用是否要运行在公网、企业内网、或是托管在公有云/私有云/混合云上?以上方面的考量将决定应用转型的实施方式。
对于大部分企业来说，通常面临两种选择：内部承载一个Web应用，或者采用SaaS服务。直观上看起来SaaS模式似乎更为经济，因为这种方式消除了绝大部分与应用相关的成本：应用服务器、数据库服务器、存储系统等等。所有这些都转移到SaaS服务提供商一端。而且，其他方面的成本也相应地大为降低：备份、业务连续性以及灾难恢复方案。
转型过程中的SaaS问题
但是，如果没有采取一些必要的应对措施，向SaaS方案的迁移是无法成功的。首先要考虑的就是SaaS应用是否能满足业务的需求。很多企业都对业务应用进行了定制或调整，以此应对特殊的需求，包括特殊的库存处理、价格管控、路线定义以及客户历史等。简单地说就是，SaaS方案必须在不改变企业日常模式的前提下满足业务需求。如果变更不可避免，那么对一个通用的SaaS产品做调整将导致高昂的成本。
另外一个方面看，在某些情况下，迁移也可以是很容易的，比如对合同管理或者销售应用来说即是如此。这些应用通常无需定制化，迁移到SaaS方案的工作基本上就是迁移数据并培训用户而已。由于固有的库存控制流程、装配追踪等，一个复杂的数据仓库管理系统的迁移将会存在很大难度。简单地说，某些业务应用由于经过深度定制而不适合迁移到SaaS模式，如果这些应用非常重要的话，可以将其重整并保留在企业内部。
大多数情况下，从业务角度看，把一个较老的应用迁移到SaaS方案是明智的决定，因为这可以获得以前无法达到的生产率和弹性。在顶级SaaS服务提供商的站点上我们可以看到数以百计的成功案例。当然，失败和无法预知的问题总是存在的，我们可以从中汲取向SaaS方案迁移的宝贵经验。
需要重点关注的方面如下：
数据安全：数据的保护措施、访问控制问题、有哪些现成的工具可以提供对交易过程和数据的保护?
可靠性：以什么样的服务级别协议用户对应用和数据的便捷访问?
稳定性：以何种措施来防止数据损坏以及满足灾备的要求?
厂商风险：SaaS厂商是否值得信赖?针对业务中断等故障将提供什么应对措施?如何在厂商方面出现事故时确保应用和数据仍然可用?
性能：为了确保客户的生产率，SaaS产品提供的性能级别?产品的可扩展性如何?
计费：有什么样的价格控制来防止成本的指数型增长?是否存在有隐性的费用、支持和扩容成本、以及其他支出?
支持：技术支持的力度如何?是否包括了相关培训?是否对服务次数有详尽规定?相关文档是否具备?
定制化：SaaS产品是否能够定制?定制工作的责任方是谁?由客户完成，合同外包或者产品自服务?
通过对上述问题的应答，可以帮助可以对厂商的承诺和SaaS产品的可持续性有更深入的了解，从而打消其顾虑。当然，对上述方面的关注还能促进对应用转型本身更深入地研究 – 比如搞清楚谁真正拥有数据，以及相关法律法规的详情。
