对于“遗留应用”，众多企业都头痛不已，因为一些老旧的系统上运转的是企业核心业务，这些业务又与其他地方的系统互联互通，颇有牵一发而动全身的意味。也正是因为遗留系统平台无处不在，企业要如何处理呢？自然就是要对其进行升级！比如重新编写应用、重新托管应用，或者用服务对已有系统进行封装。一般会有两种做法比较常见，一是协调现成的一些解决方案；再者就是用面向服务架构（SOA）现代化遗留系统，后者更为普遍。

　　即便如此，需要让遗留系统支持SOA时，往往也会存在一些常见的错误或误解。有人认为移到SOA，遗留系统就会消失。这并不可能，遗留系统仍有要干的工作，它还有自己的用户，需要每天运营下去。同样，有些人认为简单地封装Web接口即可，这样不现实，因为迁移过程中有很多事情要做，远大于计划中预期的内容，比如用户界面功能非常紧密地与业务功能耦合到一起怎么办？可能也会出现这样的想法，既然要做服务，就全都封装成服务，一劳永逸。而实际上，企业要做的只是从业务角度来看，对于值得的服务暴露出来即可，绝非全部。

　　企业可以通过使用SOA区分出遗留系统最有用的部分，用以重用。减少成本，简化了系统管理，在响应需求上，遗留系统就可以更为敏捷。通过一些构建模块，企业可以在这些组件上继续构建，用不同的工作流来连接。因为使用模块化，所以也更易于插到其他模型中。同时，通过SOA，也可以有效实现企业内部的服务共享，甚至是外部的服务共享。

　　我们曾经介绍过加拿大政府的SOA大型机迁移项目，加拿大的英格伍德市拥有使用了23年之久的IBM大型机，这个大型机上运行着他们的应急服务计算机辅助调度系统。尽管3270终端应用可能会被今天的标准看做是斯巴达，但是这个应用在其使用期内毫无瑕疵地运转着。他们首先尝试迁移Cobol应用到.NET。预期六个月的项目最终花费了19个月，最终才运转起来。最初一切顺利，但是随后SQL server数据库更新，让所有警察、消防员和急救车信息系统脱机八小时。该城市最终选择回到老旧的3270终端应用，继续运转在大型机上，决定寻求新的对策。

　　由此可见，解决遗留系统问题SOA并不一定是万能钥匙，对于合适的项目进行采纳才是正道。另外，我们也提醒企业，在考虑项目或服务失败的风险的时候要加入迁移成本，因为这一点很可能会击垮高层对于成本节省的期望。