Salesforce 以约 15 亿美元收购 Contentful，客户会面临哪些变化

要点

• Salesforce 于 2026 年 9 月 1 日完成了对 Contentful 的收购，交易金额约为 15 亿美元，约为 Contentful 在 2021 年达到的 30 亿美元估值的一半。
• 对客户而言，目前几乎没有任何变化。API 仍然可用，公开定价保持不变，欧洲客户仍与 Contentful GmbH 签约，公开的数据处理文件也早于本次交易。
• 变化在于商业层面。一旦 Contentful 被纳入 Salesforce 的大型协议中，日后将其移除就不再是简单的成本削减措施。
• 支撑这笔交易的 AI 和个性化功能仍为 Enterprise 层级专属。
• 重度 Salesforce 用户从整合中获益最多，同时也最易受到捆绑锁定。对他们来说，留下很可能是正确的决定，但应将 Contentful 作为单独定价的项目进行谈判，并明确退出条款。
• 对于其他所有人，现在正确的做法是估算一个可信的迁移成本，而不是着手迁移。

2025 年 9 月，非营利组织 Hack Club 差点不得不离开 Slack——这个它已使用了十一年的 Salesforce 旗下聊天平台。

软件本身运行正常。问题出在商业层面。Hack Club 表示，围绕其非营利定价安排的争议使其面临立即支付 5 万美元、此后每年约 20 万美元的局面，而工作区内还存有十一年的社区历史。工程师们开始备份数据并测试 Mattermost。此事登上了 Hacker News；Slack 称这是一次计费错误，并恢复了该非营利组织的条款。最初的讨论至今仍异常有用，因为双方都参与了其中。

条款恢复了，但 Hack Club 有几天不得不为一件公司通常不愿计算的事情定价：在积累了十年的数据、工作流、集成和习惯之后，离开一个 SaaS 产品的成本。

Salesforce 自 2021 年起拥有 Slack。如今它又拥有了另一个同样需要做此计算的平台。

它于 2026 年 9 月 1 日完成了对 Contentful 的收购。Salesforce 将 Contentful 描述为一个受到超过 4,800 个品牌信赖的平台，并表示此次收购将为 Headless 360 提供一个与 Data 360 和 Agentforce 相连的原生内容层。Contentful 自身报告称每月 1,800 亿次 API 调用，社区人数超过 55 万。Salesforce 的 SEC 文件显示，扣除 Salesforce 已持有的股份后，该交易以现金形式约为 15 亿美元——远低于 Contentful 在 2021 年融资时的 30 亿美元估值，约为其报告的 2024 年 ARR 的七倍。

Contentful 客户尚未遭遇类似 Hack Club 的事件。没有公开证据表明收购后出现大范围涨价，没有强制迁移到 Salesforce 合同，也没有突然的产品变更。Contentful 的 API 仍然可用，公司仍在持续发布产品，其现有法律架构也保持不变。

这笔收购仍然重要。Contentful 不再是一家独立的 CMS 公司，可以自行决定将工程预算投向何处以及如何构建商业关系。它现在正在填补 Salesforce 技术栈中的一个空缺。

这种变化很可能会缓慢而非剧烈地发生，这正是客户应该现在审视它、而不是等到变化变得显而易见之后的原因。

Salesforce 对 Contentful 有明确的用途

Salesforce 已经掌握了客户互动周围的大量上下文：CRM 记录、购买记录、支持历史、营销活动、商务数据、受众，以及如今基于这些信息采取行动的智能体。

但在拥有这些系统最终需要呈现的结构化内容方面，它一直弱得多。并非没有尝试：Salesforce CMS 自 2019 年就已存在。但它是一个混合型 CMS，其完整功能集需要 Experience Cloud 许可证，而且其内容被算作数据而非元数据，因此甚至无法复制到部分沙盒中。它服务 Salesforce 自有渠道还算够用。但它从未成为企业搭建主网站所依托的系统。

Contentful 恰好契合，因为它的基本单元不是网页。企业可以一次性建模产品描述、监管免责声明、支持答案、营销活动模块或本地化编辑内容，然后通过 API 在需要的地方随时调用。

无头 CMS 厂商多年来一直在推销这一理念。智能体软件让它变得更有价值。当智能体检索的是经过批准的结构化对象，而不是抓取网站并试图判断哪段文字才是权威时，它更容易被控制。

