將 Sitecore 遷移至 Sanity CMS

企業為何離開 Sitecore

Sitecore 曾經風光一時。多年來，它一直是企業預設的 DXP — 許多需要個性化、多站點管理和內容工作流程的大型組織的安全選擇。但安全不再等於明智。

Sitecore XP 授權成本高昂。XM Cloud 試圖將堆棧現代化，但本質上仍是 Sitecore — 固執己見、臃腫且維護成本高。JSS 是走向無頭架構的一步，但它只是在單體核心上加了一層 React，而不是重新思考整個架構。您的開發人員最終除錯 Sitecore 特定的抽象層，而不是發佈功能。您的內容團隊等待開發週期才能做出應該只需幾分鐘的更改。

Sanity CMS 與此完全相反。它是一個 API 優先的結構化內容平台，專為實時協作而設計，靈活到足以建模任何內容域而無需與系統對抗。

我們曾為執行 XP、JSS 和 XM Cloud 的企業領導 Sitecore 到 Sanity 的遷移。以下是我們所知的情況。

真正重要的 Sitecore 痛點

授權和總擁有成本

Sitecore 授權根據您的層級、模組和用戶數可能每年運行 $100K–$500K+。加上 Sitecore 專業開發人員（一個萎縮、昂貴的人才庫）、託管基礎設施和保持所有內容修補和相容性的開銷。TCO 對於您實際獲得的東西來說是驚人的。

Content Hub 供應商綁定

Sitecore Content Hub 應該可以解決 DAM 和內容操作。實際上，它是另一個緊密耦合的模組，加深了您的平台依賴性。用 Sanity 的內容湖取代 Content Hub 可以為您提供單一的、可查詢的真實來源，而無需供應商綁定。

開發人員體驗是一個瓶頸

Sitecore 開發很慢。句號。構建時間冗長，本機開發環境脆弱，元件在體驗編輯器中的外觀與生產之間的差距是 bug 的持續來源。JSS 邊際改進了情況，但您仍在透過 Sitecore 的管道部署。

內容團隊摩擦

Sitecore 中的內容編輯器在嚴格的頁面範本內工作。想要在各個渠道重複使用內容塊？這需要開發人員介入。想要實時預覽更改？體驗編輯器的渲染延遲使其令人痛苦。內容團隊最終被阻止，提交工單而不是發佈。

個性化作秀

Sitecore 的個性化引擎 — xDB、xConnect — 在銷售演示中聽起來令人印象深刻。實際上，大多數組織使用它功能的一小部分，因為實施成本巨大。您為企業 DXP 價格付費卻只得到一個 CMS。

Sanity 帶來的優勢

結構化內容建模

Sanity 架構使用 TypeScript 或 JavaScript 在代碼中定義，在 Git 中版本控制，在拉取請求中審查。您以程式方式定義文檔類型、物件類型、參考和驗證。您的內容模型變成與應用代碼一樣嚴格和可移植。

Portable Text — Sanity 的富文本格式 — 將內容儲存為結構化 JSON 而不是原始 HTML。您的內容在網頁、行動裝置、電子郵件、資訊亭或任何未來渠道上正確呈現，無需轉換困擾。

GROQ 內容湖

GROQ 是 Sanity 的查詢語言。它富有表現力、速度快，專為查詢結構化內容而設計。與 GraphQL 不同，沒有 schema 拼接或解析器複雜性。您編寫 GROQ 查詢，您會獲得確切需要的資料形狀。內容湖是實時的、全球分散的資料儲存 — 不是一個附加到 CMS 的資料庫。

實時協作

多個編輯可以同時處理同一文檔。更改立即出現。沒有簽入/簽出鎖定，沒有合併衝突，沒有遺失的工作。Sanity Studio 顯示狀態指示器，讓您的團隊知道誰在編輯什麼。想想 Google Docs 級別的協作，但用於您的 CMS。

Sanity Studio：您的自訂 CMS

Sanity Studio 是一個開源的、基於 React 的編輯環境，您可以擁有並自訂它。需要用於 SEO 評分的自訂小工具？構建它。需要用於編輯批准的工作流程外掛？構建它或安裝一個。Studio 作為代碼庫的一部分部署 — 不是託管在 Sanity 的基礎設施上 — 這意味著完全控制。

MACH 可組合架構

Sanity 適配進 MACH 堆棧。它處理內容。您的前端（Next.js、Astro、Remix）處理呈現。您的商務平台處理交易。您的搜尋服務處理搜尋。每個服務都是最佳級別，可獨立部署，可替換。沒有單體。

