遷移 Optimizely CMS 12 至 Next.js + Supabase

為什麼企業正在離開 Optimizely CMS 12

Optimizely CMS 12—曾經是 Episerver 的 PaaS 演變版本—有過它的時刻。它將 CMS、商務和個性化整合到託管的 Azure 環境中，這在一段時間內是有效的。但現在是 2026 年：龐大的 .NET 根源、不斷升級的授權層級，以及一個共享基礎設施模型，這會造成您的工程團隊字面上無法突破的性能天花板。

我們已經將企業團隊從 Optimizely DXP 中遷移出來，他們每年僅在授權上就支付 $200K–$500K。他們需要多渠道交付、低於 300ms 的 TTFB，以及能夠招聘 React 開發人員而非 .NET 專家的能力。這個數學計算不再有效。

Optimizely DXP 的真實痛點

與您相悖的授權費用

Optimizely 的分層定價—集團、企業、企業級—按環境和 Web 應用程式收費。添加商務模組、個性化附加組件和自訂整合，您就在看六位數的年度續約費用，每個合約週期都會悄悄上升。當您的行銷團隊想要一個新微網站時，預算對話從授權開始。不是設計。授權。

內置於架構中的性能天花板

Optimizely DXP 運行在共享的 Azure PaaS 基礎設施上。您的整合、預生產和生產環境共享單一 Web 應用程式和搜尋索引。我們審計的大多數 Optimizely 網站的實際 Lighthouse 行動評分落在 45–65 之間。Optimizely 本身廣泛引用的 SCA 案例研究顯示從 43 改進到 70。這是進展，當然。但這沒有競爭力。現代無頭構建持續達到 95–100。

開發人員體驗摩擦

只有 .NET 的範本系統意味著您的前端開發人員無法使用他們實際知道的工具。每個 UI 變更都需要完整的全棧 .NET 部署週期。試著在 2026 年招聘資深 .NET CMS 開發人員—該人才庫正在萎縮，而 React/Next.js 開發人員無處不在且更便宜。

製造更多問題的遷移工具

Optimizely 自己的 CMS 11→12 升級項目遷移工具顯示了裂縫。啟動新的 Linux Docker DXP 實例、通過 Azure Storage Explorer 使用臨時 SAS 鏈接複製 blob、花費 20+ 分鐘的大型網站數據庫複本—這只是在 Optimizely 版本之間移動。想像一下沒有正確代理的完整退出是什麼樣子。

設計上的供應商鎖定

內容模型、區塊結構、頁面層級、分類法樹—全部位於專有格式中。沒有「匯出為 JSON」按鈕。您留在裡面的每一年，轉換成本都會增加。這不是偶然的。

Next.js + Supabase 的功能

目標架構是可組合堆棧：Vercel 上的 Next.js 15 用於前端，Supabase（PostgreSQL + Auth + Storage + Edge Functions）用於後端和內容層，以及 Cloudflare 用於邊緣快取和 DDoS 保護。

贏得核心網頁關鍵指標的性能

Next.js App Router 配合 ISR（增量靜態再生）在全球提供低於 300ms 的 TTFB。靜態頁面在構建時生成；動態內容按需重新驗證。Lighthouse 行動評分 95–100 是基線，而非志向。

開源經濟學

Supabase Pro 每月 $25 替代 $200K/年的 DXP 授權。Vercel 託管每個網站 $20 替代 $10K+/月的 Azure PaaS 費用。三年 TCO 從 $900K+ 降至大約 $300K，包括遷移本身。ROI 在 12 個月內轉正。

真正的無頭，不是無頭相鄰

Optimizely CMS 13 行銷無頭功能，但它仍然是 PaaS 優先，並附帶一個 API。Supabase 是 API 原生。內容的每一部分都可以通過 REST 或 GraphQL 存取，通過行級安全策略保護。您的行動應用程式、您的網頁應用程式、您的資訊亭—相同的內容 API，零額外授權。

現代開發人員工作流程

React 元件、TypeScript、基於 Git 的部署、每個 PR 的預覽環境、用於伺服器邏輯的邊緣函數。您的團隊在幾天內交付功能，而非衝刺週期。招聘管道開放給世界上最大的前端開發人員社群。

我們的遷移流程

我們的平台遷移負責人 Aryan Shah 已為保留每一部分內容、維護 SEO 權益、實現零停機時間的 Optimizely DXP 退出建立了可重複的遊戲手冊。

階段 1：深度審計（第 1–3 週）

我們映射您的整個 Optimizely 內容模型—頁面類型、區塊類型、內容區域、分類法樹、媒體資產、URL 結構和整合觸點。我們匯出完整庫存並標記需要重組的內容與映射 1:1 至 Supabase 架構的內容。

階段 2：架構設計與 ETL 管道（第 4–8 週）

自訂 Node.js ETL 指令碼從 Optimizely 的資料庫中提取內容並將其轉換為 Supabase PostgreSQL 表格。分類法層級結構通過遞迴表格結構和 RLS 策略得以保留，這些策略鏡像您現有的 RBAC 許可。媒體資產從 Azure Blob Storage 遷移到 Supabase Storage。我們已使用平行上傳管道在一小時內處理 50K+ 資產的目錄。

階段 3：前端構建（第 6–14 週）

Next.js 15 App Router 前端，針對您現有的設計系統逐個元件構建。我們不只是複製—我們優化。每個 Optimizely 區塊類型都成為 React 伺服器元件。導航、搜尋和篩選移至 Supabase Edge Functions，用專用的快速基礎設施替代 Optimizely 的共享搜尋索引。

階段 4：SEO 保留（平行軌道）

這是遷移失敗的地方。這是我們不會的地方。每個 URL 都得到映射，301 重定向通過 Cloudflare 在邊緣配置。XML 站點地圖從 Supabase 內容自動再生。結構化資料 (JSON-LD) 按頁面類型重建。我們在遷移過程中以及推出後 90 天內監控 Google Search Console，以捕捉任何索引異常。

關鍵 SEO 行動：

• 完整 URL 審計和重定向映射
• 正規標籤保留
• 內部連結結構驗證
• 元標題/描述遷移以及程式驗證
• 架構標記重建
• Robots.txt 和 sitemap.xml 再生

階段 5：零停機時間切換（第 15–16 週）

藍綠部署。新的 Next.js + Supabase 堆棧在 Vercel 上平行運行，而 Optimizely 網站保持活躍。最終內容同步在切換前 2 小時執行。DNS 通過 Cloudflare 切換，具有即時傳播。流量零停機時間轉移。我們將舊環境保持溫暖 30 天作為安全淨網。

階段 6：發布後優化（第 17–20 週）

性能監控、CWV 追蹤、編輯人員在 Supabase Studio 上的培訓（或如果編輯人員需要視覺介面，則輕量級 CMS 層如 Payload CMS），以及交接文件。

時間表和投資

典型的企業 Optimizely DXP 退出從審計到推出需要 14–20 週。定價範圍從 $150K–$350K，取決於內容數量、網站數量、整合複雜性和本地化要求。

作為參考：您的下一個 Optimizely DXP 續約可能是 $200K+。遷移在第二年之前為自己支付。

這是為誰

運行 Optimizely CMS 12（或舊版 Episerver）的企業團隊，面臨續約決定、性能問題，或只是無法足夠快速交付。如果您的工程團隊花費更多時間與平台搏鬥而不是構建功能，是時候離開了。

我們不做通用重新平台。Aryan 和團隊深冷知道 Optimizely 的內部—內容模型、blob 儲存怪癖、部署管道限制。這就是為什麼我們可以保證分類法保留和零停機時間。這不是我們的第一次退出。