直接转换策略
旧系统和新系统之间直接进行转换，对旧系统直接下线，新系统直接上线。
这种转换策略带来的问题
有新系统上线后用户会发现原来的使用习惯和新系统之间存在着很大的差距。
解决办法有两种：
1.设计引导过程，将新系统和原系统不同的地方用引导一步步教给用户。
可以使用introjs（AGPL，商用收费）Bootstrap Tour（MIT 免费的！） introjs使用起来更简单一些 只需要简单几步
引入js
https://cdnjs.cloudflare.com/ajax/libs/intro.js/4.1.0/intro.min.js
https://cdnjs.cloudflare.com/ajax/libs/intro.js/4.1.0/introjs-rtl.min.css
向需要添加引导步骤的页面元素添加属性
data-title="Welcome!" data-intro="Hello World!
调用js命令
introJs().start();
就是有点贵，商业授权要600块。。。
2.提供完全模拟旧系统的UI （比如博客园上线新版之后保留了旧版UI的入口）
需要重新培养用户的习惯，需要客服大量的指导和响应。
旧数据和新数据之间的差别有可能太大，需要进行数据的迁移和处理
并行转换策略
新系统上线之后，旧系统依然使用，两者并存一段时间，给用户提供一个备选，好处是用户依然可以使用自己熟悉的系统进行操作，坏处是开发和运维需要同时维护两套系统，对于开发和运维是不小的挑战，同时因为占用了开发的精力，对于新需求的开发也会有一定的影响。
这种转换我认为有些类似AB测试，挑选一部分人使用新系统，并进行新系统的使用体验收集。另外一部分继续使用原有的旧系统。
为了兼容旧系统，两边的数据一般都需要保持一致，往往会导致技术带着较重的包袱，最后可能导致新系统和旧系统只是升级了一些依赖，引入了一些新技术，内里的逻辑基本都是复制粘贴过来的。
分段转换策略
新系统转换时并不是将旧系统完全替换掉，而是一块一块进行替换，
具体的转换，我们可以考虑三种策略：
按功能：
可以确定新系统中主要的业务功能中有哪些是迫切需要转换的，按照紧迫程度进行功能替换，也可以按照影响程度，从影响程度小的功能入手，将旧系统的功能使用新系统的功能进行替换
按部门：
选择部门开始进行替换，等到在该部门获得成功后再逐步扩大到其他部门
按机器设备：
如果旧系统和新系统的接口没有区别的话，可以使用nginx代理的方式，一台台服务器进行替换，先测试测试是否新系统能够承受生产环境的流量和压力，这种一般都是在使用新技术的时候使用，我还记得当时博客园在使用.net core逐步替换的时候，天天一到高流量的时候就出问题，螃蟹不好吃啊