Salesforce 明确表示了自己想把这带向何方。其公告将 Contentful 描述为企业内容层，将把其可组合 API 与 Data 360 和 Agentforce 相结合，以生成个性化、由 AI 组装的体验。

对于已经在 Salesforce 上投入巨资的企业来说，这可能是此次收购较好的结果之一。如今，团队往往要在 CRM 数据、商务、个性化、营销自动化和他们的 CMS 之间维护定制管道。Salesforce 现在可以将其中一些连接变成第一方基础设施。

这种打包方式有一个陷阱，而且它早于 Salesforce 存在。Contentful 的定价页面将 AI Actions 放在 Enterprise 计划中，并将 Personalization 作为 Enterprise 之上的单独产品定价。因此，Salesforce 所推销的智能体内容故事，恰恰在 Salesforce 对更广泛合同最有影响力的那些客户身上落地最重。

对于较小的客户来说，“Salesforce 为 AI 收购了 Contentful”可能并不意味着现有计划中会新增 AI 功能。它可能意味着，用来证明这笔交易合理性的功能，成了在别处同类能力很便宜的时候却要向上游市场迁移的又一个理由。在我们自己为期五周的试点中，两名编辑在 148 篇文章和 123 个落地页上运行了 31 个真实内容任务；Payload 的开源内容智能体在其中 20 个任务上完成得更快，每个任务的模型成本约为 0.39 美元。

更有趣的问题是，那些因为 Contentful 是中立基础设施而选择它的公司会怎样。

独立的 Contentful 有直接动机与 Salesforce、Shopify、定制 CRM 或任何未来出现的东西同等良好地协作。Salesforce 拥有的 Contentful 仍然需要那个生态系统，但其所有者现在有了额外的动机去投资那些能让 Data 360、Agentforce 和更广泛的 Customer 360 平台更有价值的集成。

Content Delivery API 不需要被限制，这种转变就会产生影响。开发者到 2028 年可能仍会愉快地在 Contentful 上构建 Next.js 网站，而投资最高的个性化功能、AI 工作流、治理工具和企业演示环境则越来越多地假定使用 Salesforce 产品。

这才是值得期待的方向。Salesforce 不会花 15 亿美元让 Contentful 保持战略中立。

它也不需要让 Contentful 变得更糟，就能改变其生态系统之外客户的经济账。

更大的风险是捆绑经济

Salesforce 对 Slack 的所有权在这里很有参考价值，因为这笔收购已经足够久，那些平淡无奇的变化已经开始显现。

交易完成五年后，Slack 看起来仍然像 Slack。它保留了品牌、自身的产品身份，以及很大程度的商业独立性。但从 2026 年 10 月 27 日起，Slack 支持将迁移到 Salesforce Success Plans 和 Salesforce Help。Salesforce 的条款将适用于这些支持计划。Slack 的文档还提到客户通过 Salesforce 代表在 Salesforce 订单表格上购买。重要的是，Slack 表示这次特定的支持迁移不会增加额外费用。

Hack Club 的恐慌是响亮的那一种。支持迁移则是安静的那一种，而对 Contentful 来说，安静的那一种比突然关停或更名要可信得多。

Acquia 收购 Widen 走过了从 CMS 市场另一个角落出发的类似路径。Acquia 在 2021 年收购 Widen 后让它继续运营。然而到 2023 年，Widen 已变成 Acquia DAM，Acquia 正在整合网站、支持渠道、社交网络和 CRM 系统。与此同时，Acquia 明确告诉客户，他们的 URL、API、SSO、集成、门户和嵌入内容将继续正常工作。

软件可以保持稳定，而围绕它的商业外壳却在改变。对 Contentful 来说，这个外壳可能比未来的标志更重要。

想象一家公司每年在 Sales Cloud、Service Cloud、Marketing Cloud 和 Data 360 上花费数百万美元。把 Contentful 放进同一场谈判是显而易见的事。Salesforce 可以给捆绑包打折、省去又一次供应商审查、整合支持并简化采购。这些都是实实在在的好处。

它们也改变了退出价格。

