现有软件，应该维护、重构还是重写？

先说清楚需要消除什么限制。

页面缓慢、反复出错与依赖失去支持，是不同问题。运行稳定但缺少一项功能的产品，与无法构建或难以可靠发布的系统，需要不同的评估。

介绍受影响的流程、遇到问题的人，以及对业务的影响。如果方便，整理复现步骤、目前的临时处理方式和希望实现的改变，让评估有具体对象。

• 哪项任务失败，或需要额外手工处理？
• 问题局限于某个组件，还是影响整个流程？
• 修改期间，哪些工作必须继续运行？

确认现有产品是否具备开展工作的条件。

接手评估需要了解运行演示之外的情况。代码、文档、依赖、环境与发布过程，都会影响能够修改什么，以及怎样验证。

资料缺口本身也需要规划。先确认账号与材料是否可用、产品能否构建，以及依赖哪些外部服务。敏感代码与凭据应通过约定的访问安排提供。

• 源代码、构建说明与可用文档。
• 托管、部署方式与相关账号归属。
• 依赖、系统集成与已知运行限制。
• 已有测试、测试资料与可行的验证环境。

比较三种可能的路线。

当前产品能够支持下一步需求时，可以考虑维护与扩展。例如局部修复、依赖更新或增加功能，再检查受到影响的行为。

某个部分难以调整，但其他部分仍有价值时，可以考虑重构或替换组件。明确新旧部分的边界、需要保留的行为，以及兼容性怎样检查。

所需改变难以在现有环境中合理实现时，可能需要较大范围的重建或迁移。仍需梳理业务规则、数据和集成点；仅重做界面，不能说明已经保留完整业务流程。

把数据与切换纳入工作。

资料或流程需要转移时，明确数据映射、验证和过渡安排。哪些记录需要继续访问、错误怎样修正、团队在切换时需要做什么，都应提前了解。

业务连续性取决于系统与选定方案，不能默认全程无中断。实施前需要评估可接受的中断、是否并行运行、发布职责与恢复方式。

用评估结果，确定第一阶段。

第一份有用的成果，可以是局部修复、现状评估记录，或某个组件的替换计划。它应说明产品情况、可选路线，以及仍影响费用或时间的假设。

明确第一阶段，可以为下一步提供依据，不必一开始就承诺全面重写。后续开发与持续支持，再结合评估结果确定。