集成策略
遗留系统的技术含量较高，但其业务价值较低，这种系统一般都是为了完成某些业务人员的某些要求而实现的，因为和主业务关联不大，所以主系统的历史技术包袱不用背着，因此一般都使用了较新的技术。
这种系统在各自的局部领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛，同时用户需要记录多个系统的用户名和密码，给用户造成了不必要的负担。
对这种遗留系统的演化策略为集成。集成的话往往会带来用户的统一登录问题，对于原有用户的统一保存，系统内部改造会提出很高的要求。
对于统一登录可以使用
Spring Cloud OAuth
cas
改造策略
遗留系统具有较高的业务价值，基本上能够满足企业业务运作和决策支持的需要，这种一般都是本企业的新成立的部门的业务系统。
这种系统可能建成的时间还很短，技术包袱还不那么重，还可以抢救一下，演化策略为改造。
改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变;数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。关键是在于改造过程中要进行小步慢走，一次改造一小块并进行充分测试防止引入新的bug。
淘汰策略
技术含量较低，业务价值也低，没有任何抢救的价值！！！这种往往是产品线整体淘汰，或者KPI项目，对遗留系统的完全淘汰是企业资源的根本浪费,也就只能帮助产品开发积累经验，可以帮助新系统的设计，降低新系统开发的风险。
继承策略
遗留系统建成时间已经很长因此技术含量较低，但是能够勉强通过小修小补满足企业运作的功能或性能要求，具有较高的商业价值，目前企业的业务尚紧密依赖该系统。
对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型，因此只能改改使用的技术，比如把jsp改成vue的前端。
这种对原有系统的继承需要一位对原有系统非常了解的技术人员进行总体把握，并每周进行代码梳理讨论，因为企业业务中往往存在着很多为了某些特殊需求而做的特殊逻辑，一不小心就会中招。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。