假设 Contentful 在一份大得多的 Salesforce 协议中名义上每年价值 30 万美元。三年后，用另一个 CMS 替换它可能省不下 30 万美元，因为移除 Contentful 会改变套餐中其他部分的折扣或条款。技术 API 可以保持完全开放，而迁移的财务成本却在上升。

这是企业团队最应该认真对待这笔交易的部分。Salesforce 不需要创造专有内容格式来让 Contentful 变得黏人。它已经有一个有效得多的工具：一份非常大的企业合同。

企业捆绑陷阱图表

Contentful 的社区提供了一些制衡。在这个规模上，该平台拥有代理商、成熟的 SDK、开源库、第三方应用，以及有商业理由让集成和迁移工具继续存活的开发者。

Contentful 仍然缺少 Drupal 给 Acquia 的 CMS 客户提供的那条退路——他们可以停止从 Acquia 购买，继续运行 Drupal。

Payload 被 Figma 收购后也拥有类似的结构性保护。Figma 已公开表示 Payload 将继续保持开源，Payload 用户可以自行托管该软件。现在要判断这笔收购在五年后会是什么样子还为时过早，但用户拥有 Contentful 客户所没有的东西：一个可部署的产品版本。Contentful 客户可以 fork 一个 SDK 或维护一个集成，但他们无法把 Contentful 的托管服务、编辑后端、环境、权限和工作流状态拿走，并在别处运行同样的产品。

对 Contentful 而言，逃生路线是迁移。

对欧洲客户来说，法兰克福并不是重点

Salesforce 的所有权还引发了一个比事实所能支撑的简单得多的叙事：Contentful 是德国的，Salesforce 是美国的，因此欧洲的 Contentful 数据现在由一家美国实体处理，并暴露于美国法律之下。

Contentful 目前的文件并不是这么说的。

其 服务条款仍指定位于柏林的 Contentful GmbH 作为欧洲、英国、中东、非洲和亚洲客户的签约实体。其欧盟驻留选项仍将主区域设为 AWS 都柏林，备份设为法兰克福。Contentful 还明确表示，欧盟驻留数据并不保证仅在欧盟境内处理或仅可从欧盟境内访问。

在 Salesforce 到来之前就存在美国依赖。Contentful Inc. 已经是美国关联公司，当前的子处理者名单中包含为部分服务提供支持的美国供应商。这笔收购把问题从服务器位置变成了公司控制权。

美国《CLOUD 法案》明确规定，受美国司法管辖的公司可能被强制要求提供其保管或控制的数据，无论数据存储在何处。美国司法部直接描述了这一规则。它还指出了一个重要限制：《CLOUD 法案》本身并未改变某供应商是否属于美国司法管辖范围。

因此，“备份在法兰克福”不足以解决问题，但“Salesforce 拥有 Contentful”同样也不够。

受监管的客户需要知道哪些 Salesforce 实体可以访问其数据，Salesforce 人员是否运营相关系统，Contentful 内容是否开始流入 Data 360 或 Agentforce，以及最终由哪个实体控制这些数据。

这些细节尚未完全体现在公开法律文件中。Contentful 的子处理者名单仍以 2026 年 5 月 22 日为生效日期，即收购完成之前，且 Salesforce 实体目前并未作为客户内容的处理者列于其中。当前的客户 DPA 日期为 2025 年 6 月 19 日。

这正是欧洲客户可以具体关注的地方。根据该 DPA 第 7 条，Contentful 必须提供关于新子处理者的通知机制，客户有 21 天时间基于重大数据保护理由提出合理反对。如果问题无法解决，DPA 为受影响的服务提供了有限的终止机制。

对许多公司来说，这将是又一次供应商审查。对银行、医疗、公共部门组织以及拥有更严格主权政策的公司而言，这可能成为彻底重新考虑该平台的理由。

迁移市场已经在行动

Contentstack 没有等待这些风险中的任何一个成为现实。

其当前的 Contentful 迁移承诺 为符合条件的 Contentful Premium 客户提供首年价格匹配、90 天延期付款、专属迁移架构师、预构建的 Contentful 迁移模式，以及针对 2026 年 10 月 31 日前完成的迁移提供 90 天上线后支持。

Contentstack 关于 Salesforce 定价和锁定的预测应被视为竞争性销售文案。迁移优惠本身更具揭示性。除非转换成本是赢得这些客户的主要障碍，否则供应商不会向市场抛出价格匹配、延期付款、工程师和上线后支持。

