先畫出執行期相依，而不只閱讀套件清單
評估容器化時，第一步不應只是檢查程式使用哪些函式庫。套件清單只能反映建置相依，真正影響移轉的是執行期關係：應用程式會連到哪些資料庫、檔案伺服器、ERP 或 CRM API，是否透過固定 IP 存取舊系統，以及是否依賴網域帳號、憑證、硬體金鑰、印表機或內部 DNS。這些關係若沒有被記錄，程式即使成功啟動，也可能只在特定交易或批次工作執行時才失敗。
工程團隊可以從設定檔、環境變數、連線紀錄、排程設定與網路流量交叉盤點，再請實際維運人員補充例外流程。每個相依都應標示擁有者、連線方式、逾時與重試規則、憑證更新方式，以及對方不可用時的系統行為。若外部服務沒有健康檢查或穩定的介面契約，容器化之前可能要先建立轉接層，否則只是把原本隱性的耦合搬到新的執行環境。
- 建置相依：作業系統套件、執行環境版本、字型、原生函式庫與編譯工具。
- 服務相依：資料庫、訊息佇列、身分驗證、郵件、第三方 API 與企業內部系統。
- 基礎設施相依：DNS、固定 IP、防火牆白名單、憑證、共享儲存與特定時區。
- 操作相依：人工上傳檔案、桌面捷徑、遠端登入修檔、排程器與交接中的非正式步驟。
把狀態分類，再決定應留在容器內還是移出去
容器通常被視為可替換的運算單元，因此不能假設同一個檔案系統、主機名稱或執行個體會一直存在。盤點時要區分權威資料、暫存資料與可重建資料。資料庫紀錄、使用者上傳內容、尚未處理的訊息與稽核紀錄通常必須持久保存；快取、縮圖與編譯產物可能可以重建；工作目錄則要確認中斷後是否需要接續。分類的目的不是把所有資料都接到永久磁碟，而是讓每種資料都有明確的生命週期與恢復方式。
若應用程式把 session、上傳檔案或排程進度寫在本機，擴展成多個容器後便可能出現使用者被登出、檔案只存在某個副本，或同一工作被重複執行。常見做法是把 session 移到共享儲存或外部服務，把檔案放進物件儲存，並以資料庫或訊息系統保存工作狀態。不過外移也會增加網路延遲、服務成本與故障面，因此應依一致性、存取頻率、資料量、復原目標與法規要求選擇，而不是一律採用同一種儲存方案。
- 必須保存：交易資料、設定版本、上傳原檔、未完成工作、稽核與法遵紀錄。
- 可短暫保存：session、鎖定資訊、佇列消費位置與可容忍遺失的暫存結果。
- 可重新產生：快取、索引副本、縮圖、報表中間檔與部署時產生的資產。
- 不應存放：硬編碼密碼、長期金鑰，以及被打包進映像或日誌的敏感資料。
驗證啟停、併發與失敗後的行為
許多舊系統是假設單一主機、單一程序與固定啟動順序而設計。進入容器平台後，服務可能被重新排程、快速重啟或同時執行多個副本。需要確認啟動程序能否重複執行，資料庫 migration 是否只會執行一次，背景排程是否具備領導者選舉或分散式鎖，以及交易、訊息處理與 webhook 是否具有冪等性。只靠延長啟動等待時間，通常無法解決相依服務尚未就緒或偶發網路中斷的問題。
關閉行為也同樣重要。容器收到終止訊號後，應停止接受新工作、完成或安全交還進行中的任務、關閉連線，並在平台允許的時間內退出。健康檢查要分清程序仍活著、服務已可接受流量，以及服務是否暫時不應接收流量。若所有檢查都只是呼叫同一個網址，資料庫緩慢時可能觸發大量重啟，反而擴大故障。
測試不應只證明映像能在開發機啟動。應刻意終止容器、切斷外部服務、讓請求執行到一半再重啟，並同時啟動多個副本。觀察是否遺失資料、重複扣款、重送通知或留下無法釋放的鎖。這類故障演練會直接揭露容器化前必須修正的假設。
用可恢復性決定移轉順序與責任邊界
完成盤點後，不必一次容器化所有元件。無狀態 API、前端服務與可重跑的背景工作通常較適合作為第一批；依賴本機檔案、專用硬體、舊版資料庫驅動或人工操作的元件，可能需要先重構、保留在既有環境，或透過穩定介面逐步隔離。判斷標準應是故障後能否預測、重建與恢復，而不是映像是否成功建立。
每個服務在移轉前都應有映像版本策略、設定與密鑰管理方式、備份及還原程序、日誌與指標、容量基準，以及明確的回復路徑。資料 migration 更要與應用部署分開規劃，確認新舊版本能否短暫共存，避免程式回復後卻無法讀取已變更的資料結構。最後，請應用、平台、資安與業務維運共同確認責任邊界；容器平台能改善交付一致性，但不會自動補上模糊的資料擁有權與復原流程。若系統跨越 LINE、ERP、CRM、雲端與內部網路，由整合團隊共同完成相依圖與故障演練，通常比直接選定平台更能降低改造風險。