新版網站測試正常，不代表測試完成後新增的訂單、會員、預約與內容已同步。本文用五項驗收問題，協助企業確認資料主來源、停止寫入、差異同步、對帳證據與回復邊界，避免切換後漏單、重複紀錄或回復舊站時遺失新交易。
想像公司花了幾週驗收新版網站，商品、會員與預約資料也都搬過去。正式切換後，客服卻發現前一天新增的訂單不見了，舊站剛更新的價格被新版覆蓋，部分會員又收到重複通知。這不是在描述特定案例，而是用來說明一個容易漏掉的時段：從「測試完成」到「正式切換」之間，舊站仍持續接收異動，卻沒有人說清楚最後一段資料由誰搬、何時停止、怎麼對帳。
這像搬店時先把大部分貨物送到新址，但舊店在搬家期間仍繼續收貨與出貨。第一次清點完全正確，也不能代表關門那一刻兩邊庫存一致。企業真正要驗收的，不只是搬過去多少，而是哪一本帳是準的、最後一批異動如何補上，以及切換失敗時新交易要帶回哪裡。
測試資料完整，不等於切換時仍一致
資料切換是把正式讀寫從舊系統轉到新系統的時刻。若先一次搬完全部資料，也就是全量搬遷，之後再補上新增、修改與刪除，這段補差異的做法常稱為增量同步。更自動化的方式可能使用變更資料擷取（Change Data Capture，CDC），也就是從資料庫的變更紀錄持續把異動送往新系統。
Google Cloud 的資料遷移指引把停機搬遷、持續複寫與雙邊寫入列為不同策略，選擇取決於資料變動頻率、可接受中斷與系統複雜度。AWS 也提醒，持續複寫不是即時保證，延遲會受工作量、網路與目標系統處理能力影響。因此「有同步工具」仍不能取代切換時點、落後量與對帳標準。
用五個問題驗收最後一段資料
- 每類資料的主來源是哪裡？ 訂單、會員、商品、預約、文章與檔案要逐項指定切換前後唯一可信的系統。若同一欄位可在兩邊修改，就要先定義衝突時採哪一邊、由誰判斷，不能用「最後寫入者勝出」含糊帶過。
- 何時停止舊站寫入？ 明確列出停止下單、編輯內容、匯入庫存與背景排程的時間。若營運不能暫停，就要說明哪些異動會持續同步、可容許落後多久，以及切換前如何確認待同步清單已清空。
- 第一次搬遷後的差異怎麼補？ 要涵蓋新增、修改與刪除，不只再複製一次目前看得到的資料。檔案附件、關聯資料與第三方系統回寫也要列入，避免訂單存在，明細、付款狀態或上傳文件卻缺漏。
- 用什麼證據判斷一致？ 除了總筆數，還要比較切換時段的最新時間、狀態分布、金額合計、關聯是否完整，並抽查幾條真實業務流程。AWS 的遷移驗證會逐筆比較來源與目標並回報不一致，企業採用其他工具時，也應先定義相等的驗收證據。
- 切回舊站時，新資料怎麼辦？ 若新站已收進訂單或預約，單純把網址指回舊站會讓舊資料庫落後。回復條件、決策人、停止新站寫入、反向帶回或人工補登方式，都要在上線前決定。
明顯警訊包括：切換清單只有網域名稱系統（DNS），也就是把網址導向網站的設定，或只列出網址變更；兩邊同時可編輯卻沒有衝突規則；廠商只提供總筆數；回復方案只寫「切回舊版」；以及上線後立即刪除舊環境，沒有保留受控的查核期。
停寫、持續同步與雙邊寫入各有代價
預算與技術條件有限時，短暫停止寫入通常最容易驗證。企業先公告維護時段，停用下單或編輯，補完最後差異，再對帳與切換。代價是營運會暫停，適合可接受短時間中斷、資料量與流程較單純的網站。
持續同步能縮短停止時間，但需要監測延遲、處理失敗紀錄，並證明最後異動已套用。雙邊寫入讓新舊系統同時接收更新，對使用者影響可能更小，卻會增加衝突、重複與回復設計的成本。便宜方案若只做一次資料匯入，省下的通常正是最後差異、切換對帳與失敗回復，不一定適合仍持續交易的網站。
今天先畫出一條切換時間線
先選最不能遺失的一類資料，例如訂單，從上次完整搬遷開始，標出舊站最後可寫入時間、差異同步開始與完成、對帳、切換、第一筆新站交易及可回復截止點。每個節點寫上負責人、可接受條件與證據位置。
接著用去除真實個資的測試資料演練三種情境：切換前新增一筆、同步途中修改一筆、切換後取消一筆。檢查新舊系統、通知、庫存與報表是否得到預期結果。一次成功搬完歷史資料，不能代替這些跨時點測試。
自行處理的邊界與接洽準備
純形象網站、更新可暫停且沒有會員與交易時，企業可自行設定內容凍結時間、匯出清單與人工抽查。若網站涉及訂單、付款、預約、庫存、會員、檔案，或多個系統會回寫同一筆資料，就需要網站、資料庫、營運與第三方廠商共同設計同步、對帳與回復，並在測試環境演練。
接洽前可準備資料類型與筆數、每日異動量、不能中斷的流程、舊新系統管理權限、第三方串接、預計切換時段、可接受的資料落後與回復條件。邊境部署可以協助把搬站計畫拆成主來源、時間線、差異同步、驗收證據與責任人；若短暫停寫已足夠，也不必為了看起來不中斷而導入更複雜的雙邊同步。