先講結論： 系統還在跑，就還有時間。真正讓你失去選擇的不是程式碼寫得爛，是存取權限拿不回來。所以第一件事不是急著找人接手，是確認網域和主機帳號在不在你名下。技術的事後面再說。
我接手過十幾套別人開發的系統。打來的人講的話其實很像：原廠不回訊息了、唯一懂這套系統的工程師離職了、想改一個欄位但沒人敢動。
而且幾乎每一次，對方手上什麼跟程式有關的東西都沒有。沒有原始碼、沒有架構圖、沒有部署說明，有時候連主機開在哪家都要查帳單才知道。只剩一個還在跑的網站，和一個不回訊息的聯絡人。
如果你現在就是這個狀況，這篇是寫給你的。
我現在最該先做什麼？
不是找人報價，是先確認哪些東西還在你名下。順序是這樣：
- 網域：登記在誰名下、管理後台的密碼在不在你手上。這一樣掉了最難救，因為它牽涉到所有權移轉程序，不是技術問題。
- 主機或雲端帳號：AWS、GCP 或主機商的主帳號是誰開的。如果是前廠商用他們自己的帳號開的，你買的其實是租來的房子。
- 程式碼：在哪裡、你有沒有讀取權限。很多人到這一步才發現自己從來沒拿過。
- 資料：備份有沒有在跑是一回事，有沒有人實際還原過是另一回事。沒有還原測試過的備份，不能算備份。
前兩樣在你名下，你就有完整的談判空間，接下來找誰做都可以。缺的話，先處理那一樣，那比找開發廠商急。
什麼都沒有，是不是就沒救了？
不是。什麼技術資料都沒有是常態，不是例外。
程式碼和資料庫本身就是最完整的文件，架構可以從裡面反推回來，補文件本來就是交接工作的一部分，不是接手的前提條件。
真正卡住的是拿不到程式碼，不是看不懂程式碼。這兩件事的難度差很多。
你們會不會一接手就叫我重寫？
不會。多數系統可以直接接手維護，或分階段改善。
我會建議重做的情況其實只有一種：這套系統已經難以維護，而且程式碼過舊。 兩個條件要同時成立。
怎麼判斷「難以維護」，你自己就能看出來：
- 改一個很小的地方（例如表單多一個欄位），要動到很多個檔案
- 每次改完都有別的地方壞掉，修一個冒一個
- 前一個廠商後期改東西的速度明顯變慢
「程式碼過舊」則是看框架或語言的版本，還有沒有在收安全更新。這一點不用猜，官方都有公開的時程表：PHP 的維護狀態列在 php.net 的 Supported Versions，Node.js 在 Previous Releases，其他常見框架可以查 endoflife.date。
停在已經沒人維護的版本，代表漏洞只會愈積愈多。OWASP 把這類問題單獨列為十大風險之一（A06: Vulnerable and Outdated Components），而且愈晚處理愈貴，因為要跨的版本越多。
反過來說，「程式碼很醜」不是重做的理由。醜但結構清楚的系統，維護起來比看起來便宜很多。會建議你重寫的人，不一定是因為系統該重寫。
接手之前要花多少錢、多久？
NT$30,000 起，依系統規模而定，一週內給你答案。如果決定繼續合作，這筆錢全額折抵。
這不是在賣一份報告。是我要看過程式碼、架構、主機和資安狀況，才能判斷這套系統接得下來、還是該重做。看過之前報的價格都是猜的，所以我們不猜。
看完你會知道三件事：現在的風險在哪、接手要花多少、以及該不該接手。就算你看完決定找別人做，結論還是你的。
接手之後多久能正常運作？
看過系統大概一週，接著是交接：取得各項權限、補齊文件、建立可以重複執行的部署流程。
這一段的長短通常取決於權限拿回來的速度，不是技術。跟前廠商還能聯絡上的案子，會快很多。
交接完成後進入正常維運，由同一個團隊負責監控、修復和後續調整。
後續維運費用怎麼算？
月約維運 NT$7,000 起，依系統規模和你需要的回應速度而定，在看過系統之後議定。
如果你的需求會持續產生（不只是修 bug，還會一直有新功能），固定人力方案通常比月約划算，維運已經包在裡面。
換一家廠商，會不會又遇到一樣的事？
不敢保證，但有三件事可以在簽約前就先擋掉，而且成本是零：
- 帳號開在你名下：雲端、網域、程式碼儲存庫都用你的帳號建立，廠商只拿協作權限。
- 合約寫明交付物：原始碼、資料庫、部署文件，而不是只有「系統上線」四個字。
- 先問清楚上線之後誰維護：多數糾紛不是開發階段出事，是保固結束之後沒人接。
這些寫進合約不用花錢。事後補救的成本，就是這整篇文章在講的事。