⚡ 重點摘要：(1) 先確認主機、網域、雲端平台的帳號在誰名下；(2) 動任何東西之前先完整備份；(3) 查出系統是用什麼做的、原始碼齊不齊；(4) 別急著重寫，先比較修、維護、重寫的成本；(5) 這次接手完，把交接清單補齊，不要再重演一次。

為什麼系統會變成「沒人知道怎麼運作」

通常不是誰的錯。系統是某個工程師（或外包工作室）幾年前做的，當時一切正常，也就沒人想到要留文件。後來工程師離職、轉行、工作室收掉，系統還在跑，所以大家也沒發現問題。

直到某一天網站白屏、表單收不到、憑證過期，或者只是想加一個欄位，才發現公司裡沒有任何人知道這套系統放在哪裡、怎麼改。這時候最容易做錯的事，是急著找人「先修好再說」。

第 1 件事：確認每一個帳號在誰名下

這是最重要、也最常被忽略的一步。系統本身不值錢，能不能登入管理它的帳號才是關鍵。請一項一項確認：

要確認的帳號去哪裡找線索
網域（例如 xxx.com.tw）網域續約通知信寄到誰的信箱？註冊商通常是 PChome、GoDaddy、Gandi 等
主機或雲端平台每月的帳單從哪張信用卡扣款？GCP、AWS、Hostinger 的帳單聯絡人是誰
DNS 設定有些網站的 DNS 另外放在 Cloudflare，帳號可能跟網域不同
網站或系統後台公司裡誰有管理員帳號？是個人帳號還是共用帳號
第三方服務金流（綠界、藍新）、LINE 官方帳號、Google Analytics、寄信服務

如果帳單是從公司的卡扣款，但帳號是工程師個人的信箱註冊的，現在就要處理。多數平台都有「帳號所有權轉移」的流程，只要能證明付款人或公司身分就能申請，拖越久越麻煩。

第 2 件事：動任何東西之前，先完整備份

接手別人的系統，最怕的不是修不好，而是修的過程弄壞了原本還能用的部分。所以不管是你自己、還是新找的工程師，第一步都應該是備份：

備份完還要確認真的可以還原。只存了檔案卻沒人試過還原，跟沒備份差不多。

第 3 件事：查出系統是用什麼做的、原始碼齊不齊

知道系統用什麼技術做的，才找得到對的人接手。你不需要自己看懂程式碼，但可以請工程師回答這幾個問題：

真實案例
一套系統，兩組工程師，三種狀況
之前接手評估過一套裝修業的管理系統。主系統放在 GCP 上，查下去是開源 CMS 二次開發，程式碼標準、邏輯清楚，可以直接接手維護。但同一台主機上還有一段後來由另一組工程師加上去的 Java 後端，主機上只剩編譯檔、沒有原始碼；App 前端也只找到打包後的版本。

所以結論不是一句「能接」或「不能接」，而是：主系統可以接；Java 後端和 App 前端要先向原開發者取回原始碼，否則那兩塊只能重做。先把這些搞清楚，後面的報價才會準。

第 4 件事：別急著重寫，先比較三種做法

很多老闆找了幾家廠商，得到的答案都是「這個要重寫」。重寫不一定錯，但要知道：看別人的程式碼很花時間，重寫對接手的人比較省事，不一定對你比較划算。可以請對方用這個角度比較：

做法適合的情況要注意的
修系統大致正常，只是某個功能壞了修完最好順便做一次健檢
維護系統還堪用，需要有人固定更新、備份、改小功能先補交接文件，之後才不會又斷掉
重寫技術太舊沒有安全更新、架構撐不住新需求、原始碼拿不回來費用最高，要規劃資料怎麼搬過去

比較好的接手工程師，會把這三種做法的費用和風險寫清楚讓你選，而不是只給一個答案。

第 5 件事：這次接手完，把交接清單補齊

最後這件事，是為了不要再重演一次。不管之後是誰維護，結案時都應該拿到：

常見問題

工程師聯絡不到，手上也沒有原始碼，系統還能救嗎？
大多數情況可以。網站和系統本來就放在主機上，只要主機或雲端平台的帳號在公司名下，就能從主機取回程式碼和資料庫。比較麻煩的是只剩編譯後的執行檔或打包後的前端，這時要向原開發者取得原始碼，或評估重寫那一部分。
新的工程師說一定要重寫，該相信嗎？
不一定。可以請對方用書面比較修、維護、重寫三種做法的費用和風險。只有架構撐不住、或安全問題太多時，重寫才是合理選項。
外包做系統時，合約要怎麼寫才不會被綁住？
至少寫清楚三件事：原始碼和資料的所有權屬於公司；主機、網域、雲端平台用公司名義申請；結案時交付原始碼、帳號清單和部署說明。
✅ 一句話總結：系統沒人管的時候，先搶回帳號、再做備份，最後才是修。順序對了，大部分的舊系統都救得回來。