從舊會員中心搬到 Shopify New Customer Accounts，功能如何分階段遷移？

前言

舊會員中心不是只有登入頁。案例裡同時存在 Theme customer templates、舊站會員與訂單資料、客服查詢流程，以及準備掛到新版 Customer Accounts 的 Service Center blocks。

上一篇 說明 extension-only 的能力邊界。真正遷移時，最危險的做法是把「切換 Customer Accounts 設定」當成全部完成；Shopify 可以 redirect 多數舊連結，卻不會替你搬移 Liquid 客製、外部歷史資料或營運工作流。

原本的做法與問題症狀

第一個方案是 Big Bang：

1. 匯入舊會員與訂單。
2. 開啟新版 Customer Accounts。
3. 把舊會員頁導向新頁。
4. 假設顧客看得到所有歷史資訊。

這會把四種不同問題壓在同一天：

• 登入從 email＋password／activation 改成 email one-time code。
• Legacy Liquid templates 不再負責 account pages。
• Shopify 原生 orders 與外部歷史 orders 不是同一個資料來源。
• 客服需要先能查資料，顧客端 UI 才能安全開放。

另一個方向是為了保留每個舊畫面，逐像素重做。新版 Customer Accounts 本身已提供 profile、addresses、orders 與 order status；全部重做不只成本高，也可能和平台原生功能衝突。

問題是怎麼推敲出來的？

案例 source 出現三組證據：

1. 舊 Theme 還有 classic customer account templates。
2. App config 定義 legacy order 與 customer summary 的 app-owned metaobjects。
3. Admin App Home 已有 legacy lookup，但 Customer Account blocks 仍只是服務入口。

Lookup 流程會：

輸入 email
  → 找 customer summary
  → 取關聯的歷史 order handles
  → 最多展開前 50 筆

輸入 order number
  → 直接找單筆歷史 order

沒有精確命中
  → display-name query

這證明資料查詢模型與管理員 UI 已存在，卻沒有證明顧客登入後能看到 legacy orders。Service Center 沒有呼叫 lookup model，資料 access、identity match、顧客授權與空值體驗都還沒完成。

現行 Shopify 文件又增加一個時間邊界：自 2026-02-26 起，legacy customer accounts 已 deprecated；新店無法使用，既有但未使用的商店也無法再取得，商家必須往新版遷移。這使 phased migration 更重要，而不是更適合一次切換。

最後採用的架構

遷移分成六個 gate：

1. Inventory
   登入、Liquid、Apps、資料、redirect、營運流程

2. Preserve
   保存必要歷史資料
   先提供 admin-only lookup

3. Rebuild
   原生 Customer Accounts 負責 profile / orders
   UI Extensions 補必要 gap

4. Pilot
   測試 accounts、fixtures、support fallback

5. Cutover
   發布 account configuration
   監控登入、redirect、查詢與客服

6. Retire
   停止舊寫入
   依 retention / privacy policy 清理

每個舊功能先分類：

舊功能	新責任
登入、profile、addresses	Shopify Customer Accounts
Shopify orders／status	原生 order pages
額外服務入口	Customer Account UI Extension
外部歷史 order lookup	受控 legacy data service
管理員查詢與修復	Admin App Home
舊 Liquid account template	退場，不直接搬到新版 DOM

關鍵實作

Legacy schema 不要直接保存原始整包資料。先定義最小可查、可刪除的欄位：

type LegacyOrderSummary = {
  lookupHandle: string;
  externalOrderReference: string;
  placedAt: string;
  status: string;
  currency: string;
  total: string;
};

Email 不應直接變成公開 handle，可以先 normalize 再做 deterministic safe handle；真正顧客端查詢還要把登入 customer identity 和 legacy record 綁定，不能讓使用者任意輸入另一個 email。

const identity = await getAuthenticatedCustomer();
const legacySummary = await findLegacySummary({
  customerId: identity.id,
});

管理員 lookup 可以保留 email／order search，因為它在受控 admin authorization 內；顧客端要採 identity-bound query，只回最少欄位，並記錄資料 retention、redaction 與 support escalation。

實際驗證

2026-07-30 能由 source 證明：

• App 有 legacy customer summary 與 legacy order 的結構化定義。
• Admin lookup 有 exact customer、exact order、fallback query、loading、empty 與 error paths。
• Customer summary 會關聯有限數量的 order handles，避免無上限展開。
• Customer Account Service Center 和 Admin legacy lookup 是分離的 surfaces。
• Customer Account blocks 沒有呼叫 legacy lookup。
• 來源有 migration artifacts，但本次沒有讀取、統計或公開任何真實會員／訂單內容。

官方文件查核確認：

• Customer Account UI Extensions 只支援新版 Customer Accounts。
• Legacy Liquid／app customizations 不會自動帶到新版，要用 apps／blocks 重建。
• 新版使用 email one-time code，不支援舊 password 模型。
• 多數 legacy links 會 redirect，但 workflow 與 data migration 仍需自行處理。
• Customer Account UI Extensions 本身不是 Plus-only；Branding API、自訂 identity provider、B2B、saved payment methods 與 market overrides 要分別看 plan requirement。

本次沒有做 store setting cutover、test customer login、legacy identity match、顧客端歷史訂單顯示、redirect crawl 或 rollback drill。

仍然存在的限制

第一，管理員查得到資料不代表顧客有權看到。顧客端 lookup 必須以 authenticated identity 綁定，處理 email 變更、合併 customer profiles、重複 email 與資料更正。

第二，metaobject schema 裡若保存 email、phone、訂單與付款摘要，就進入 protected customer data、retention 與 privacy deletion 範圍。不能因為資料在 Shopify 裡就省略 data inventory。

第三，來源 lookup 依 customer summary 展開前 50 筆 orders。這是明確上限，但超過上限的 pagination／客服 fallback 尚未實作。

第四，legacy order 不會自動變成 Shopify Order。若只需要查詢，保留 summary 可能合理；若要 returns、reorder、invoice 或 warranty action，就要逐功能設計，不要偽造 Shopify native order state。

第五，切換後的登入體驗改成 one-time code。舊的 password reset、account invite、activation Email、Flow trigger 與客服話術都需要 inventory；redirect 成功抓不到這些營運缺口。

第六，Plus 限制不能用一個總結代替。Customer Account extensions 可在非 Plus 使用，但自訂 identity provider、進階 branding、B2B 與其他能力各有自己的方案條件，而且可能更新。

最後，Shopify 已將 legacy accounts deprecated，不代表可以立即刪除歷史資料。退場日期要同時滿足客服、財務、法規、商家政策與 customer access request。

可以延伸到哪些情境？

這套 phased migration 適合 WordPress／WooCommerce 會員中心、ERP 客戶入口與自建售後平台：

先盤點行為
  → 再保存最小資料
  → 先讓內部可支援
  → 再開顧客端能力
  → 最後切流量與退舊系統

遷移成功的定義不是「新登入頁打得開」，而是每個舊能力都有明確去向、每個資料集都有 owner、顧客與客服都有 fallback，而且還沒完成的部分沒有被包裝成已上線。

本批三篇 Customer Account 案例到這裡完成；下一批 AI 估點文章尚未發布，因此不預先建立正式連結。

參考資料

• Shopify：Building apps for customer accounts
• Shopify Help Center：Customer accounts and legacy customer accounts
• Shopify Help Center：Setting up and managing customer accounts
• Shopify Help Center：Customization options for upgrading
• Shopify Help Center：Customizing customer accounts
• Shopify：Customer account UI extensions

以上平台文件查核日期：2026-07-30。