增量迁移

增量迁移非常适合更新大型遗留项目--以较低的风险一次迁移一小部分，然后逐步完成其余部分。

大型遗留软件系统的增量迁移策略包括将系统分解为可以有选择地单独替换的较小组件。与一次完成所有更新或重写(例如，分阶段迁移到Tyescript、ES模块或较新版本的框架)相比，这种分阶段迁移降低了迁移的费用和风险。在某些情况下，一些遗留组件可能被封装在包装器中，以便它们可以按其原始形式使用，直到具有相当程度可靠性的新组件可以接管它们的功能。

从遗留体系结构分阶段迁移到目标体系结构可以带来很多好处。如果做得好，可以有一个在生产中运行的全功能混合遗留/目标版本的系统，同时获得对什么是有效的、什么是粗糙的关键洞察力。您可能希望确定迁移各阶段的优先顺序，同时牢记需要首先解决哪些最紧迫的目标。或者，首先处理关键任务阶段，以提升项目的知名度，并获得认可，以了解整个迁移过程。

由于系统在迁移的每个阶段后仍在运行，因此与一次性迁移和实施整个遗留项目相比，可以更快地体会到项目的好处。通常，小组件中的错误比大型系统中的错误更容易识别和修复。这降低了项目对用户的风险和不便。

大爆炸式的采用，即在约定的日期全面迁移，用新系统取代旧系统。这实际上是一个即时的转变。

并行采用，即旧系统和新系统并行运行一段时间，直到新系统的实现被认为完成。

试点转换，即在向更多用户推出实现之前，将非常部分的迁移推出给一组受信任的测试人员进行评估(例如，尝试针对特定组件或页面进行迁移)。

我倾向于支持增量迁移，原因有很多，包括从分阶段迁移阶段获得的经验教训可以用来指导项目的其余部分。通过这种方式，随着实现的进展，理想情况下会有更少的问题。