Contentstack 现在声称可以在几分钟内为复杂度较低的 Contentful 项目自动化内容和代码迁移。该工具是真实存在的；但“几分钟”不应与企业级重新平台化的持续时间混为一谈。

Sanity 从不同角度处理同一问题。其官方的 Contentful 到 Sanity 包会从 Contentful 空间创建 Sanity 项目和模式，然后准备数据集以供导入。Storyblok 也有专门的 Contentful 路径，但其文档更有趣，因为它明确指出了自动化停止的地方：Contentful 的模型必须映射到 Storyblok 的组件系统中，富文本和链接条目可能需要转换，webhook 负载不同，环境不能直接映射，自定义应用必须重建。Storyblok 的 Contentful 迁移指南明确说明了这些差异。

这是思考 Contentful 可移植性的正确方式。内容通常不是困难的部分。

Contentful 已经迫使公司将内容结构化并将其置于 API 之后。这使得离开比从传统单体 CMS 中提取多年的页面更容易。其自己的 CLI 可以导出内容类型、条目、资产、区域设置、角色、编辑器界面和 webhook。

围绕它们的运营状态则不太可移植。Contentful 自己的导出文档 指出，版本历史会重新开始，发布、任务和工作流需要单独处理，webhook 凭据必须重新创建，空间成员资格不会转移，自定义应用和 UI 扩展需要重新安装，导入的条目会丢失原始作者历史。

这些限制甚至在更换供应商之前就适用。

一旦公司迁移到不同的 CMS，它还必须处理应用程序中嵌入的假设：GraphQL 查询、预览逻辑、本地化、编辑工作流、权限、自定义应用、构建管道，以及每个期望 Contentful 形状数据的下游系统。

这就是为什么计算 Contentful 条目是估算迁移的糟糕方式。一个拥有 500,000 条简单产品记录的空间可能比一个规模小得多但具有深度定制编辑工作流和围绕 Contentful 特定行为构建的五个前端的实现更容易。

真正的迁移清单由依赖关系构成。我们的 CMS 迁移指南 介绍了在任何内容移动之前如何映射它们。

迁移应作为实验开始

考虑在 Salesforce 交易后退出的公司不需要从为期六个月的重新平台化计划开始。

他们需要确认关于转换成本的假设是否真实。

选取现有 Contentful 实现中一个困难但具有代表性的部分。包含若干带有引用、本地化字段、富文本的内容模型、一个自定义集成，以及编辑人员实际使用的前端路径。将该切片迁移到最合理的目标 CMS，并替换相应的应用查询。

一个好的概念验证能迅速暴露代价高昂的部分。也许内容模型可以干净地转换，但预览却很痛苦。也许一个看似简单的编辑工作流依赖于三个自定义应用。也许前端已经足够解耦，替换 Contentful 查询只需几天而不是几周。

Storyblok 的通用 迁移指南建议在迁移真实内容之前先构建概念验证并完善目标内容模型。这一建议无论目标 CMS 是什么都适用。

其结果比泛泛的供应商对比有用得多。它告诉公司哪些迁移工作可以自动化，哪些依赖需要工程投入，哪些编辑流程需要重新设计，以及一次现实的切换可能花费多少。现实的估算很重要，因为迁移很少仅仅因为有人不喜欢某次收购而发生。

它们发生，是因为另一个事件让维持现有平台的成本变得高昂。

Arriva 的出行平台 Glimble 就是一个有用的例子。约 2,000 个页面，Contentful 账单约为每月 1,500 欧元，且重新设计的预算已经到位。迁移到基于 Next.js 的自托管 Payload CMS 花了大约两个月，将运行成本降至每月 100–150 欧元，同时将多市场支持和 AI 辅助翻译并入同一个项目，而不是为此支付两次费用。自托管将成本转移到工程上，而不是消除成本。时机之所以合适，是因为重新设计的预算已经承诺。

Contentful 客户可能会在网站重新设计、前端重写、企业续约或合规审查期间到达同样的节点。一旦公司已经为重大变更付费，经济账就变了。围绕 Contentful 重建和替换 Contentful 之间的差距，不再是全新迁移的全部成本。

那正是 Salesforce 收购可能从背景风险转变为迁移项目的时刻。

目的地取决于你离开的原因

