遗留系统含有成千上万个执行一大批业务功能的服务组件。比如说，假设贵企业运行的一个内部遗留系统中的一套组件向企业高管提供一份统计报告。为了赶在截至日之前获得这份每周提交的报告，该高管应该考虑将必要的组件迁移到新的软件即服务(SaaS)应用程序。
如果经济可行性研究表明这种迁移是明智的决策，他应该与其他高管以及由开发人员、系统工程师和业务分析人员组成的一个团队合作，将遗留系统细分成多个组件，然后着手开发那个应用程序。
1. 识别遗留系统资产
开发团队、高管和遗留系统负责人需要识别遗留系统的资产。这些资产包括如下：
- 说明文档，包括遗留系统的描述和流程图以及灾难恢复计划;
- 公司内部数据中心所在的设施;
- 与遗留系统有关的利益相关者;这包括当前用户(包括高管)、开发人员、系统管理员和业务分析人员;
- 遗留系统运行在上面的IT基础设施;以及
- 开发人员的技术技能，比如在平台即服务(PaaS)上开发SaaS应用程序，让开发人员能够在虚拟环境共享技能。
2. 发现必要的组件及依赖关系
开发人员应该扫描源代码，查找供以后提取的服务组件。源代码包括主程序及其与子例程之间的接口，子例程可能采用了不同于主程序语言的编程语言编写而成。
下一步是，开发人员识别主程序和子例程中的组件之间的依赖关系。服务组件的依赖关系可能与其他服务组件的依赖关系之间存在多对多的关系。
在识别组件的过程中，开发人员还应该设计一份流程图，帮助自己将服务组件彼此之间的依赖关系具象化。
3. 提取组件
开发人员应确定应该从遗留系统提取哪些组件。提取服务组件的简易性取决于下面五个因素：
- 源代码一开始编写得有多好;
- 源代码打补丁、再打补丁有多频繁，以修复软件错误;
- 遗留系统的说明文档是否定期更新;
- 开发人员的技术技能(比如，遗留系统的原始开发人员可能再也找不到);以及
- 服务组件的依赖关系具有的复杂性。
4: 接受或拒绝提取的组件
一旦开发人员厘清了依赖关系，他可以接受或拒绝依赖关系。接受依赖关系并不总是意味着按原状接受服务组件。开发人员可能需要重新设计服务组件的结构，以满足新的业务需求。结合依赖关系有望消除重复或类似的服务功能，因而减少了服务组件的数量。开发人员把所有被接受的服务组件放入到一个组件库，以便在构建SaaS应用程序时使用。
构建和安装SaaS应用程序
在PaaS上构建SaaS应用程序时，开发人员应该确定：
1. 用户、开发人员、系统管理员和业务分析人员期望从SaaS应用程序获得什么样的东西，然后选择SaaS应用程序运行所需的云部署类型：私有云、公有云还是混合云。
2. 根据用户、开发人员、系统开发人员和业务分析人员的预期要求构建应用程序时，使用哪些被接受的服务组件。
3. 什么方法将服务组件编排到松散耦合的SaaS应用程序最经济高效，并测试该应用程序的结果是否满足预期目标。松散耦合是指，应用程序在等待用户响应的同时，应用程序的其余部分可以继续运行。
安装应用程序后，开发人员应该监控SaaS应用程序的性能以及业务需求方面出现的任何变化，这些变化可能需要更新及重新设计应用程序的服务组件。
英文原文：Four steps to take before migrating legacy components to a SaaS app
