科技執法系統換廠商時要移交的不只是原始碼，而是五類標的：程式與建置、資料、憑證與帳號、文件，以及營運中的委託關係。判斷有沒有真的交接完成，標準只有一個——新的承接方在不詢問原廠商的情況下，能不能用收到的東西把系統重建起來。做不到這件事，簽收清冊上打再多勾也只是形式。
交接之所以經常出事，是因為它發生在一個所有人的動機都最低的時間點。原廠商的契約即將結束、尾款多半已請領、熟悉系統的工程師往往早就被調去別的案子；機關的承辦人可能剛輪調接手，手上只有一份三年前的規格書；承接方則還在等機關開設權限。這段期間如果系統出狀況，責任歸屬幾乎必然變成爭議。
這篇把換廠商當下實際要點交的東西、每一類怎麼驗才算收到、時程怎麼排，以及最常卡住的六件事寫清楚。退場條款本身要寫進規格書哪幾項（原始碼、資料庫與案件資料的交付格式、期限與協助義務），在科技執法標案規格書怎麼寫那篇已經列過，本文不重述條文寫法，只補「條文寫好之後，交接現場實際怎麼執行」。
科技執法系統交接要點交什麼？五類移交標的
下表是建議直接拿來當移交清冊骨架的五類標的。右欄的「最常缺的那一項」不是理論推導，而是盤點既有系統時最常發現的空白——這幾項通常不是原廠商刻意扣留，而是當初的契約根本沒有把它列成交付項目。
| 類別 | 要移交的內容 | 最常缺的那一項 |
|---|---|---|
| 程式與建置 | 原始碼、版本庫完整歷史、編譯與佈署腳本、相依套件清單、設定檔範本 | 佈署腳本與相依套件版本，導致程式拿得到卻裝不起來 |
| 資料 | 資料庫結構、可還原的完整備份、歷史案件資料、影像母檔與各自的格式說明 | 影像母檔的存放位置與命名規則，只拿到判讀後的輸出檔 |
| 憑證與帳號 | 伺服器與網路設備管理帳號、資料庫帳號、憑證與金鑰、第三方服務帳號與續約窗口 | 第三方服務登記在原廠商名下，帳號移交不了，只能重新申辦 |
| 文件 | 系統架構圖、介接規格、資料庫綱要、操作手冊、維運手冊、已知問題清單 | 介接規格與已知問題清單，前者靠讀程式反推，後者只存在於離職工程師的記憶裡 |
| 營運中的委託關係 | 網域註冊與管理權、主機與機房合約、監控與告警的收件設定、對外通知服務 | 告警信箱仍設定在原廠商的內部群組，換約後沒有人收得到故障通知 |
五類之中，第五類最容易被整個漏掉。程式、資料、帳號、文件都是看得見的交付物，會出現在驗收清單上；但「網域登記在誰名下」「告警要寄給誰」是營運設定，不是交付物，往往沒有人負責提出來。等到換約之後某個清晨系統中斷、卻沒有任何人收到通知，才發現監控還在對著上一家廠商的信箱響。
交接時最不對等的一件事：口頭知識
系統跑了三年，一定累積出一批沒有寫進任何文件的判斷：哪一個路口的設備在雨天容易誤判、哪一支批次程式不能跟月報同時跑、哪一類案件送出去會被退件而要改欄位再送。這些知識沒有載體，契約也很難要求交付，可行的辦法只有一種，就是在交接期安排並行作業，讓兩方的工程師同時處理幾週的日常維運，把問題在現場問出來。把「並行期間原廠商應指派熟悉本案的工程師參與」寫進退場條款，比要求「提供完整文件」更有用，因為前者驗得到人，後者只驗得到紙。
交接怎麼驗才算真的收到？獨立重建演練
驗收交接不能用「文件已提供」當判準，要用「承接方能不能自己把系統做起來」當判準。做法是在交接期間安排一次獨立重建演練：由承接方只用移交到手的原始碼、備份與文件，在另一套環境把系統佈署起來，還原一份資料，跑通一條完整的案件流程，並送一筆資料到介接對象的測試環境。演練過程原廠商在場但不出手，只記錄承接方卡在哪裡——每一個卡點就是一項移交缺失。
五類標的各自的「收到」判定動作
- 程式與建置：在乾淨的環境照文件佈署一次，跑得起來才算收到。同時確認版本庫是完整歷史而不是最後一版的壓縮檔——沒有歷史就查不出某個判斷邏輯是什麼時候、為了什麼被改成現在這樣。
- 資料：實際還原一份備份，比對筆數與日期範圍，並抽驗幾件跨年度的舊案件是否連影像都調得出來。備份檔能不能還原，是還原過才知道的事。
- 憑證與帳號：逐一登入確認權限層級，確認到期日並列進維運行事曆。簽收之後立即全部更換一次密碼與金鑰並記錄，這一步不是不信任原廠商，而是讓責任起算點乾淨。
- 文件：抽兩件事照著文件做一次——例如新增一個路口、重跑一次退件的案件。照著做得出來才算文件有效，讀得懂不等於做得到。
- 營運中的委託關係：登入網域管理介面確認登記人與管理權、確認主機合約的到期日與續約窗口、把告警收件人改成機關與新承接方，並實際觸發一次測試告警確認收得到。
介接是重建演練中最容易失敗的一環，因為它牽涉第三方。承接方就算拿到完整原始碼，也不見得有對方系統的測試環境、來源 IP 開放或憑證。建議把「介接對象清單與各自的窗口、憑證到期日、測試環境申請方式」當成獨立的一份交接文件，六類介接對象怎麼盤點、規格書要寫死哪七個欄位，見科技執法系統要介接哪些系統；那篇提到「沒有交付介接規格的專案，換廠商時只能讀原始碼反推」，交接現場印證這句話的方式，就是看承接方能不能在演練當天送成功一筆測試資料。
證據類資料的移交另有要求。影像母檔、完整性驗證值與稽核軌跡要以什麼格式移交、由誰驗收，必須在移交前講定，因為這幾項一旦在搬移過程中斷鏈，後續的申訴案件就補不回來。各類證據要素與保存期限的訂法見交通違規證據鏈要保存什麼。
交接時程怎麼排？換約前 90 天的三個階段
建議從契約到期日回推至少 90 天啟動交接，並分成三個階段。90 天不是法定期限，而是從實務推回來的估算：光是第三方服務的帳號移轉、網段與防火牆的重新申請、機關帳號開設這幾件事，往返時間就經常吃掉一個月，重建演練發現缺失後還要留補件與複驗的時間。
| 階段 | 時間 | 主要工作 | 完成判準 |
|---|---|---|---|
| 一、盤點與清冊確認 | 到期前 90～60 天 | 原廠商提出移交清冊；機關確認範圍；釐清哪些項目屬第三方授權或其他機關的系統 | 清冊經三方簽認，爭議項目已列出並標明處理方式 |
| 二、交付與重建演練 | 到期前 60～30 天 | 文件、原始碼、資料與帳號分批交付；承接方做獨立重建演練；缺失列表並補件 | 承接方在另一套環境跑通完整案件流程並送出一筆測試資料 |
| 三、並行與收尾 | 到期前 30 天～到期日 | 兩方同時處理日常維運；交代未結案問題、待處理申訴與介接異常；帳號密碼全面更換 | 並行期間的事件全部由承接方主辦、原廠商僅協助，且無須升級回原廠商處理 |
上表為建議的起草基準，實際天數應依系統規模、介接對象數量與機關採購作業時程調整。
三個階段裡最不能省的是第三階段的並行。前兩個階段交付的是東西，第三階段交付的是「有能力處理未預期狀況」這件事，而那只有在真實事件發生時才驗得出來。並行期間建議刻意涵蓋一次月結、一次月報產出與一次批次交換的完整週期，讓週期性的工作至少被承接方獨立跑過一輪。
交接期間的維運責任歸屬也要先寫清楚：哪一天起事件由誰主辦、原廠商的協助義務到什麼程度、未達標怎麼認定。回應時效分級、扣款級距與稼動率以誰的監測為準，在警政系統維運委外怎麼談 SLA那篇有完整訂法，交接期直接沿用同一套分級即可，只需另外註明並行期間的主辦方。
交接最常卡住的六件事
以下六項不是技術難題，而是權利與流程問題。共同點是：全都要在招標階段預防，到了換約前才處理幾乎都來不及。
- 第三方元件的授權不可轉移：系統用到的地圖服務、辨識引擎、報表元件或資料庫，授權可能登記在原廠商名下且按公司授權計價。招標時就要求載明所有第三方元件、授權方式與是否隨案移轉。
- 網域與主機登記在廠商名下：機關的對外平台若由廠商代辦網域註冊，換約時管理權移轉會卡在對方的作業流程。網域一律登記在機關名下、廠商只任管理者，是成本最低的預防措施。
- 原始碼交付的是成品不是專案：只拿到可執行檔或編譯後的程式，等同沒拿到。契約要寫「完整可建置的原始碼與建置說明」，並以能重新編譯佈署為驗收判準。
- 資料格式沒有說明文件：資料庫拿到了，但欄位代碼的意義沒有對照表，狀態碼 3 代表什麼只有原程式知道。資料字典要列為交付文件。
- 介接窗口屬於其他機關：本案的介接對象未必是承商能指揮的對象，換廠商時對方要重新開放來源 IP 與測試環境。清單與窗口聯絡方式要先備妥。
- 資料留在個人裝置或私人帳號：設定檔、憑證、部署腳本散在工程師的電腦或私人雲端。交接時應明確要求只以機關指定的儲存位置當交付管道，並要求刪除個人端副本並簽署確認。
把這六項反寫成招標條文，就是一份可驗收的退場條款。驗收當天的實測腳本、缺失分級與尾款訂法見科技執法系統驗收怎麼驗；那篇把移交清冊列為驗收動作之一，本文則把清冊展開成可執行的清單與判定動作。建議的做法是：初驗時就先驗一次移交清冊的完整性，不要等到三年後換約才第一次打開來看。系統交付給的是會輪調的承辦人，第一次驗不出來的東西，三年後更不會有人記得要問。
換廠商的成本要估進採購評估
交接不順的代價通常不是帳面上的費用，而是時間：重建環境、反推規格、重新申請介接權限，經常讓新承接方的前三個月無法投入任何改善工作。機關在比較是否換廠商時，這段學習與重建期應該一併估進去——這也是為什麼把退場與交接條款寫得具體，其實是保護機關自己的議價能力：交接成本越低，換約時的選擇就越多。
瑪尼國際成立於 2004 年，深耕資訊服務逾 20 年、服務逾 500 家企業，並以協力廠商身分參與全台多個縣市警察局交通隊的入案系統建置與維運。機關若正面臨換約、需要協助盤點移交範圍，或想在招標前把退場條款改寫成驗得出來的寫法，我們可以依實際系統環境提供技術說明。若專案同時包含對外宣導專區，網頁設計與後端維運的交接文件建議分列；主機與網站代管的委託關係也要一併納入移交清冊。從辨識、入案到對外平台由單一窗口負責的一條龍服務，在交接時的差別最明顯：要盤點的對象少，責任邊界也清楚。系統的完整技術規格與資安設計見智慧警政科技執法系統方案頁。
常見問題
Q：科技執法系統換廠商交接要移交哪些東西？
實務上分五類：一、程式與建置，包含原始碼、版本庫的完整歷史、編譯與佈署腳本、相依套件清單與設定檔範本；二、資料，包含資料庫結構、可還原的完整備份、歷史案件資料與影像母檔，以及各自的格式說明；三、憑證與帳號，包含伺服器與網路設備的管理帳號、資料庫帳號、憑證與金鑰、第三方服務帳號及其續約窗口；四、文件，包含系統架構圖、介接規格、資料庫綱要、操作手冊、維運手冊與已知問題清單；五、營運中的委託關係，包含網域、主機、監控與告警的收件設定。每一類都要有簽收清冊，逐項註明交付形式、份數與驗收方式。
Q：科技執法系統的交接要怎麼驗才算真的收到？
判準只有一個：新的承接方在不詢問原廠商的情況下，能不能用收到的東西把系統重建起來。具體做法是在交接期間安排一次獨立重建演練，由承接方只用移交的原始碼、備份與文件，在另一套環境把系統佈署起來、還原一份資料、跑通一條完整的案件流程，並實際送一筆資料到介接對象的測試環境。演練不通過就代表移交不完整，缺什麼當場列進缺失清單，而不是先簽收再補。帳號密碼在簽收之後應立即全部更換一次並記錄。
Q：科技執法系統交接的時程要留多久？
建議從契約到期日回推至少 90 天，分成三個階段：前 30 天盤點與清冊確認，由原廠商提出移交清冊、機關確認範圍，並釐清哪些項目其實是第三方授權或其他機關的系統；中間 30 天實際交付與重建演練，文件、原始碼、資料與帳號分批交付，承接方做獨立重建；最後 30 天並行與收尾，兩方同時在場處理日常維運，把未結案的問題、待處理的申訴與介接異常交代完畢。時程與雙方的協助義務要在招標階段就寫進退場條款，而不是等到換約前才協商。