我們的 Sitecore 到 Sanity 遷移流程

第一階段：發現和內容審計（2–3 週）

我們盤點您的 Sitecore 實例 — 每個範本、呈現、內容項目、媒體資產、個性化規則和工作流程。我們爬取站點以尋找 URL 結構、重定向和 SEO 中繼資料。我們將 Sitecore 的範本階層對應到 Sanity 文檔類型，並決定遷移什麼、合併什麼和削減什麼。

可交付成果：內容模型對應文檔、遷移範圍、風險評估、SEO 基準報告。

第二階段：Sanity 中的內容建模（2–3 週）

我們從頭開始設計您的 Sanity 架構。不是 Sitecore 範本的 1:1 移植 — 一個適當的結構化內容模型，針對重複使用、全通路交付和編輯效率進行優化。我們配置 Portable Text、參考結構、分類系統和本地化模式。

我們使用自訂輸入元件、預覽窗格和與 Sitecore 相匹配（並改進）的編輯工作流程設定 Sanity Studio。

第三階段：前端開發（4–8 週）

我們在 Next.js（或用於內容豐富的站點的 Astro）中構建您的前端，透過 GROQ 查詢連接到 Sanity。設定視覺編輯和即時預覽，以便編輯在實際站點上看到更改 — 不是體驗編輯器近似值。

效能是非常重要的。我們的目標是 TTFB 低於 300ms，行動設備上 Lighthouse 評分 95+。

第四階段：內容遷移和驗證（2–4 週）

我們透過 API、資料庫匯出或站點爬取從 Sitecore 提取內容 — 無論哪種方式都能給我們最乾淨的資料。自訂遷移腳本將 Sitecore 欄位轉換為 Sanity 文檔結構，將富文本轉換為 Portable Text，並將媒體資產重新對應到 Sanity 的資產管道。

遷移分階段進行 — 子集匯入、針對來源的驗證、自動奇偶性檢查。不是單一高風險的 cutover。

第五階段：SEO 保護、QA 和啟動（1–2 週）

每個 URL 都會獲得重定向對應。我們驗證規範標籤、結構化資料、Open Graph 中繼資料、XML 網站地圖和 hreflang 標籤。遷移前後的爬取確認零 SEO 回歸。

我們訓練您的內容團隊使用 Sanity Studio、記錄所有內容，並支持您完成啟動和生產的前幾周的關鍵期。

SEO 保護策略

Sitecore 遷移如果處理不當會帶來真實的 SEO 風險。我們的方法：

• 完整 URL 盤點 來自 Sitecore 網站地圖和爬取資料，與 Google Search Console 交叉參考
• 301 重定向對應 針對每個索引 URL，在邊緣實施（Vercel、Netlify 或 Cloudflare）
• 中繼資料遷移 — 標題標籤、中繼描述、OG 標籤、結構化資料全部移植並驗證
• 內部連結審計 — 每個內部連結更新以防止重定向鏈
• 啟動後監控 — Search Console 索引、Core Web Vitals 和 90 天的排名追蹤

我們已經遷移了 50K+ 頁面的站點，沒有損失有機流量。關鍵是將 SEO 視為一流的工作流，而不是事後才想到。

時間表和定價

大多數 Sitecore 到 Sanity 遷移運行 12–20 週，具體取決於內容量、站點數量、本地化複雜性和前端範圍。

| 範圍 | 時間表 | 投資 | |-------|----------|------------|| | 單一站點，<5K 頁面 | 12–14 週 | $80K–$150K | | 多站點，5K–50K 頁面 | 14–18 週 | $150K–$300K | | 企業，50K+ 頁面，多品牌 | 18–24 週 | $300K+ |

這些數字是大多數組織每年在 Sitecore 授權上花費的一小部分。遷移透過第一年內減少的授權、託管和開發成本在一年內自給自足。

我們部署的 MACH 可組合堆棧

遷移後，您的架構看起來像這樣：

• 內容：Sanity CMS（內容湖 + Studio）
• 前端：Next.js 或 Astro on Vercel/Netlify
• 搜尋：Algolia 或 Typesense
• 商務：Shopify、commercetools 或 Medusa（如適用）
• 媒體：Sanity 資產管道或 Cloudinary
• 分析：Plausible、Fathom 或 GA4

每個元件都是獨立可擴展、可替換和 API 連接的。沒有供應商綁定。沒有單體稅。