CTO、工程師或外包團隊離職了
原本負責系統的人離開，交接不完整或根本沒交接，剩下的人不清楚系統怎麼 build、怎麼部署、資料在哪。
軟體接手與救援 · 取得控制權 → 確認可維護 → 接手方案
工程師離職、原開發團隊不在了？先把系統安全接回來
「我的工程團隊離職了，你們可以直接接嗎？」——可以評估。但接手的第一步不是馬上改程式，而是先確認你能不能真正拿回系統的控制權、系統能不能被安全維護，再決定該直接接手、局部重構、逐步替換，還是必須重建。
適用情境
如果你正遇到這幾種狀況，這頁就是為你寫的。
這些情境的共通點不是「還沒開始做」，而是「已經有一套在跑的系統，但負責它的人不在了」。這時最怕的不是功能不夠，而是沒人敢動、也沒人知道動了會不會出事。
Production 還在跑，但沒人敢改
系統每天都在服務客戶，但沒有測試、沒有部署流程、也沒有回滾方式，改一行都怕整個掛掉。
沒有文件，只剩 source code 或 cloud 帳號
手上可能只有一份 repo、一組 cloud 登入，或幾個外包留下的帳號，卻沒有架構圖、部署說明或相依清單。
AI／vibe-coded 原型已經上了 production
用 ChatGPT、Cursor、Lovable 或 vibe coding 快速做出來的東西已經在對外服務，但沒有人能維護、也不確定它安不安全。
接手流程
接手分三個階段，每一階段都先確認清楚，再往下走。
我們不會一開始就承諾「全部接下來」。接手是有順序的：先確認你拿得回控制權，再確認系統能不能被安全維護，最後才依結果提出接手方案。任何一個階段卡住，我們都會誠實告訴你風險在哪。
階段 01
取得控制權（Access & Ownership）
盤點並確認你是否真正掌握：程式碼庫（repo）、網域（domain）、DNS、cloud 帳號、資料庫、環境變數與 secrets、第三方 API、金流、email、監控與備份、CI／CD。控制權不完整時，先協助你把該拿回的權限拿回來——這是所有後續動作的前提。
階段 02
確認能否安全維護（Maintainability）
驗證系統能不能被安全地 build、測試、部署、回滾、做資料遷移、還原備份，以及存取權責是否清楚。這一步的目的，是找出「改下去會不會出事」的真實風險，而不是先急著加功能。
階段 03
接手方案（Takeover Plan）
依前兩階段的結果，提出可討論的接手路線：直接接手維護、局部重構、逐步替換或必須重建。我們不預設每個系統都要重寫——能安全維護的就維護，該重建的才重建，並把取捨寫清楚讓你決定。
交付內容
接手不是口頭承諾，而是一組你能留著、看得懂的文件。
接手完成後，你手上會有一套可持續使用的資產，讓系統之後不管由誰維護，都有可依循的基準——不會再回到「只有一個人知道」的狀態。實際交付內容會依系統狀況與範圍調整。
- System Architecture Map系統架構圖：服務、模組與資料流怎麼串起來。
- Access Map存取地圖：哪些帳號、權限、金鑰控制哪些資源。
- Dependency Map相依清單：第三方套件、API 與服務的相依關係。
- Risk Register風險清單：已知風險、影響與建議處理順序。
- Deployment Runbook部署手冊：怎麼 build、部署、回滾與處理常見狀況。
- Backup-Recovery Plan備份還原計畫：資料怎麼備份、真的能不能還原。
- 30-60-90 Day Plan接手後的 30／60／90 天計畫：先穩住什麼、再改什麼。
接手方案
四種可能的方向，我們不預設每個都要重寫。
「要不要重做？」是接手時最常被問、也最容易被亂建議的問題。重寫聽起來乾脆，但常常最貴、風險也最高。我們會依控制權與可維護性的真實結果，建議最合理的方向，並把取捨講清楚。
誠實邊界
我們先把「不保證什麼」講清楚。
不保證每個系統都能救回
有些系統在控制權或可維護性檢查後，確實不值得繼續維護。我們會誠實說明，而不是硬接。
盤點前不給固定報價
沒有先確認控制權與系統狀況，任何報價都只是猜測。我們先檢查，再談範圍與成本。
不預設重寫，也不做法律／稽核結論
能維護的就不重寫；法律、稽核與合規判斷仍需交給對應專業，我們提供技術面的可討論依據。
你的狀況可能更接近這幾種
還不確定自己屬於「接手」還是「救援」？
如果你的問題不是「團隊離職沒人接」，而是某個東西做一半、卡在上線前，或你只是想先判斷該從哪一步開始，下面這幾個入口更適合你。
常見問題
常見問題：把接手的範圍和邊界說清楚。
工程師都離職了，你們可以直接接手我們現在的系統嗎？
可以評估。第一步不是馬上改程式，而是先確認你能不能拿回 repo、domain、DNS、cloud、資料庫、環境變數與各種帳號的控制權，並盤點系統能不能安全 build、測試、部署、回滾與還原備份，再依結果判斷直接接手或其他方案。
系統只剩 source code、沒有任何文件，還能接手嗎？
多數情況可以，但需要先做盤點。我們會從現有的 source code、cloud 設定與執行中的服務反推架構、相依套件與部署方式，補出 System Architecture Map、Access Map 與 Deployment Runbook，讓後續維護有可依循的基準。
接手一定要整個重寫嗎？
不預設要重寫。我們會依風險與成本提出四種方案——直接接手維護、局部重構、逐步替換或必須重建——並說明各自的取捨。能安全維護的系統就不重寫，避免不必要的重建成本。
會直接給報價或保證能救回來嗎？
不會在盤點前給固定報價，也不保證任何系統都能救回。我們先做可驗證的控制權與可維護性檢查，把風險與可行路線寫成可討論的文件，讓你在資訊清楚的情況下決定下一步。
從檢查現有系統開始
先讓我們檢查你現在的系統。
告訴我們你目前的狀況：原團隊離開了嗎、你手上有哪些帳號與 source code、系統還在服務嗎、最擔心的是什麼。我們會先做控制權與可維護性檢查，再判斷下一步——不先報價、不先承諾重寫。