在公司经常碰到的情况是新系统开始好了，但是旧系统一直还被人依赖，让使用者迁移，一般都不会怎么顺利，记得我当年在某一个大厂时，新旧两套系统同时跑了快一年，旧系统最大的问题是需要维护，同时维护两套系统的成本很高。
记录一下 Google 是怎么处理这个问题的，有一些主张还是比较有意思。
什么是过时的系统
已经有一个新的系统提供相同的功能，新系统可能更有效地使用资源，具有更好的安全属性，以更可持续的方式构建。 拥有两个系统来完成同一件事似乎不是什么大问题，但随着时间的推移，维护它们的成本会大幅增加， 用户可能需要使用新系统，但仍然依赖于使用过时的系统。
为什么过时系统很难下线
对于迁移方来说没有任何收益
比如我要求我的依赖方从旧系统迁移到新系统，但是对于我的依赖方来说，只会增加他的成本，可能不会对他有什么收益，他可能还要重新适配新的系统，要测试，会存在工作量，有可能还会有未知的风险。
恋旧
有时因为这个系统是某个人开发的，他对这个系统有一定的情节，不想被替换。
利益冲突
可能系统跨部门，让别的部门的人增加成本去迁移到新系统，会增加部门的成本，如果不迁移，成本可能看不到。
代码是一种负债，不是一种资产
Google 认为代码是一种负债，而不是一种资产，这个是可以理解的，当你的代码越多，维护成本就越高，如果不把这些过时的系统下线，会增加维护成本，代码越简单，同时保持相同数量的功能越好
代码本身不会带来价值：它提供的功能带来了价值，如果该功能满足用户需求，那么它就是一种资产：实现此功能的代码只是实现该目的的一种手段。如果我们可以从一行可维护、可理解的代码中获得与 10,000 行错综复杂的代码相同的功能，我们会更喜欢前者，代码本身是有成本的——代码越简单，同时保持相同数量的功能越好。
与其关注我们可以生产多少代码，或者我们的代码库有多大，我们应该关注每单位代码可以提供多少功能，并尝试最大化该指标，最简单的方法之一就是不要编写更多代码并希望获得更多功能，删除不再需要的多余代码和系统。
向死而生的设计
就是在设计的时候，要考虑如果这个系统要关闭时，迁移成本有多大，容易迁移吗？说是核电站在设计的时候，是要考虑这个核电站不运转了，我怎么样安全地把它关闭，Google 在设计的时候也会考虑这一点，我认为这一点特别不错，很少有人会在设计时，考核这个事情。
- 我的使用者从我的产品迁移到潜在替代品的难易程度如何？
- 如何逐步升级？
过期系统下线的方式
- 建议
- 强制
这两种方式在 Java 的编译时经常看到。
工具的使用
Google 会用一些工具去分析依赖关系。
总结
- 软件系统具有持续的维护成本，应与删除它们的成本进行权衡。
- 下线通常比开始构建它们更困难，因为现有用户经常使用超出其原始设计的系统。
- 如果将停机成本包括在内，改进系统通常比更换新系统便宜。
- 很难真实地评估决定是否弃用所涉及的成本。