01
先說清楚商業改變
如果新平台只被描述成技術替換，團隊很難判斷哪些流程值得重建。
來源決策對照
Magento01
WooCommerce02
SHOPLINE / 91APP03
資料語意
體驗邊界
營運責任
目的地
下一階段營運模型
02
先畫出不能失去的東西
資料、搜尋入口、會員權益與關鍵整合，都需要可檢查的保留條件。
03
先指定切換後的主人
誰管理內容、促銷、商品、整合與異常，會直接改變最適合的架構。
引導式決策
用兩個選擇，找到第一份該讀的遷移路徑
這不是自動報價，也不會替代系統盤點。它只幫你把來源平台與第一優先對齊，產出一份可帶進內部會議的起點。
0 / 2 已完成
先定範圍，再選平台
你要的是搬遷、重構，還是換一套營運方式？
三種範圍都可能合理，但它們需要不同的決策人、證據與驗收方式。先講清楚，才能避免提案看似同名、實際上完全不同。
A搬遷
保留主要營運模型
核心流程大致不變，重點是資料、網址、權益與必要功能在新平台中能被驗證。
決策問題
哪些舊行為是真的必要，而不是歷史習慣？
帶上：現況流程、欄位樣本、網址清單、必要功能擁有者
B重構
重新設計體驗與系統邊界
趁遷移調整前台、內容與整合責任，但保留既有商業模式與多數資料關係。
決策問題
哪些限制來自平台，哪些其實來自內部流程？
帶上：關鍵旅程、內容治理、系統責任圖、優先順序
C轉型
定義新的市場與營運模型
多市場、B2B、門市、會員或內容組織都要改變，平台只是承接新模型的一部分。
決策問題
新模式需要誰做出現在做不到的決策？
帶上：市場模型、權限、商品與價格規則、跨團隊決策方式
依來源平台分流
同樣叫遷移，三個來源平台的第一個難題不同
不要用同一份需求書套進所有平台。先看常見觸發、探索焦點與切換前的證據，再進入來源平台專頁。
| 來源平台 | 常見觸發 | 探索焦點 | 切換前要看到的證據 | 下一步 |
|---|---|---|---|---|
| Magento / Adobe Commerce | 升級、基礎設施與客製模組的治理，持續佔用技術與營運決策。 | 客製商務規則、商品模型、ERP／PIM／OMS 介面，以及仍有價值的歷史資料。 | 關鍵規則在新架構中的對照、整合失敗時的處理方式，以及可回復的切換邊界。 | 查看路徑 |
| WooCommerce | 外掛、主機與內容／商店邊界逐漸難以治理，改一處常牽動另一處。 | 外掛依賴、內容與網址結構、訂閱或會員流程，以及目前會影響營運的自訂功能。 | 內容與商店的責任邊界、舊網址對照、外掛替代方案，以及付款憑證等外部資料的可攜性。 | 查看路徑 |
| SHOPLINE / 91APP | 品牌體驗、資料運用或跨市場營運需求，開始超出既有方案的可控範圍。 | 來源資料可得性、會員身分與權益、POS／LINE／CRM 關係，以及台灣與海外流程的分工。 | 小批量匯出樣本、會員權益對照、門市與線上身分合併規則，以及各服務商的帳戶與合約條件。 | 查看路徑 |
遷移風險登錄表
資料表之外，還要搬移商務規則與營運責任
欄位匯入成功只是技術事件；能否繼續營運，取決於資料語意、身分、入口、整合與回復機制是否被共同驗證。
01資料語意
同名欄位，在兩個平台裡真的是同一件事嗎？
商品狀態、價格、庫存、訂單與標籤常帶著來源平台規則。先用例外案例建立對照與轉換原則，避免只比筆數。
驗收門檻：關鍵案例能在新系統被同樣理解與操作。
02顧客身分與權益
顧客切換後，如何登入並找回該有的權益？
登入憑證、同意紀錄、會員分級、點數與購物金可能由不同服務持有。需要逐項確認可攜性、替代流程與溝通方式。
驗收門檻：身分恢復與權益差異都有清楚處理路徑。
03搜尋與內容入口
舊網址、索引與內容價值如何延續？
先建立網址與內容去留清單，再處理重新導向、內部連結、結構化資料與監測。不要等到切換前才補 SEO。
驗收門檻：高價值入口有新目的地、責任人與監測方式。
04整合與異常
當同步失敗時，誰會知道，誰能補救？
整合規格除了成功路徑，也要寫入重試、重複資料、順序衝突、人工介入與服務商責任。
驗收門檻：關鍵失敗情境已演練，且能追蹤到負責人。
05切換與回復
什麼條件下繼續切換，什麼條件下回復？
資料凍結、增量同步、DNS、付款、客服與舊站保留方式需要同一張指揮圖，並由商業與技術共同做決定。
驗收門檻：放行與回復條件在上線前已被同意。
以證據推進交付
每一階段都要產出下一個決策所需的證據
不先承諾一個漂亮時程；先把未知變成可檢查的成果，讓範圍、風險與切換條件逐步收斂。
- 01
界定改變
把商業目標、現況限制與不在這次處理的範圍寫清楚。
輸出：決策簡報、範圍邊界、責任人
- 02
建立對照
用真實資料、旅程與整合案例驗證新舊模型的差異。
輸出：資料對照、網址地圖、系統責任圖
- 03
演練例外
先測錯誤、邊界與失敗處理，再把成功案例擴大。
輸出：驗收紀錄、差異清單、復原方案
- 04
受控切換
依放行條件完成最終同步、流量切換與營運交接。
輸出：切換指揮圖、監測與後續待辦
提案前先回答的問題
在看平台或提案之前，先問這些問題
01一定要先決定 Shopify Plus，才能做遷移評估嗎？
不用。先確認新營運模型、平台必須承接的能力與不能接受的風險，再判斷 Shopify、Shopify Plus、Headless 或其他架構是否合理。評估的價值就在於把選擇條件說清楚。
02商品、會員與訂單可以完整搬移嗎？
不能只用「完整」兩個字判斷。來源匯出能力、資料品質、登入憑證、外部服務與新平台資料模型都會影響結果。好的盤點會逐類定義保留、轉換、封存與無法直接搬移的處理方式。
03遷移一定要同時重新設計網站嗎？
不一定。可以保留主要體驗、分階段重構，或趁平台更換重新定義整體旅程。關鍵是不要把三種範圍混在同一份估算裡，並為每一階段設定可驗收的邊界。
04比較遷移提案時，最值得看什麼？
看對方如何處理未知與例外：是否要求真實資料樣本、是否說明來源限制、是否能畫出整合責任、是否有 SEO 與會員身分方案，以及放行與回復條件是否清楚。
帶上實際系統圖
先把真實邊界帶上桌，再談新平台。
準備來源平台、關鍵整合、會員／訂單規則與最不能中斷的營運流程，我們可以從一場遷移盤點開始。