对于 Contentful 替代品，并不存在有用的通用排名。

如果公司仍然想要一个面向开发者的托管内容后端，Sanity 是一个显而易见的可测试平台，其现有的 Contentful 导入器让这种测试成本很低。

当问题涉及编辑体验和组件驱动的内容时，评估 Storyblok 更有意义。它的建模方法与 Contentful 差异足够大，盲目转换旧 schema 会错失要点，这也是在承诺之前先做原型的另一个原因。

Contentstack 明确瞄准那些仍然想要托管可组合平台的企业级 Contentful 账户。它目前最强的卖点不是迁移轻而易举，而是它愿意承担此次迁移的部分商业和工程风险。

然而，如果 Salesforce 的所有权本身就是问题所在，那么立即转向另一个专有的企业级 SaaS就需要更多考量。Payload 之所以有趣，正是因为 Figma 承诺保持其开源和可自托管。Strapi 提供了同一权衡的另一种变体：承担更多基础设施责任，以换取对内容底层平台更多的控制权。

而有些迁移评估的结论应该是留在 Contentful。

一家大量使用 Salesforce 的公司可能会得出结论：计划中的 Data 360 和 Agentforce 集成将消除足够多的自定义基础设施，使这次收购成为净收益。这些集成目前尚不存在，所以眼下这些管道工作仍是自定义的，但方向已经足够清晰，可以纳入决策考量。那样的话，迁移反而会去解决一个该公司并不存在的问题。

更可能的候选者是那些 Salesforce 采用度低、Contentful 成本或定制化程度高、即将进行重新设计或续约，或者随着 Salesforce 集成加深而监管要求变得棘手的公司。

对它们来说，今天最有用的产出不是一份已签署的迁移项目，而是一份可信的切换成本估算。该估算不仅应包含迁移工作量，还应包含留下来的真实成本。在建模替代方案之前，详细审视Contentful 定价可以提供有用的基准。

Contentful 的 API 或许会保持开放。你的退出成本却未必。

在相当长一段时间内，Contentful 很可能看起来仍可辨认地是 Contentful。保持其 API、开发者生态系统和现有客户完好无损，符合 Salesforce 的利益。

变化更快的是这些 API 周围的语境。

Agentforce 将获得更好的 Contentful 集成。Data 360 将出现在更多工作流中。Salesforce 将在企业销售和支持中更加显眼。一些客户会发现，Contentful 与他们的 Salesforce 合同契合得非常好。法律文件最终将不得不反映 Salesforce 实际构建的任何运营集成。

这些事件都不必是戏剧性的。

这正是捆绑经济学的危险之处。每一个单独的决定都可以是理性的：接受折扣、采用原生集成、整合支持、节省工程工作。几个续约周期之后，API 可能仍然开放，而离开却变成了一个大得多的项目。

对于已经在怀疑 Contentful 是否仍是合适平台的公司来说，Salesforce 的收购是一个很好的理由，让它们不再猜测那个项目会花多少钱。Hack Club 不得不在几天内、在压力之下算出其退出价格。Contentful 客户现在就可以做这件事，而没有什么在逼迫他们。不是因为迁移必然是正确答案，而是因为拥有选择权的代价往往在你需要它之后才上涨。

披露：FocusReactive 是 Contentful 合作伙伴 ，同时也基于 Sanity、Storyblok 和 Payload 构建。

总结

下次续约前应向 Contentful 提出的问题

• 哪些 Salesforce 实体可以访问你的客户内容，Salesforce 人员是否会运营处理这些内容的系统？
• DPA 和子处理者列表何时会更新以反映交易完成后的结构？
• 你的签约实体、订单表格或支持计划会在续约时改变吗？
• 如果你之后将 Contentful 从捆绑协议中移除，你的折扣会怎样？

如果你想要的是确切数字而不是猜测：我们的迁移估算器会根据你的线上站点来评估 Contentful 重新平台化的范围（内容模型、组件清单、工时和成本区间），当迁移真正提上日程时，会由一位资深工程师审核输出结果。大多数重新平台化项目都会超出预算；我们的项目中有 90% 落在最初报价范围内，几乎总是因为依赖关系在前期就已梳理清楚。

估算你的 CMS 迁移，或者把你认为最难的部分发给我们，我们会告诉你需要付出什么。