将 Optimizely CMS 12 迁移到 Next.js + Supabase

为什么企业正在离开 Optimizely CMS 12

Optimizely CMS 12—曾经是 Episerver 的 PaaS 演进版本—曾经有过它的时刻。它将 CMS、商务和个性化捆绑到托管的 Azure 环境中，这在一段时间内运行良好。但现在是 2025 年了：庞大的 .NET 根基、不断上升的许可证等级，以及共享基础设施模型，这创造了性能上限，你的工程团队根本无法突破。

我们已经为支付 20 万美元至 50 万美元年度许可证费用的企业团队从 Optimizely DXP 进行了迁移。他们需要多渠道交付、300 毫秒以下的 TTFB，以及招聘 React 开发人员而不是 .NET 专家的能力。经济账不再成立。

Optimizely DXP 的真实痛点

按比例向你收费的许可证

Optimizely 的分层定价—集团版、企业版、旗舰版—按环境和 Web 应用程序收费。添加商务模块、个性化附加组件和自定义集成，你就会看到每年都会增加的六位数续约费用。当你的营销团队想要新的微网站时，预算讨论从许可证开始。不是设计。是许可证。

架构中根深蒂固的性能上限

Optimizely DXP 运行在共享的 Azure PaaS 基础设施上。你的集成、预生产和生产环境共享一个 Web 应用程序和搜索索引。在我们审计的大多数 Optimizely 网站上，实际的 Lighthouse 移动评分在 45-65 之间。SCA 案例研究—由 Optimizely 自己广泛引用—显示从 43 提高到 70。那是进展，当然。但它没有竞争力。现代无头构建持续达到 95-100。

开发人员体验摩擦

仅限 .NET 的模板系统意味着你的前端开发人员无法使用他们实际了解的工具。每次 UI 变更都需要完整的全栈 .NET 部署周期。尝试在 2025 年招聘资深 .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），以及用于边缘缓存和 DDoS 保护的 Cloudflare。

赢得 Core Web Vitals 的性能

Next.js App Router 搭配 ISR（增量静态再生）在全球范围内提供 300 毫秒以下的 TTFB。静态页面在构建时生成；动态内容按需重新验证。Lighthouse 移动评分 95-100 是基线，而不是抱负。

开源经济学

Supabase Pro（每月 25 美元）替代 20 万美元/年的 DXP 许可证。Vercel 托管（每个站点 20 美元/月）替代 1 万美元+/月的 Azure PaaS 费用。三年 TCO 从 90 万美元+ 下降到大约 30 万美元，包括迁移本身。投资回报率在 12 个月内转为正数。

真正的无头，不是无头邻近

Optimizely CMS 13 宣传无头功能，但它仍然是 PaaS 优先，只是附加了 API。Supabase 是 API 原生的。每条内容都可以通过 REST 或 GraphQL 访问，由行级安全策略保护。你的移动应用、你的网络应用、你的信息亭—相同的内容 API，零额外许可证。

现代开发人员工作流

React 组件、TypeScript、基于 Git 的部署、每个 PR 的预览环境、用于服务器逻辑的边缘函数。你的团队在几天内发布功能，而不是冲刺周期。招聘渠道开放给世界上最大的前端开发人员社区。

我们的迁移流程

我们的平台迁移负责人 Aryan Shah 为 Optimizely DXP 退出制定了一个可重复的剧本，保留每条内容、维护 SEO 权益并实现零停机时间。

第 1 阶段：深度审计（第 1-3 周）

我们映射你的整个 Optimizely 内容模型—页面类型、块类型、内容区域、分类树、媒体资源、URL 结构和集成接触点。我们导出完整清单并标记需要重组的内容与映射 1:1 到 Supabase 模式的内容。

第 2 阶段：模式设计和 ETL 管道（第 4-8 周）

自定义 Node.js ETL 脚本从 Optimizely 的数据库提取内容并将其转换为 Supabase PostgreSQL 表。分类层次结构通过递归表结构和反映你现有 RBAC 权限的 RLS 策略得以保留。媒体资源从 Azure Blob Storage 迁移到 Supabase Storage。我们已经使用并行上传管道在一小时内处理了 5 万+ 资源的目录。

第 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 周。定价范围从 15 万美元-35 万美元，取决于内容量、网站数量、集成复杂性和本地化需求。

为了参考：你的下一个 Optimizely DXP 续约可能是 20 万美元+。迁移在第二年之前为自己付出代价。

这是为了谁

运行 Optimizely CMS 12（或旧版 Episerver）的企业团队，他们面临续约决定、性能问题，或根本无法快速交付。如果你的工程团队花费更多时间与平台搏斗而不是构建功能，是时候离开了。

我们不做通用重平台。Aryan 和团队对 Optimizely 的内部工作了如指掌—内容模型、blob 存储怪癖、部署管道限制。这就是我们能保证分类保留和零停机时间的原因。这不是我们的第一次退出。