原開發者不做了，接手前要拿回哪些資料？原始碼只是六類資產之一

原開發者要退出，很多人第一句會問：「原始碼拿到了嗎？」

原始碼當然重要，但只有一個 ZIP 檔，還不能證明下一個團隊接得起來。真正的接手條件是：公司擁有專案控制權，新團隊可以從乾淨環境建置、部署、還原與維護，而且不必繼續依賴某位個人的帳號或記憶。

接手前，至少把下列六類資產逐項盤點。

一、原始碼與版本歷史

不要只收某一天匯出的壓縮檔。應確認：

• 前端、後端、App、後台與基礎設施設定分別在哪些 repository；
• 預設分支、正式版 tag、目前 production 對應哪個 commit；
• submodule、Git LFS、私有套件與產生程式碼如何取得；
• issues、pull requests、release notes 與未合併分支是否仍有價值；
• 公司是否已成為 repository owner，而不是只被加成個人 collaborator。

GitHub 官方文件也顯示，repository 轉移會牽涉 issues、pull requests、設定、webhooks、secrets、deploy keys 與 packages。這代表「把程式碼 clone 下來」和「把整個開發資產移交」不是同一件事。

二、帳號、所有權與續費關係

先列出所有會影響服務存續的帳號：

• 網域註冊商、DNS 與 SSL；
• 雲端主機、資料庫、物件儲存與 CDN；
• Apple Developer、App Store Connect、Google Play Console；
• Email、簡訊、推播、付款、地圖、分析與監控服務；
• 第三方 API、套件 registry、設計與專案管理工具；
• 信用卡、發票、續費日期與帳務通知人。

正確目標不是取得前開發者的私人密碼，而是把 owner、管理員、付款與復原方式轉到公司可控帳號，再撤銷不需要的個人權限。

Apple 與 Google 的官方移轉文件都提醒，App 本身可以移轉，不代表所有憑證、整合與歷史報表都會自動完整跟著走。移轉前要先辨識哪些項目保留、哪些必須備份、哪些要重新建立。

三、環境、部署與基礎設施

至少要能回答：

• 開發、測試、預備與正式環境各在哪裡；
• CI/CD 如何觸發，使用哪些 runner、service account 與核准條件；
• production 從哪個 branch、tag 或 artifact 部署；
• 網路、DNS、排程、queue、storage、database 與權限如何配置；
• 部署失敗如何回復上一版；
• 哪些設定由程式管理，哪些仍是主機上的人工操作。

文件不能只寫「執行 deploy.sh」。新團隊需要知道前置條件、輸入、輸出、失敗訊號與回復方式。

已有專案要換團隊接手時，奧微軟體可依現有程式、帳號控制權與部署方式評估接手範圍，可參考軟體外包服務。

四、資料、備份與還原

拿到資料庫帳密不等於拿到資料治理方式。交接要列清楚：

• 資料庫 schema、migration、seed 與必要的 reference data；
• 檔案、圖片、附件、搜尋索引與快取放在哪裡；
• 備份頻率、保留期限、加密與存放位置；
• 最近一次成功還原是何時、在哪個隔離環境驗證；
• 個資、刪除、匯出、保留與稽核責任由誰處理。

備份檔存在，只能證明「有一個檔案」。實際還原成功，才證明它能用。

五、機密、憑證與撤銷清單

交接文件應記錄 secret 的用途、所在系統、owner、到期日與輪替方式，但不要把 token、私鑰或正式密碼直接貼進一般文件。

建議把項目分成三種：

1. 移轉後仍可沿用；
2. 接手時必須重新簽發；
3. 確認新系統可用後立即撤銷。

特別檢查 deploy key、雲端 access key、App 簽章、APNs、付款 webhook、OAuth client、資料庫帳號與備份金鑰。舊人員離開後仍可存取 production，是交接沒有完成，不是人情問題。

六、營運知識、風險與未完成事項

最後一類最容易遺失，因為它常只在原開發者腦中：

• 目前已知 bug、暫時解法與不能隨便改的區域；
• 外部廠商、支援窗口、合約與 SLA；
• 監控警報代表什麼、出事時先看哪裡；
• 每月、每季與憑證到期前要做哪些維護；
• 正在開發、尚未驗收與已承諾但未完成的項目；
• 哪些文件已過期，哪些決策仍有效。

不必要求原開發者補成百科全書，但高風險依賴與已知限制要明確留下來。

明示虛構教學例：預約系統的接手清單

以下是完全虛構的教學情境，不是客戶案例。

某公司要接手一套網站與 App 預約系統。對方先交付前後端原始碼與資料庫備份，看似已經完成移交。

盤點後才發現：網域仍在前開發者私人帳號、App Store 的 Account Holder 不是公司人員、正式環境靠某台個人電腦手動部署、推播憑證三週後到期，而且沒有人做過備份還原。

這時不應直接承諾「接手後照常運作」。應先建立資產表，逐項完成 owner 轉移、乾淨環境建置、測試部署、隔離環境還原與憑證輪替。通過後，才把日常維護責任交給新團隊。

最有效的驗收：空白電腦接手演練

文件收齊後，安排一次由新團隊主導的演練：

1. 用新的公司帳號取得 repository 與必要服務；
2. 在乾淨環境依文件完成建置與測試；
3. 部署到非正式環境；
4. 從備份還原一份隔離資料；
5. 觸發監控或測試事件，確認通知能到正確的人；
6. 記錄所有卡點、補文件，再重跑關鍵步驟。

不要只驗收「檔案有沒有交」。要驗收「不靠原開發者，接手人能不能做完必要操作」。

反例：原開發者仍願意配合，不必一開始就全面重建

如果原開發者仍可聯絡、服務目前穩定，而且公司已經掌握核心 owner 權限，最有效的做法通常是排定受控移交與演練，不是立即重寫系統、搬走所有服務或同一天輪替全部憑證。

一次改太多，反而可能讓原本可運作的服務中斷。先依風險排序：會失去控制權、即將到期、無備份或無法部署的項目優先；其餘在可回復的窗口逐步處理。

可直接使用的接手驗收表

每一項至少記錄：資產名稱、用途、目前 owner、新 owner、入口、續費／到期日、移轉方式、驗證結果、撤銷項目與負責人。

最後用四個問題收口：

1. 公司是否真的擁有控制權？
2. 新團隊能否從乾淨環境建置與部署？
3. 備份是否實際還原成功？
4. 原開發者離開後，是否還存在無人管理或無法撤銷的依賴？

若其中一題答不出來，交接就還沒完成。

如果你的專案正面臨開發者退出或維護團隊更換，可以先整理六類資產與接手演練結果。奧微軟體可依現有程式、帳號控制權、部署方式與風險邊界協助評估接手範圍；是否適合承作、需不需要重構，以及時程與費用，仍須檢視實際資料後另行評估。

資料來源與核對日期

• GitHub Docs, Transferring a repository，核對日期：2026-09-21。
• Apple Developer, Overview of app transfer 與 App transfer criteria，核對日期：2026-09-21。
• Google Play Console Help, Transfer apps to a different developer account 與 Transferring ownership of a Play Console developer account，核對日期：2026-09-21。

作者：奧微軟體內容團隊。本文為一般軟體專案交接與接手需求整理；奧微軟體開發企業社與軟體開發服務有商業關係，本文不構成特定專案可接手性、資安、法規遵循、工期、費用或成果承諾。