.NET 舊系統接手維護：上線前必做的七項檢核

這篇文章適合誰

• IT 主管／採購：評估是否由原廠轉第三方維護，需要可驗收的接手範圍。
• 開發／維運：即將接手 ASP.NET MVC、Web Forms 或早期 ASP.NET Core 專案的工程師。

問題背景

「接手維護」常被報價成「每月 N 小時修 bug」。實務上，前 30 天決定後續 12 個月成本：若沒有釐清部署、設定、排程與資料流，小改動也可能觸發連鎖故障。我們在多個 .NET 專案中常見的接手風險包括：

• web.config / appsettings 與正式環境不一致，本機正常、上線異常
• Windows 工作排程或背景服務只有口頭交接
• 資料庫預存程序與應用程式版本不同步
• 日誌分散於本機文字檔，出問題無法還原時間軸

決策者摘要：接手合約應含「現況盤點交付物」，而非直接進入功能開發；盤點完成再談 SLA 較合理。

檢核一：原始碼與執行中版本是否一致

決策者關注： 買到的是「能編譯的 zip」還是「正在跑的版本」？

技術清單：

• 比對組件版本、Git tag（若有）、正式機 DLL 時間戳
• 記錄 Framework / .NET 版本、IIS 應用程式集區設定
• 列出 NuGet 套件與是否有已知 CVE

檢核二：設定與密鑰盤點

決策者關注： 連線字串、API 金鑰是否可移交且可輪替。

技術清單：

• 連線字串、SMTP、外部 API endpoint 集中列表
• 區分 Development / Staging / Production 設定來源（web.config transform、環境變數、Azure App Settings）
• 標記硬編碼在程式內的密鑰——優先列為重構項

檢核三：部署與回滾路徑

決策者關注： 發布失敗時，多久能回到上一版？

技術清單：

• 繪製部署流程：建置 → 發布 → 檔案替換 / 容器映像
• 確認是否有資料庫 migration 腳本與執行順序
• 至少保留一次「可回滾」的正式機備份驗證紀錄

相關實績：銀行對帳單 BAI2 轉檔

檢核四：背景工作與排程

決策者關注： 半夜沒跑完的 job，早上誰發現？

技術清單：

• 列出 Windows Task Scheduler、Hangfire、Windows Service、Azure WebJob 等
• 記錄 cron 或觸發條件、執行帳號、失敗是否重試
• 確認測試環境能否安全觸發（或需 mock 外部系統）

相關實績：民間團體補助公示

檢核五：觀測與日誌

決策者關注： 客訴進來時，能否在 15 分鐘內定位錯誤請求。

技術清單：

• 應用程式日誌路徑、保留天數、是否集中（Application Insights、ELK 等）
• HTTP 錯誤頁是否洩漏堆疊至外網
• 關鍵交易（匯入、上傳、產檔）是否有 correlation id

檢核六：資料流與整合點

決策者關注： 改一個欄位會影響哪些下游？

技術清單：

• 輸入／輸出檔案格式、編碼（Big5 / UTF-8）、SFTP 或 API 介接
• 手動操作步驟（「把檔案放到某資料夾」）是否為隱性依賴
• 繪製整合圖：內部系統 ↔ 本系統 ↔ 外部機關或銀行

檢核七：權限與帳號生命週期

決策者關注： 人員離職後，舊帳號是否仍能登入或跑 batch。

技術清單：

• 登入機制：表單、AD、SSO、JWT
• 角色與功能對照表；是否存在萬用管理員帳號
• 服務帳號密碼到期日與輪替流程

接手後的第一個月建議節奏

週次	重點
第 1 週	完成檢核一～三，建立唯讀正式環境觀測
第 2 週	完成檢核四～五，補齊排程與日誌文件
第 3 週	完成檢核六～七，畫出整合與權限圖
第 4 週	選一項低風險改善（日誌、告警、小 bug）驗證發布流程

下一步

若貴單位即將接手 .NET 舊案，建議在合約中明列盤點交付物（設定表、排程表、整合圖）再進入維護工時。我們在銀行轉檔、補助 API 與企業後台有多起接手經驗——歡迎透過網站聯絡，討論現況評估範圍。