舊系統現代化指南：該修、該換，還是重寫？
幾乎每家經營超過幾年的公司，都有一套「不要碰它」的系統。它還在跑，但沒有人完全知道它怎麼跑；能改的人離職了，原廠聯絡不上；每次要加一個功能，答案都是「那個做不了」。
要不要處理它，是一個投資決策，不是技術品味問題。這篇整理判斷的訊號、三種可選策略，以及執行時最該防的風險。
老舊系統的五個訊號
一、沒有人敢改。 系統能動，但沒有文件、沒有測試，改一個地方不知道會影響什麼。於是所有需求的答案都變成「先不要動它」。
二、找不到原廠或原作者。 開發的公司不在了、負責的員工離職了、原始碼不在你手上。這時系統實際上已經進入無主狀態。
三、安全性無法修補。 底層的作業系統、資料庫或程式語言版本已經停止更新，代表新出現的漏洞不會有修補。這一項的風險會隨時間單向增加。
四、無法和其他系統整合。 資料只進得去、出不來，所有跨系統的事都要靠人工匯出匯入。相關的處理方式見系統整合與 API 串接開發指南。
五、人工補償越來越多。 有人專門負責「系統做不到的那部分」，用試算表、便條或口頭交接補洞。這是最容易量化的訊號：去算那些人每週花多少時間。
要注意的是，系統老舊本身不是問題。如果它穩定、沒有安全疑慮、也沒有擋住任何業務決策，那維持現狀是理性的選擇。真正該處理的是它已經開始收你看不見的稅。
三種策略與各自的適用情境
策略一：原地修補
維持現有架構，只處理最急迫的問題：補上安全性更新、修掉高風險缺陷、加上備份與監控、補寫最基本的文件。
適合：系統核心邏輯仍符合業務、短期內沒有大幅擴充需求、或公司正處於其他優先事項的時期。
代價：問題延後而非解決，且每次修補都可能讓結構更複雜。適合當作爭取時間的手段，不適合當終局。
策略二：逐步汰換
保留舊系統，但把功能一塊一塊搬到新系統。新舊並存一段時間，透過介接讓兩邊資料保持一致，直到舊系統只剩空殼再退役。
適合：系統龐大、業務不能中斷、模組之間界線還算清楚的情況。這也是多數中大型汰換的實際作法。
代價：過渡期要同時維護兩套，介接本身也是一份工作。時間拉得比較長，需要耐心與明確的階段目標。
策略三：整體重寫
重新規劃、重新開發，一次切換。
適合：舊系統已經無法繼續運作、技術上無法延伸、或業務模式本身要改變——這點很關鍵，如果只是想要同樣的東西但比較新，重寫的報酬率通常不高。
代價：風險最高。舊系統裡藏著大量沒有寫下來、但真的有人依賴的規則，重寫最容易漏掉這些。而且重寫期間舊系統還是要維護。
選擇的原則：業務不能停、規則不清楚 → 逐步汰換；業務要改、舊系統無法承載 → 重寫；還沒想清楚、但風險要先壓住 → 先做原地修補，同時進行盤點。
資料遷移是最大的風險
比程式重寫更容易出事的是資料。原因在於程式錯了會報錯，資料錯了只會安靜地算出不對的數字。
先盤點，再談搬。 要搬哪些資料表、哪些歷史範圍、哪些是重複或錯誤資料、哪些其實可以不搬只留查詢。多年累積的資料裡，往往有相當比例是無效的，把它們一併搬進新系統，等於把問題帶著走。
欄位意義要逐項確認。 金額含稅還是未稅、日期有沒有時區、狀態代碼的定義、同一個客戶在不同表裡的編號是否一致。這一步的工作量常被低估。
先做試遷移。 在正式切換前完整跑一次，並逐項對帳：筆數對不對、金額總計對不對、抽樣的單筆資料在新舊兩邊長得一樣嗎。沒對過帳的遷移不能上線。
保留舊資料的唯讀查詢。 切換後一段時間內，仍要能查到舊系統的原始樣貌，這是爭議發生時唯一的依據。
訂好回退方案。 切換當天若發現重大問題，怎麼退回去、退回去之後這段時間的新資料怎麼處理。這個方案要在切換前就寫好並演練。
如何降低停機與業務中斷
平行運行。 新舊系統同時運作一段時間，同樣的作業兩邊都做，再比對結果。這會增加人力負擔，但它是最有效的驗證方式，尤其適合帳務與庫存類系統。
挑對切換時間。 避開結帳日、檔期、報稅期與連假前。這聽起來理所當然，實務上卻常因為專案時程壓力被忽略。
分批切換使用者。 先讓一個部門或一個門市使用，問題收斂後再擴大。第一批使用者要挑願意回報問題的人，而不是最重要的那批客戶。
教育訓練不是上線那天才做。 老系統用了很多年的同事，最大的阻力通常不是不會用，而是沒有被說明為什麼要換。把新流程的原因講清楚，比多做兩份操作手冊有用。
保留應變時段。 切換後的第一週要預留人力處理臨時狀況，不要把切換排在所有人都很忙的時間點。
如果這套舊系統同時是對外網站，網址與搜尋排名的處理另有一套步驟，見網站改版 SEO 檢查清單——那篇專門處理「換系統時不要掉搜尋流量」這件事，與本篇的內部系統汰換互為分工。
四個常見的誤判
「先把畫面換新就好。」 把舊系統套一層新介面，短期有感，但底層的限制一項也沒解決，而且之後真正要動結構時，等於要再改一次。介面翻新可以是策略的一部分，不該是全部。
「找到原本的程式碼就沒事了。」 拿回原始碼是必要條件，不是充分條件。沒有環境設定文件、沒有資料庫結構說明、沒有測試，接手的人一樣要從頭理解。移交清單要涵蓋的範圍，比多數人想的更廣。
「等業務比較閒的時候再做。」 業務不會變閒，而系統的風險會隨時間增加，尤其是已經停止安全性更新的部分。比較可行的是把工作切小，讓它能在日常節奏中進行。
「換一套套裝軟體就能解決。」 導入現成系統確實能省下開發，但它要求你把流程改成系統的樣子。這件事的難度在於組織與習慣，不在技術；評估時要一併算入流程調整與教育訓練的成本。
預算與時程該怎麼思考
現代化專案最難估的原因是：你在估一個自己還沒完全看懂的東西。 比較務實的作法有三個。
第一，先花一小筆做技術盤點。 在投入大筆預算前，先做一次現況評估：系統架構、資料狀況、風險清單、可行策略與優先順序。NETVANA 的軟體顧問服務（含技術架構審查與技術盡職調查）交付的就是這類技術評估報告、架構建議文件與優先順序路線圖。這一步的價值在於把後面的估算變得可信。
第二，用階段而不是整包來規劃。 NETVANA 以兩週為一個 Sprint、每個週期提供可操作的版本，用意就是讓你在過程中看到實際進度並調整優先序，而不是等到最後才知道方向對不對。專案完成後原始碼、設計檔與部署文件會完整移交，避免再次落入「找不到原廠」的處境——這也是評估合作對象時務必確認的條款，見如何挑選軟體開發公司。
第三，把維運成本放進同一張表。 新系統上線後的監控、備份、更新與支援，是這筆投資能不能維持的關鍵，安排方式見網站維護費用包含什麼。很多現代化專案最後失敗，不是做不出來，而是沒有人負責讓它繼續健康地跑下去。
舊系統的問題很少是突然爆發的，它通常是慢慢地把你的選項收窄：不能改、不能串、不能查、不能擴充。處理它的第一步不是決定要不要重寫，而是先看清楚它現在到底長什麼樣子。
如果你手上有一套沒人敢動的系統、想先釐清風險與可行的路線，與 NETVANA 討論你的現況。我們會先做技術盤點再談方案，軟體服務採先諮詢再報價，服務內容與交付物見軟體服務介紹。
延伸閱讀：新舊系統要並行時的串接重點，見系統整合與 API 串接開發指南；對外網站改版不掉搜尋流量的步驟，見網站改版 SEO 檢查清單；評估合作對象與合約條款，見如何挑選軟體開發公司；重做一個新的要多少錢，先跟修舊的比，可以看網站製作費用怎麼算；決定重寫之前，先決定由誰來寫這一版，可以看軟體外包還是自建團隊；舊系統難改的原因，多半是累積多年的技術債，可以看技術債是什麼白話解釋；決定重寫舊系統前，先確認客製開發是不是唯一選擇，可以看買現成 SaaS 還是客製開發；紙本簽核也是一種舊系統，該修還是該換看這篇，可以看電子表單與簽核流程系統；決定要換系統之後，資料轉移該怎麼安排，可以看換系統時的資料轉移。
