先盤點業務依賴，不只列出技術介面
ERP 周邊通常同時存在 API、批次檔案、資料庫查詢、訊息佇列、排程程式，以及由人員手動匯入的流程。若只整理端點與欄位，很容易漏掉真正的營運依賴。例如訂單建立成功後，可能還要觸發信用檢查、庫存保留、出貨通知與財務過帳；其中任何一步延遲，都可能形成表面成功、實際未完成的交易。因此，盤點單位應是完整業務流程，而不是單一程式。
我們通常會為每條整合記錄資料方向、觸發方式、負責團隊、資料來源、允許延遲、失敗後果、重送方法與稽核需求，再依業務影響決定遷移順序。這也能提早找出沒有正式負責人、直接寫入 ERP 資料庫，或只能由特定人員手動補救的高風險介面。
- 不可中斷：訂單、出貨或生產等核心流程，需要預先建好替代路徑，並在切換期間持續監控。
- 可短暫延遲：通知、報表或分析資料可先進入佇列，待新 ERP 穩定後依序回補。
- 可安排暫停：低頻且可人工核對的流程，可以設定明確停機窗口與補登程序。
- 應優先退場：直接存取舊 ERP 資料表、缺乏驗證或無法追蹤來源的整合，不宜原封不動搬到新環境。
用穩定的整合邊界隔離新舊 ERP
換版期間若讓每個周邊系統分別理解新舊 ERP 的欄位、狀態碼與驗證規則，切換成本會快速擴散。較穩定的做法，是在 ERP 前方建立版本化的 API、事件或檔案契約，再由轉接器處理新舊模型差異。周邊系統只依賴穩定契約，路由則可依流程、公司別或切換階段導向舊系統、新系統，或暫存佇列。
這層邊界不應變成包辦所有欄位的巨大共通模型。只抽象出跨系統真正穩定的概念，例如訂單識別碼、客戶、品項、數量與處理狀態；ERP 特有的會計欄位或客製流程則保留在專用轉接器。呼叫端必須立即取得驗證結果時，可使用同步 API；能容忍短暫延遲的更新則適合事件或佇列。只有在舊 ERP 無法發送事件、且資料擁有者同意的情況下，才考慮以 CDC 擷取異動。
- 契約版本化：新增欄位以相容方式推出，破壞性變更另開版本，避免同一天迫使所有系統升級。
- 冪等處理：以業務鍵或事件識別碼辨識重送，避免重複建立訂單、出貨或傳票。
- 可重播佇列：保留原始訊息、處理結果與失敗原因，修正後可安全回補，不必人工重建資料。
- 禁止直接寫表：周邊系統應經由受控介面更新 ERP；否則驗證、權限與稽核規則很容易被繞過。
平行驗證的重點是結果一致，而非每個欄位相同
在正式切換前，可以將真實流量複製到新 ERP 進行影子處理，但不讓新系統對外產生出貨、通知或會計過帳等副作用。比較時不要只逐欄比對，因為新舊 ERP 可能採用不同編碼、稅額拆分或狀態生命週期。更實用的做法，是檢查業務不變條件：每張已接受訂單是否都有明細、保留量是否合理、過帳總額是否平衡，以及失敗交易是否能追溯至來源。
雙寫看似能讓兩套 ERP 同步，實際上卻會遇到一邊成功、一邊失敗的分散式交易問題。除非確實需要兩套系統同時承擔主系統責任，我們更傾向保留單一寫入來源，再透過事件、異動擷取或受控批次同步另一端。每筆同步都應保留來源識別碼、時間戳記、處理狀態與最後成功水位，並定期勾稽數量、金額與狀態。若交易不可直接撤銷，回復方案也必須定義沖銷或補償交易，而不是假設能把資料庫倒回舊版本。
把切換設計成多個可停止的小步驟
較安全的上線方式，是依業務能力分波切換，例如先切查詢，再切主檔同步，最後才切訂單與財務寫入。每一波都要有進入條件、觀察時間、停止條件與回復路徑。切換前應凍結非必要的契約與主檔變更，完成契約測試、歷史資料回放、容量測試及故障演練，並確認舊 ERP 在回復窗口內仍可接手，而不是只保留一台無法同步最新資料的主機。
上線期間的儀表板應呈現成功與失敗量、佇列積壓時間、處理延遲、重複訊息、最後同步水位及勾稽差異，並讓每個告警都有明確負責人。路由開關、停用步驟、補資料腳本與人工替代流程也應先演練。當判斷依據與操作程序都已寫清楚，團隊才能在壓力下依證據決定繼續、暫停或回復；如需外部整合團隊協助，其首要任務也應是建立這套可驗證的遷移控制面，而不是單純重接所有介面。