系統爛尾點救？接手舊系統前的完整 checklist（2026）
系統爛尾、vendor 失聯、源碼混亂是香港中小企常見情況。本文列明接手前必須拿到的七樣東西、三種救援路線（穩定化／局部重寫／重建）、如何判斷值不值得救，以及避免再次爛尾的合約條款。
文章目錄（點擊展開）
系統爛尾、vendor 倒閉、開發人員離職、接手後發現源碼混亂——這在香港中小企與學校機構並不罕見。這篇不是講「我們幾叻」，而是講清楚：接手一個爛尾系統前，你應該先拿什麼、判斷什麼、以及哪三種情況下其實不值得救。
決策摘要（30 秒）
適合：現有系統仍在運作但無法維護、vendor 失聯、或接手後發現無文件。
範圍與工期：技術診斷 1–2 週；救援視乎系統狀態，由補文件到局部重寫，一般 4–12 週。
唔適合：系統連登入都做不到、又沒有資料庫備份——那已經不是救援，是重建。
一、先判斷：值不值得救
救援的成本差異可以極大，關鍵在第一天就判斷清楚。以下五個訊號，出現三個以上，就要認真考慮重建而非修補。
- ▸源碼沒有版本控制（沒有 Git），改動靠複製檔案
- ▸沒有資料庫結構文件，欄位命名無規律（例如 field1、field2）
- ▸核心功能依賴已停止維護的框架或套件
- ▸沒有測試，任何改動都可能弄壞其他功能
- ▸資料庫與程式邏輯高度綁定，無法分離
二、接手前必須拿到的七樣東西
這份清單可以直接拿去問前 vendor 或離職同事。拿不到，就代表你沒有真正擁有這個系統。
- 源碼與完整 Git 歷史（不只是最後一版壓縮檔）
- 資料庫完整匯出（含結構與資料），以及最近一次可還原的備份
- 伺服器／雲端帳戶的擁有權或管理員權限
- 網域、DNS、SSL 憑證的註冊商帳戶
- 第三方服務清單（金流、短訊、地圖、AI API）與其帳單歸屬
- 部署方式說明（就算是口述也要錄音）
- 任何已知的臭蟲清單與未完成功能
三、三種救援路線
| 路線 | 做法 | 適合情況 | 風險 |
|---|---|---|---|
| A. 穩定化 | 補文件、加監控、修高危漏洞，不改架構 | 系統仍能運作，只是想止血 | 技術債仍在，日後仍要處理 |
| B. 局部重寫 | 保留資料庫，逐個模組換新前端／後端 | 資料有價值但程式無法維護 | 期間新舊並存，需要較多測試 |
| C. 重建 | 重新設計與開發，只遷移資料 | 五個訊號中四個以上出現 | 成本最高、時間最長，業務要能承受 |
四、要幾錢、幾耐
我們不會在文章寫一個虛假價格。實際差別在於：資料結構是否可保留、要接幾個第三方服務、是否需要期間不停機。三個變數都會直接影響工期。診斷階段完成後，我們會給一個明確範圍，而不是一個開口價。
五、如何避免再次爛尾
- ▸合約要寫明源碼交付時間點，並放在你名下的 repo
- ▸每兩週要看得到可運作的版本，不接受「做完才給你看」
- ▸伺服器與網域一開始就登記在公司名下，不用 vendor 的帳戶
- ▸付款與里程碑掛鈎，尾數不少於一成半
三、接手第一日：不要改代碼
接手一個爛尾系統，第一日的衝動通常是「先修好它」。這是錯的。第一日應該只做三件事：備份、盤點、記錄。
- 全站與資料庫完整備份，並且實際還原一次到獨立環境。沒有測試過的備份，等於沒有備份。
- 盤點三樣東西：主機與帳號權限、第三方服務（金流、短訊、地圖、雲端）的帳號擁有者、以及所有部署流程。
- 寫一份現狀文件：哪些功能能用、哪些不能用、哪些沒人知道。這份文件是之後所有決定的基礎。
這一步看似浪費時間，但它決定了之後所有工作的安全性。我們見過太多次「一改就全站掛」，原因是沒有人知道那條線牽著什麼。
四、七十二小時穩定化：實際順序
| 時段 | 目標 | 具體動作 |
|---|---|---|
| 0–8 小時 | 停止失血 | 備份、關閉明顯有問題的功能入口、把錯誤訊息改為通用提示（避免洩露內部資訊） |
| 8–24 小時 | 恢復核心流程 | 確保登入、下單或提交這些「會收錢」的流程可用；其他功能可以暫時停用 |
| 24–48 小時 | 建立可見度 | 加錯誤記錄與基本監控；設定磁碟、憑證到期、服務中斷的告警 |
| 48–72 小時 | 寫下真相 | 列出現存問題清單、嚴重程度、以及「保留／重寫」的初步判斷 |
為什麼先停用而不是先修？因為不穩定的功能繼續對外開放，會持續產生錯誤資料與客戶投訴，而錯誤資料比停用更難收拾。
五、判斷「保留、修補、重寫」的標準
這是接手專案最重要的一個決定，也是最容易被情緒影響的決定。我們用三個可量化的指標：
| 情況 | 建議 | 理由 |
|---|---|---|
| 核心流程可運行，問題集中在介面與個別功能 | 保留＋修補 | 重寫成本高於修補，且風險更大 |
| 資料結構可用，但技術棧已停止維護 | 保留資料、重寫應用層 | 資料是資產，程式不是 |
| 沒有測試、沒有文件、原作者無法聯絡 | 分階段重寫 | 每次改動都是賭博，長期成本失控 |
| 核心流程本身設計錯誤（例如資料模型錯） | 重寫 | 在錯的基礎上修補，只會累積更多債 |
六、接手時最常被忽略的三件事
- ▸帳號擁有權。網域、主機、雲端、金流、短訊服務，如果仍掛在前供應商的帳號下，你隨時可以被斷掉。接手第一件事是把這些轉到你名下。
- ▸憑證到期日。SSL 憑證、API 金鑰、App 上架憑證，很多「突然壞掉」都是到期而非程式出錯。
- ▸備份是否真的存在。見過不少「有備份」的系統，備份檔案其實是空的，或者從未成功還原過。
七、怎樣避免再次爛尾
接手完成後，真正的價值是建立防止再發生的機制。四項最基本：
- 版本控制與可回滾部署。每次上線都可以一鍵回到上一版。
- 最小可行的測試。不需要全面覆蓋，但核心流程（登入、付款、提交）必須有自動測試。
- 文件與交接清單。包括環境變數、部署步驟、第三方服務清單。
- 監控與告警。問題發生時，你先知道，而不是客戶先知道。
八、常見問題
Q：前供應商不肯交出源碼怎麼辦？
先看合約是否列明源碼與帳號擁有權。實務上，如果資料與網域在你手上，即使沒有源碼，仍然可以重建；最壞情況是重寫，但不能接受的是資料被扣住。
Q：重寫會不會失去現有 SEO？
不會，只要網址結構與 301 對照表處理好。真正會失去排名的是「換網址但不做轉址」，而不是重寫本身。
Q：接手後多快可以恢復正常？
核心流程通常 72 小時內可以穩定；完整修復視系統規模，一般需要四至十二星期。任何承諾「一星期全部修好」的方案，都值得懷疑。
九、接手成本的三種情境
客戶最常問的是「接手要幾多錢」。誠實的答案不是一個數字，而是三個情境。以下為我們實際報價時使用的框架（不含具體金額，因為每個系統差異太大）：
| 情境 | 條件 | 工作量 | 你可以得到什麼 |
|---|---|---|---|
| 止血 | 核心流程可運行，只需穩定與修錯 | 最小 | 系統不再出事、有備份與監控 |
| 可控 | 需要整理架構、補測試、補文件 | 中等 | 之後每次改動都有把握、可回滾 |
| 重建 | 架構或資料模型已錯 | 最大 | 可支撐未來三至五年的系統 |
報價時應該分開列這三層，讓客戶自己選擇停在哪一層。只給一個總數，客戶無法判斷錢花在哪裡；分成三層，反而更容易成交，因為「止血」這一層的門檻低，可以先建立信任。
十、接手後的頭三個月，怎樣衡量是否成功
- ▸事故次數下降。由「每週有人回報壞掉」變成「每月一兩次」。
- ▸改動時間縮短。改一段文字或一個小功能，由「幾日」變成「幾小時」。
- ▸團隊敢改。同事不再害怕碰系統，因為知道有備份與回滾。
- ▸知識不再集中在一個人。至少兩個人知道部署與常見問題怎樣處理。
ADWire 編輯團隊
ADWire Agency Limited
文章由 ADWire 團隊撰寫及審閱。團隊負責軟件開發、AI 應用與工作流程自動化、SEO／GEO 及數碼營銷項目，內容取材自實際項目經驗及公開的官方資料。
- 軟件及系統開發
- AI 應用及流程自動化
- SEO 及 GEO 搜尋優化
- 數碼營銷及成效量度
