增量迁移适用于对大型历史遗留项目进行升级——也就是一次迁移一点，然后逐步迁移其余部分，以便降低风险
对于大型历史遗留软件系统进行增量迁移，需要事先对系统进行拆解，分割成可以有选择性独立进行替换的小型组件或者模块。相对于一次大型升级，或者整个系统重写，阶段性迁移可以降低成本以及风险（比如迁移到TypeScript，ES Modules或者一个框架的新版本）。有时，一些遗留组件可能被很好的封装起来，因此我们仍然可以使用他们的原始形态，直到具有更高可靠性的新组件替代他们。
通过分阶段地从遗留架构迁移到目标架构拥有很多益处。当处理得当时，生产环境中会运行着功能完整的遗留版本与目标版本混合的系统，此时我们可以在这个混合系统中有根据地判断哪些模块运行良好，哪些模块还有瑕疵。当然除了技术本身获得的益处以外，在工程排期上你也可以进行更加精细的考量。比如在不同的阶段如何安排迁移的优先级，或者在迁移之外的业务关键目标之中如何穿插迁移任务。另外对关键模块优先进行迁移，还可以为迁移本身赢得更多关注度并且得到更多支持，以便完成整个项目的迁移。
由于系统在每一阶段的迁移之后仍然可以工作，因此相对于整体迁移过程，增量式迁移的方式允许我们尽快评估迁移工作是否带来收益。通常来说，在一个小模块中产生的BUG要比在一个完整的大系统中更易被发现和定位。所以这也为系统的用户减少了风险和不便。
相对于增量迁移的概念，其他的迁移方式还包括：
- 直接转换。也就是在迁移之前设定目标时间点，一次性使用新系统替换老系统。也就是一次性的即时切换。
- 同步转换。也就是老系统和新系统同时在生产环境运行一段时间，直到新系统被认定完整实现老系统的所有功能。
- 试点转换。将某些特定功能的迁移优先开放给一部分可信赖的测试人员进行评估，通过之后再向更多用户开放（比如迁移某个特定功能模块或者页面）
出于多种原因我个人更倾向于采用增量迁移，包括在阶段性迁移过程中得到的经验教训，在项目的其余部分依然适用。以此方法论出发，在迁移以外的项目演进过程中，理想情况下也会减少问题的出现。
