遗留软件现代化：继续维护、改造还是替换？

年代久远本身不是替换软件的理由

使用十二年的应用可能仍可靠处理订单，而仅使用两年的应用也可能已经难以修改。只有当变更阻碍新服务、平台失去支持，或关键流程依赖某一个人的知识时，现代化改造才有明确意义。成熟软件也积累了运行经验：特殊价格、更正分录和少见例外，可能只存在于代码中。只重做界面和标准流程，可能丢失这些规则。

盘点重要应用的流程、用户、数据、集成与负责人，记录近期变更耗时、每周手动转录工作、受支持版本和测试过的恢复路径。如果每月导入因三个系统的客户 ID 不一致而需要两天对账，可能需要可靠接口。关键应用若运行在已失去支持的操作系统上，则面临另一类决策：平台迁移、替换，或有明确期限的过渡方案。

选择能够解决实际限制的策略

不同系统和功能可以采用不同策略。Microsoft 区分多种迁移方式，并结合依赖关系评估工作负载。迁往云端是基础设施决策，并不能证明应用自身已经现代化。

• 维护并稳定：业务功能合适、组件仍受支持、变更需求很少；持续关注依赖和最终替换。
• 重新托管：更换托管环境或旧硬件；应用结构和许多运行问题仍会保留。
• 调整平台：在保留核心业务逻辑的同时，将运行时或数据库迁到受支持的基础上；仍需测试兼容性。
• 针对性重构：改善经常修改、边界明确的薄弱点，同时让其他功能继续运行。
• 替换或退役：解决迁移、归档与依赖流程后，采用更合适的标准产品，或移除不必要功能。

逐步替换，并为并行运行设定终点

在绞杀榕模式中，新组件逐步接管边界明确的职责，中间层将请求路由到适当应用。Microsoft 的指南也介绍了过渡成本、共享数据，以及中间层成为瓶颈的风险。该模式并不适合每个小系统，也不一定适合很快就要整体替换的系统。

例如，将客户视图从既有订单系统中分离，而报价与发票仍留在原应用。试点前应决定哪个系统可以修改地址，以及变更如何传播。两个独立写入路径会制造相互矛盾的记录。可追溯的数据流是有价值的里程碑，新画面本身不是。

每项过渡连接都需要退役条件，否则企业会无限期地为两个平台及其连接付费。试点可以要求全部活跃客户完成核对、业务团队采用新视图，并确认生产中已没有读取方依赖旧接口。

一起计算开发、过渡与运行成本

应在相同时间跨度内，比较稳定后继续运行与拟议现代化方案。两者都应计入托管、许可证、支持和预期变更工作。迁移还会增加分析、数据清洗、并行运行、培训和退役成本。不确定的节省应以范围表示。

举例计算：如果每月确实减少十小时对账，按内部每小时 €70 计，在额外运行与维护成本之前，每年相当于 €8,400。节省时间最终变成支出降低还是可用产能，取决于企业情况。假设避免的停机，并不是有保证的额外节省。

数据导入必须经过业务核对才算完成

记录数量相同，并不能证明迁移正确。应检查客户 ID、总额、关系、字符编码、时区和历史例外。重建前收集代表性案例：普通订单、部分取消、贷项通知和事后更改的联系人。在两个系统中比较预期结果，并让业务人员解决差异。

明确切换期间如何处理新写入。新应用中的生产数据一旦变化，仅重启旧服务器可能已不足够。回退路径需要数据协调、约定时间窗口，或预先规定的向前修复方式。

最初几周应减少不确定性

有边界的调研阶段应产出关键数据流图、受支持的平台版本和有代表性的业务案例。将用户、运维和开发人员放在一起访谈。年终结账、冲销、导出和替岗访问等低频活动，可能不会出现在短期观察中，但仍可能十分关键。

将小规模技术调查对准最大未知数。先验证不确定的导出能力，再构建新界面；如果第三方集成决定进度，就及早取得访问。期限和书面结果能防止分析无限持续，却迟迟不做决定。

每个里程碑都要有收益、验收标准与停止条件

第一个里程碑应选择端到端业务流程，例如向有限用户组显示已有订单。验收应明确预期数据、约定负载下的响应时间、权限案例和业务验收人。扩大上线前，必须能够观察错误和数据差异。

如果多次试导入仍产生无法解释的差异，应推迟生产切换并调查。已经投入资金，并不能证明数据已准备就绪。里程碑完成后，再决定增加下一功能、调整策略，还是保留稳定的中间结果。

把退役作为独立工作包

切换后，夜间导出、账户或报表工具可能仍在访问旧数据库。应识别并迁移这些读取方和写入方。历史数据必须以约定、可用的格式保持可检索；无法读取的文件转储不是有用归档。

结束旧访问、许可证、备份任务、告警和运维文档。协调合同终止与必要访问的结束，避免退役造成另一次中断。完成之后，再比较预期节省与实际运行，并记录剩余差异及其原因。