先講結論
若核心資料結構仍能支撐現行業務，應優先選擇局部改造；若每新增一項功能都須變動基礎結構，或連原開發者都無法說明資料流向，重做才是成本較低的選項。判斷重點不在系統新舊，而在於是否還能安全地修改。
四項判斷標準
一、資料結構是否仍可支撐
這是最關鍵的一項。介面美觀與操作流暢度皆可調整，但若當初的資料表設計無法表達現行的業務關係——例如原本假設一個客戶僅有一位聯絡人，如今卻須管理整個窗口群組——那麼任何新功能都只是在補丁上疊加補丁。
二、改動的風險是否可控
可用一個問題檢驗：修改 A 功能時，是否有人能明確指出會影響哪些範圍？若答案是必須改了才知道，代表系統已失去可維護性，持續投入只會累積風險。
三、問題出在系統或流程
相當比例的「系統難用」，實際上是流程本身未經釐清，只是被系統忠實反映出來。此種情況即使重做一套，半年後仍會回到相同的問題。先釐清流程，往往能省下一整套系統的預算。
四、技術與人力是否仍可取得
若系統採用的技術已無廠商願意承接，或原始碼並不完整，那麼能否修改就不再是技術判斷，而是現實限制。
還有第三個選項：分階段替換
選項不只維持現狀與全部重做兩種。實務上常見的作法，是先將最急迫的一段流程獨立建置為新系統，與舊系統之間以 API 或資料同步串接，待新系統穩定後再逐步接手其他模組。此作法可避免一次性切換的風險，也讓預算分散於不同年度。
評估時建議準備的資料
- 現行系統的資料表結構，或至少主要功能清單。
- 近半年提出但未被實作的需求，以及未被採納的原因。
- 使用者實際反映的具體情境，而非僅有「難用」的概括描述。
