平台遷移最危險的時刻，往往出現在新站已能下單、團隊以為工作完成之後。匯入程式沒有報錯，幾天後卻發現會員點數沒對上、廣告事件重複計算，或舊文章全部導向首頁。每一項都能修，但修復成本已經從測試環境搬到真實顧客身上。
一份可執行的 Shopify Plus 遷移清單，應該為每類資料寫清楚來源、目標欄位、轉換規則、驗收方式與負責人。上線日期只是最後一格，不是計畫的起點。
商品與訂單要用什麼數字驗收？
商品不能只比對總筆數。還要檢查變體、SKU、價格、稅別、重量、庫存位置、圖片、上下架狀態與商品關聯。總數相同，仍可能有兩個變體被合併，或某個市場價格少了一位小數。
驗收可以分兩層。全量比對用腳本檢查筆數、唯一鍵、空值與金額總和；人工抽樣則挑高營收商品、多規格商品、缺貨品、組合品及不同稅別。只做其中一層都不夠：腳本看不懂圖片順序是否合理，人工也不可能逐筆檢查幾萬個 SKU。
歷史訂單是否全部匯入，要根據客服、退換貨、財務與法務需求決定。有些資料留在可查詢的封存系統更合理。關鍵是上線後的客服能找到舊訂單，而且團隊知道哪一天以前的資料要去哪裡查。
會員、點數與密碼要分開處理
會員電子郵件匯入成功，不等於會員遷移完成。分級、標籤、同意狀態、地址、點數、購物金、生日與訂閱偏好可能分散在不同系統，也有各自的隱私與使用限制。
密碼通常不能直接從舊平台搬到新平台，因為系統不持有可匯出的明文密碼，雜湊方式也可能不同。上線前要設計帳號啟用或重設流程，並測試通知信、失效時間與客服處理方式。不要等第一批會員登入失敗才寫說明。
點數與購物金需要凍結時間。先定義舊站何時停止異動、最後一批差異怎麼補，再讓財務或會員營運簽認總額。只比對人數，可能漏掉少數高餘額會員；只比總額，也可能把金額放到錯的人身上。
SEO 遷移不能保證完全沒有波動
Google 的 站點搬遷指南建議先建立舊網址到新網址的對照，再使用永久伺服器端轉址。對照應盡量一對一：舊商品導向對應商品，舊分類導向最接近的新分類。把所有失效頁面送到首頁，對使用者和搜尋引擎都沒有提供等價內容。
301、canonical、sitemap、robots 與內部連結都正確，可以降低風險，卻不能承諾排名完全不動。網站架構、內容、效能與網域若同時改變，搜尋系統需要重新抓取與評估。遷移計畫應先保存舊站的 URL、流量、排名與反向連結資料，切換後才能分辨正常波動與真正遺漏。
內容頁也要納入轉址表。部落格與教學文章可能不是直接交易頁，卻承接搜尋流量與外部連結。需要逐頁盤點時，可對照 Headless CMS 遷移服務，並依來源平台查看 Magento 遷移或 SHOPLINE／91APP 遷移的差異。
分析與廣告追蹤同樣是遷移資產。GA4 的 view_item、add_to_cart、begin_checkout、purchase 事件名稱即使保留，參數、幣別或觸發時機仍可能改變。切換前先保存測試訂單的事件序列，切換後用相同情境比對；purchase 重複送出會把營收灌高，漏送則會讓廣告系統失去回傳訊號。
同意管理也要一起測。Cookie banner、Consent Mode、Meta Pixel 與其他廣告標籤的載入順序，不能因換平台就回到預設開啟。這部分牽涉法遵與投放資料，應由行銷、技術與負責隱私的人共同簽認。
上線前至少演練一次完整切換
正式遷移前，用接近正式資料量的版本跑完整流程：匯出、轉換、匯入、驗收、凍結增量、切換網域，再模擬回滾。只用十筆測試商品通過，無法證明大量資料、API 限速與長時間執行不會出問題。
切換清單應包含 DNS TTL、憑證、付款、物流、稅務、通知信、分析事件、廣告像素、客服入口與監控。每一項要有通過條件及負責人。發現付款失敗率或錯誤率超過門檻時，由誰決定暫停，回滾要花多久，也要在上線前寫好。
遷移報價前，先取得自己的資料地圖
資料量只是成本的一部分。客製欄位、會員權益、第三方整合、網址變更比例與可接受停機時間，都會改變工期。沒有完成盤點就給出的固定報價，通常只是把未知風險藏到變更單。
先列出系統、資料擁有者、數量、相依服務與驗收責任，再談技術方案。需要把這些項目整理成可估算的遷移地圖，可以從免費遷移評估開始；若還在比較平台與服務範圍，也可查看 Shopify Plus 代理商服務。