先定義整合邊界，不要先選工具
面對沒有 API 的舊系統，工程團隊最先問的通常不該是「能不能抓到資料」，而是「哪些動作可以安全失敗」。讀取產品主檔與寫入出貨狀態，風險完全不同；每日批次同步與即時交易，也需要不同的可靠性設計。應先盤點資料來源、更新頻率、資料擁有者、允許的延遲，以及錯誤發生後由誰判斷與修復。
另一個重要原則，是把舊系統視為受保護的系統邊界。即使能取得資料庫帳號，也不等於整合程式應直接操作正式資料表。舊系統常把商業規則藏在畫面流程、觸發器、批次程式或特定欄位組合中，繞過它們寫入資料，可能產生表面成功、實際不一致的紀錄。整合設計應優先選擇唯讀、非同步、可重送的方式，只有在業務確實需要時才逐步增加寫入能力。
依風險選擇整合模式
沒有單一模式適合所有舊系統。實務上可把方案依侵入性與即時性排列，從最容易隔離的資料交換開始，再評估是否需要更深層的連接：
- 唯讀資料庫檢視：由舊系統管理者建立限定欄位的 view、stored procedure 或唯讀副本，整合服務只能查詢必要資料。這種方式速度快、結構清楚，但必須控制查詢負載，並避免依賴未承諾穩定的內部表結構。
- 檔案交換：透過 SFTP 或受控儲存區交換 CSV、XML、JSON 等檔案。它不追求即時，卻容易隔離、重送與人工檢查，特別適合主檔、對帳與每日批次。重點是定義檔名、版本、編碼、完成標記與重複檔案處理規則。
- 資料異動擷取：若資料庫支援交易日誌或變更記錄，可使用 CDC 將異動送到訊息佇列或中介資料庫。它能降低輪詢壓力，但仍需處理事件順序、刪除紀錄、結構變更與重新同步。
- 受控資料庫寫入：只有在原廠或系統負責人確認寫入規則後，才透過專用 stored procedure、暫存表或匯入佇列寫入。整合程式不應直接更新核心交易表，也不應共用管理者帳號。
- 畫面自動化：RPA 或瀏覽器自動化可重現人員操作，適合低頻、短期且缺乏其他入口的流程。然而畫面改版、彈出視窗與登入機制都可能使流程失效，因此應視為最後手段，並保留人工接手方式。
選型時可用四個問題快速篩選：資料需要多即時、寫錯是否可逆、舊系統能承受多少額外負載，以及介面變更能否提前通知。若需求只是隔日報表，就不必承擔即時 CDC 的維運成本；若是庫存承諾或付款狀態，則不能只靠缺乏確認機制的檔案搬運。
用中介層隔離舊系統的不確定性
不論採用哪種入口，都建議建立獨立的整合服務或 anti-corruption layer。它負責把舊系統欄位轉換成穩定的企業資料模型，驗證必填值與格式，並對外提供一致的 API 或事件。下游系統不直接理解舊資料表、特殊代碼或畫面操作細節；未來更換舊系統時，需要調整的範圍也會較小。
中介層還必須處理「至少一次」傳遞帶來的重複問題。每筆工作應有穩定的業務鍵或 idempotency key，寫入前檢查是否已處理，並保存來源版本與處理狀態。失敗項目應進入可查詢的重試佇列，而不是無限重跑。對於跨系統交易，不要假設能使用同一個資料庫交易；較可靠的方式是記錄各步驟狀態、允許補償操作，並定期以對帳程序找出遺漏、重複或狀態衝突。
安全控制也應落在架構中，而非只寫在文件裡。使用專用服務帳號與最小權限、將憑證放入祕密管理服務、限制來源網段與連線時段，並對敏感欄位做遮罩或加密。所有讀取、轉換、寫入與人工修正都應留下可追溯紀錄，但日誌不應直接保存密碼、權杖或完整個資。
把可停止、可驗證、可演進當成上線條件
正式切換前，先以唯讀影子模式執行，確認資料量、延遲與轉換結果，再小範圍開放寫入。寫入流程應具備速率限制、逾時、斷路器與 kill switch；當舊系統變慢或輸出異常時，整合服務要能暫停，而不是持續放大故障。監控除了成功率，也要觀察待處理佇列、最舊工作時間、來源與目的筆數差異，以及資料驗證失敗原因。
同時要把 schema drift 當成必然事件。針對欄位新增、型別改變、代碼表更新與檔案格式變更建立契約測試，並保留可重播的去識別化樣本。每次變更都應有相容期、回復方式與負責窗口。若某個畫面自動化流程長期承擔核心交易，或資料庫寫入規則已複雜到難以驗證，這通常就是投資正式 API、事件介面或模組替換的訊號。
安全整合的目標不是把所有舊系統立即現代化，而是建立一條風險可控的演進路徑：先隔離、再觀察，從唯讀走向受控寫入，最後逐步替換脆弱介面。若內部缺少舊系統知識、資安治理或跨系統維運能力，可由具備整合經驗的團隊協助完成盤點與邊界設計，但資料權責與失敗處置仍應由企業共同確認。