遗留系统的迁移是一个相当复杂的工作，以至于重写的成本甚至比迁移的成本更高。但是从技术维度来看，步骤无非就是：
设定迁移的目标
制定迁移的计划
迁移计划的验证（PoC）
实施应用程序的迁移
校验迁移结果
对，就是这么简单。
我们通过把数字化时代的遗留资产划分了这几种类型：
遗留代码。所有没有测试的代码。
遗留基础设施。所有不安全、没有弹性、不可靠的基础设施。
遗留系统。所有不可观察、没有支持的自制系统或者商业化系统（COTS）
遗留架构。所有限制交付价值的架构。
旧式流程。所有不可度量的流程（缺少 KPI、SLO）
旧式组织。所有不敏捷且不统一的组织
旧式思维。相信上述内容无法克服或无法改变
替换这些系统的原因，也无非就是：
降低成本：更快的概念兑现
改善客户体验
上市
可伸缩、可扩展系统
技术变革根上业务变革的速度
架构量子则是具有高功能内聚并可以独立部署的组件，它包括了支持系统正常工作的所有结构性元素。—— 《演进式架构》
在单体架构中，量子就是整个应用程序，每个部分都高度耦合，因此开发人员必须对其进行整体部署。
架构架构量子可演进性没有架构的单体
单体（大泥球）
低
分层单体
单体（分层应用）
低
模块化、结构化单体
单体（如模块化的 COTS）
中
微内核
内核 + 插件
中
事件驱动 - 中介
总线、消费者、订阅者
中
事件驱动 - 代理
队列、消费者、订阅者
高
基于服务的架构
微服务
高
对应的替换过程模式有：
改善现有。现有系统已经过现代化改造，可以通过改进设计来提供更好的结果。通常，核心技术堆栈保持不变，或者可能会引入一些次要的补充。
缓慢替换。IT 系统的组件/功能块已被新技术取代，并作为单独的应用程序移至生产环境，而系统的其余部分仍旧采用旧技术。随着时间的流逝，剩余的组件/功能块将被单独的应用程序取代，然后逐步重建整个系统。
普通替换。整个系统使用新技术进行了重建，旧系统已停用。它使用标准平台从头开始构建，或者使用第三方程序包作为基础层构建。
当然了，每种模式的要求也有所不同：
改善现有缓慢替换完全替换现有化技术栈
低
高
最高
系统修改
应用级别
应用级别 / 局部变化
企业级
风险等级
低
中
低 - 高
资金需求
中
中
低 - 高
持续时间
数月
数月到 1 年
数月到数年
长期收益
低
高
最高
人生度
最高
高
低
人力成本
低
中
高
在我们决定好了迁移的目标和模式之后，只需要适合的方式即可：
保留（Retain），什么都不做。
清退（Retire），摆脱原有束缚。
重新采购（Repurchase），转移至不同的产品。
重新托管（Rehost），即直接迁移。
平台更新（Replatform），『修补加迁移』。
架构重构（Re-Architect），更改应用程序的架构和开发方式，往往通过使用云原生功能来完成的。
这里，我们主要考虑讨论的是：重新托管、平台更新、架构重构，因为只有这三项是技术活动。
对于遗留系统的迁移，想必你也相当的有经验了，比如这些常见的实践：
使用版本管理。
小步前进。
使用测试作为防护网。
频繁提交。
……
而在这其中除了架构的设计，最复杂的一部分莫过于：防护网的设计。
适用的场景：遗留代码、遗留系统、 遗留架构。
对应的实施方式：
代码级重构。
组件级重构。
API 级重构。
系统级迁移。
常见的防护措施有：
单元测试。针对于包级、组件、函数级的代码重构场景。
容器内测试。针对于模块化的 OSGI 架构应用。
API 测试。采用纺锥型测试策略进行系统迁移。
端对到端测试。较少采用，成本较高，效果较差。
UI 测试。
性能测试。针对于云迁移下的对比。
常见的工具有：xUnit、 REST Assured、Karate、Cucumber 等。
适用场景：遗留基础设施、遗留系统、遗留架构。
基础设施迁移：
数据库迁移。
构建工具迁移。
常见的实施方式有：
数据比对测试。通过测试对比迁移前后的数据变化，来判定迁移是否成功。
数据库比对测试。同上，只是维度变成了数据库。
Schema 比对。确保数据模型或架构结构在源系统和目标系统之间匹配。
Row 计数比对。确保计数是针对源和目标之间的表是否匹配。
数据汇总测试。对源和目标之间的大量表执行汇总检查。
制品比对测试。针对于构建工具迁移，对比构建产物，看是否发生变化。
checksum 比对。
class 比对。
常见的工具有：DBDiff、DbUnit 等。
适用场景：遗留系统绞杀。
常见的实施方式有：
过渡 API。适用于遗留系统迁移的过渡模式，在迁移完成好，可以删除。
防腐层。即建立与遗留、腐败的代码的层级，以隔离系统变化。
BFF。适用于多种客户端模式
结论
没有银弹，迁移才是最有意思的技术挑战。
