迁移 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 许可可能每年运行 10 万美元到 50 万美元以上，具体取决于你的层级、模块和用户数。加上 Sitecore 专业开发人员（一个萎缩的、昂贵的人才池）、托管基础设施以及保持一切补丁和兼容性的开销。对于你实际得到的东西来说，总拥有成本是巨大的。

Content Hub 锁定

Sitecore Content Hub 应该解决 DAM 和内容操作。实际上，它是另一个紧密耦合的模块，加深了你的平台依赖。用 Sanity 的内容湖替换 Content Hub 给你一个单一的、可查询的真实来源，不受供应商锁定。

开发者体验是瓶颈

Sitecore 开发很慢。就是这样。构建时间拖沓，本地开发环境很脆弱，组件在 Experience Editor 中的外观与生产环境之间的差距是持续的 bug 来源。JSS 略微改进了情况，但你仍然通过 Sitecore 的管道部署。

内容团队摩擦

Sitecore 中的内容编辑在严格的页面模板内工作。想在频道间重用内容块吗？那需要开发人员干预。想要实时预览更改吗？Experience Editor 的渲染延迟使这很痛苦。内容团队最终被阻止，提交工单而不是发布。

个性化虚张声势

Sitecore 的个性化引擎 — xDB、xConnect — 在销售演示中听起来令人印象深刻。实际上，大多数组织只使用其功能的一小部分，因为实施成本巨大。你为企业 DXP 价格买单却只是得到一个 CMS。

Sanity 带来的东西

结构化内容建模

Sanity schemas 在代码中定义 — TypeScript 或 JavaScript，在 Git 中进行版本控制，在 pull requests 中审查。你以编程方式定义文档类型、对象类型、引用和验证。你的内容模型变得与应用程序代码一样严格和可移植。

Portable Text — Sanity 的富文本格式 — 将内容存储为结构化 JSON 而不是原始 HTML。你的内容在 web、移动、电子邮件、信息亭或任何未来频道上正确渲染，无需转换麻烦。

GROQ 内容湖

GROQ 是 Sanity 的查询语言。它很有表达力、速度快、专门为查询结构化内容而构建。与 GraphQL 不同，没有 schema 拼接或 resolver 复杂性。你写一个 GROQ 查询，你获得你需要的确切数据形状。内容湖是一个实时的、全局分布的数据存储 — 而不是一个与 CMS 相连的数据库。

实时协作

多个编辑可以同时处理同一文档。更改瞬间显示。没有签入/签出锁定，没有合并冲突，没有丢失的工作。Sanity Studio 显示存在指示器，所以你的团队知道谁在编辑什么。想像 Google 文档级别的协作，但用于你的 CMS。

Sanity Studio：你的自定义 CMS

Sanity Studio 是一个开源的、基于 React 的编辑环境，你拥有和自定义。需要一个用于 SEO 评分的自定义小部件吗？构建它。需要一个编辑审批的工作流插件吗？构建它或安装一个。Studio 作为你的代码库的一部分部署 — 不托管在 Sanity 的基础设施上 — 这意味着完全控制。

MACH 可组合架构

Sanity 恰当地融入 MACH 栈。它处理内容。你的前端（Next.js、Astro、Remix）处理呈现。你的商务平台处理交易。你的搜索服务处理搜索。每项服务都是一流的、独立可部署的和可替换的。没有单体。

我们的 Sitecore 到 Sanity 迁移流程

第 1 阶段：发现和内容审计（2–3 周）

我们盘点你的 Sitecore 实例 — 每个模板、呈现、内容项、媒体资产、个性化规则和工作流。我们爬取网站的 URL 结构、重定向和 SEO 元数据。我们将 Sitecore 的模板层次结构映射到 Sanity 文档类型，并决定什么迁移、什么整合、什么删除。

可交付成果：内容模型映射文档、迁移范围、风险评估、SEO 基线报告。

第 2 阶段：Sanity 中的内容建模（2–3 周）

我们从头设计你的 Sanity schemas。不是 Sitecore 模板的 1:1 移植 — 一个适当的结构化内容模型，针对重用、全渠道交付和编辑效率进行优化。我们配置 Portable Text、引用结构、分类系统和本地化模式。

我们用自定义输入组件、预览窗格和编辑工作流设置 Sanity Studio，这些与你在 Sitecore 中拥有的相匹配 — 并有所改进。

第 3 阶段：前端开发（4–8 周）

我们在 Next.js（或用于内容繁重的网站的 Astro）中构建你的前端，通过 GROQ 查询连接到 Sanity。配置可视编辑和实时预览，以便编辑在实际网站上看到更改 — 而不是 Experience Editor 近似值。

性能是不可商量的。我们在移动设备上针对 300 毫秒以下的 TTFB 和 95+ Lighthouse 分数。

第 4 阶段：内容迁移和验证（2–4 周）

我们通过 API、数据库导出或网站爬取从 Sitecore 提取内容 — 任何给我们最干净数据的方式。自定义迁移脚本将 Sitecore 字段转换为 Sanity 文档结构，将富文本转换为 Portable Text，并将媒体资产重新映射到 Sanity 的资产管道。

迁移分阶段运行 — 子集导入、针对源验证、自动奇偶校验检查。不是单个高风险切换。

第 5 阶段：SEO 保护、QA 和启动（1–2 周）

每个 URL 都获得重定向映射。我们验证 canonical 标签、结构化数据、Open Graph 元数据、XML 站点地图和 hreflang 标签。迁移前后的爬取确认零 SEO 回归。

我们培训你的内容团队了解 Sanity Studio、文档化一切，并在启动和生产的前几周关键时期支持你。

SEO 保护策略

Sitecore 迁移如果处理不当会带来真实的 SEO 风险。我们的方法：

• 完整 URL 清单 — 来自 Sitecore 站点地图和爬取数据，交叉引用 Google Search Console
• 301 重定向映射 — 针对每个索引 URL，在边缘实施（Vercel、Netlify 或 Cloudflare）
• 元数据迁移 — title tags、meta descriptions、OG tags、结构化数据都已移植和验证
• 内部链接审计 — 每个内部链接都更新以防止重定向链
• 启动后监控 — Search Console 索引、Core Web Vitals 和 90 天的排名跟踪

我们迁移了有 5 万多个页面的网站而没有丧失有机流量。关键是将 SEO 视为一流的工作流，而不是事后想法。

时间表和定价

大多数 Sitecore 到 Sanity 迁移运行 12–20 周，具体取决于内容量、网站数量、本地化复杂性和前端范围。

| 范围 | 时间表 | 投资 | |-------|----------|------------|| | 单个网站，<5K 页面 | 12–14 周 | 8 万美元–15 万美元 | | 多站点，5K–50K 页面 | 14–18 周 | 15 万美元–30 万美元 | | 企业，50K+ 页面，多品牌 | 18–24 周 | 30 万美元以上 |

这些数字是大多数组织每年在 Sitecore 许可上花费的一小部分。迁移在第一年内通过降低许可、托管和开发成本来自我偿还。

我们部署的 MACH 可组合栈

迁移后，你的架构如下所示：

• 内容：Sanity CMS（内容湖 + Studio）
• 前端：Next.js 或 Vercel/Netlify 上的 Astro
• 搜索：Algolia 或 Typesense
• 商务：Shopify、commercetools 或 Medusa（如适用）
• 媒体：Sanity Asset Pipeline 或 Cloudinary
• 分析：Plausible、Fathom 或 GA4

每个组件都是独立可扩展的、可替换的和 API 连接的。没有供应商锁定。没有单体税。