转移流

映射数据源

如果我们要提取和重新实现关键聚合器，我们首先需要了解它是如何与遗留系统其余部分链接的。这意味着分析和理解用于聚合的最终数据来源。在这里，重要的是要记住，我们需要找到最终的上游系统。例如，虽然我们可能将大型机视为销售信息的真实来源，但数据本身可能起源于店内收银系统。

创建一个图表，显示聚合器以及上游和下游依赖关系至关重要。系统上下文图或类似的图表在这里可以很好地发挥作用；我们必须确保我们完全了解哪些数据从哪些系统流出以及流出的频率。遗留解决方案通常是数据瓶颈：来自（较新）源系统的其他有用数据通常会被丢弃，因为在遗留系统中捕获或表示它们太困难了。鉴于此，我们还需要捕获哪些上游源数据被丢弃以及在哪里被丢弃。

用户需求

显然，我们需要了解我们计划“转移”的功能如何被最终用户使用。对于 关键聚合器，我们通常对每个报告或指标都有很多用户。这是一个典型的例子，说明 功能一致性 会导致重建一组“臃肿”的报告，而这些报告实际上并不满足当前用户的需求。一组简化的较小报告和仪表板可能是一个更好的解决方案。

在初始实现过程中，可能需要并行运行以确保关键数字匹配，从而使企业能够确信一切按预期工作。

捕获输出的生成方式

理想情况下，我们希望捕获当前输出的生成方式。一种技术是使用时序图来记录遗留系统中数据接收和处理的顺序，甚至只是流程图。但是，试图完全捕获现有实现通常会产生边际收益递减，发现关键知识丢失的情况并不罕见。在某些情况下，遗留代码可能是唯一关于事物工作方式的“文档”，理解它可能非常困难或昂贵。

一位作者与一位客户合作，该客户使用遗留系统的导出文件以及高度复杂的电子表格来执行关键的财务计算。目前组织中没有人知道这是如何运作的，幸运的是，我们联系了一位最近退休的员工。不幸的是，当我们与他们交谈时，他们发现自己十年前从之前的员工那里继承了电子表格，而这位员工不幸在几年前去世了。对遗留报告和（两次“版本迁移”）Excel 电子表格进行逆向工程比从头开始定义计算应该做什么的工作量更大。

虽然我们可能不会在替换端点中构建功能一致性，但我们仍然需要关键输出与遗留系统“一致”。使用我们的聚合示例，我们现在可能能够生成商店的每小时销售报告，但业务领导者仍然需要月度总计，并且这些总计需要与任何现有数字相关联。我们需要与最终用户合作，为给定的测试输入创建预期的输出工作示例，这对于在以后发现哪个系统（旧的或新的）“正确”至关重要。

交付和测试

我们发现这种模式非常适合迭代方法，在这种方法中，我们以切片的方式构建新的功能。对于关键聚合器，这意味着依次交付每个报告，将它们全部交付到类似生产的环境中。然后，我们可以使用 并行运行 来监控已交付的报告，因为我们正在构建其余报告，此外还有测试用户提供早期反馈。

我们的经验是，许多遗留报告包含未发现的问题和错误。这意味着新的输出很少（如果有的话）与现有的输出匹配。如果我们不完全了解遗留实现，通常很难理解不匹配的原因。一种缓解措施是在整个实现阶段使用自动化测试来注入已知数据并验证输出。理想情况下，我们应该对新的和遗留实现都这样做，以便我们可以比较同一组已知输入的输出。然而，在实践中，由于遗留测试环境的可用性和注入数据的复杂性，我们通常只对新系统这样做，这是我们推荐的最低限度。

在遗留聚合中发现“非系统”解决方法很常见，显然，在迁移工作期间尝试跟踪这些解决方法很重要。最常见的例子是领导团队所需的报告实际上无法从遗留实现中获得，因此有人手动操作报告以创建他们看到的实际输出 - 这通常需要几天时间。由于没有人愿意告诉领导层报告实际上不起作用，因此他们通常不知道事情的真实运作方式。

上线

一旦我们对新聚合器中的功能感到满意，我们就可以将用户转移到新的解决方案，这可以分阶段进行。这可能意味着为关键用户群实施报告，进行一段时间的并行运行，最后只使用新报告切换到它们。

监控和警报

拥有正确的自动化监控和警报对于转移流至关重要，尤其是在依赖关系仍然存在于遗留系统中的情况下。您需要监控更新是否按预期接收，是否在已知的良好范围内，以及最终结果是否在容差范围内。手动执行此检查很快就会变得工作量很大，并且会成为错误的来源，并延迟未来的工作。一般来说，我们建议修复在上游系统中发现的任何数据问题，因为我们希望避免将过去的解决方法重新引入我们的新解决方案。作为额外的安全措施，我们可以将并行运行保留一段时间，并选择性地使用协调工具，如果旧的和新的实现开始出现太大差异，则生成警报。