先讲结论
若核心数据结构仍能支撑现行业务，应优先选择局部改造；若每新增一项功能都须变动基础结构，或连原开发者都无法说明数据流向，重做才是成本较低的选项。判断重点不在系统新旧，而在于是否还能安全地修改。
四项判断标准
一、数据结构是否仍可支撑
这是最关键的一项。界面美观与操作流畅度均可调整，但若当初的数据表设计无法表达现行的业务关系——例如原本假设一个客户仅有一位联系人，如今却须管理整个对接人群组——那么任何新功能都只是在补丁上叠加补丁。
二、改动的风险是否可控
可用一个问题检验：修改 A 功能时，是否有人能明确指出会影响哪些范围？若答案是必须改了才知道，代表系统已失去可维护性，持续投入只会累积风险。
三、问题出在系统或流程
相当比例的「系统难用」，实际上是流程本身未经厘清，只是被系统忠实反映出来。此种情况即使重做一套，半年后仍会回到相同的问题。先厘清流程，往往能省下一整套系统的预算。
四、技术与人力是否仍可取得
若系统采用的技术已无厂商愿意承接，或源代码并不完整，那么能否修改就不再是技术判断，而是现实限制。
还有第三个选项：分阶段替换
选项不只维持现状与全部重做两种。实务上常见的做法，是先将最急迫的一段流程独立建置为新系统，与旧系统之间以 API 或数据同步对接，待新系统稳定后再逐步接手其他模块。此做法可避免一次性切换的风险，也让预算分散于不同年度。
评估时建议准备的资料
- 现行系统的数据表结构，或至少主要功能清单。
- 近半年提出但未被实现的需求，以及未被采纳的原因。
- 使用者实际反映的具体情境，而非仅有「难用」的概括描述。
