Salesforce Contentful Acquisition: What the Deal Means for Contentful Customers

verified October 2026
Dmitrii Susloparov Lead Marketing Manager
16 min

Key takeaways

  • Salesforce completed its acquisition of Contentful on September 1, 2026, for roughly $1.5 billion, about half of the $3 billion valuation Contentful achieved in 2021.
  • Almost nothing has changed for customers yet. The APIs still work, published pricing remains unchanged, European customers still contract with Contentful GmbH, and the public data processing documents predate the deal.
  • The change is commercial. Once Contentful is included in large Salesforce agreements, removing it later is no longer a simple cost-saving measure.
  • The AI and personalization features that justified the deal remain exclusive to the Enterprise tier.
  • Heavy Salesforce users have the most to gain from integration and the greatest exposure to bundle lock-in. Staying is likely the right decision for them, but they should negotiate Contentful as a separately priced line item with clear exit terms.
  • For everyone else, the right move now is to develop a credible switching-cost estimate rather than pursue a migration.

In September 2025, Hack Club, a nonprofit, nearly had to leave Slack, the Salesforce-owned chat platform it had used for eleven years.

The software was working. The problem was commercial. Hack Club said a dispute over its nonprofit pricing arrangement had left it facing $50,000 immediately and roughly $200,000 a year after that, with eleven years of community history sitting inside the workspace. Engineers began backing up data and testing Mattermost. The story reached Hacker News; Slack described it as a billing mistake and restored the nonprofit’s terms. The original discussion remains unusually useful because both sides participated.

The terms came back, but for a few days Hack Club had to price something companies usually prefer not to calculate: the cost of leaving a SaaS product after a decade of accumulated data, workflows, integrations, and habits.

Salesforce has owned Slack since 2021. It now owns another platform where the same calculation matters.

It completed the acquisition of Contentful on September 1, 2026. Salesforce describes Contentful as a platform trusted by more than 4,800 brands and says the acquisition will give Headless 360 a native content layer connected to Data 360 and Agentforce. Contentful itself reports 180 billion API calls a month and a community of more than 550,000 people. Salesforce’s SEC filings put the transaction at roughly $1.5 billion in cash, net of the stake Salesforce already held — well below the $3 billion valuation Contentful raised at in 2021, and around seven times its reported 2024 ARR.

Nothing comparable to the Hack Club episode has happened to Contentful customers. There is no public evidence of a broad post-acquisition price increase, no forced move onto Salesforce contracts, and no abrupt product change. Contentful’s APIs still work, the company is still shipping, and its existing legal structure remains in place.

The acquisition matters anyway. Contentful is no longer an independent CMS company deciding where to spend its engineering budget and how to structure its commercial relationships. It is now filling a hole in Salesforce’s stack.

That change will likely happen slowly rather than dramatically, which is why customers should look at it now rather than after the change becomes obvious.

Salesforce has an obvious use for Contentful

Salesforce already owns much of the context surrounding a customer interaction: CRM records, purchases, support history, marketing activity, commerce data, audiences, and now the agents acting on that information.

It has been much weaker at owning the structured content those systems eventually need to present. Not for want of trying: Salesforce CMS has existed since 2019. But it is a hybrid CMS whose full feature set requires Experience Cloud licenses, and whose content counts as data rather than metadata, so it does not even copy into a partial sandbox. It serves Salesforce’s own channels well enough. It never became the system a company builds its main website on.

Contentful fits neatly because its basic unit is not a webpage. A company can model a product description, regulatory disclaimer, support answer, campaign module, or localized editorial copy once, then retrieve it via APIs wherever it is needed.

Headless CMS vendors have been selling that idea for years. Agentic software makes it more valuable. An agent is easier to control when it retrieves approved structured objects than when it scrapes a website and tries to decide which paragraph is authoritative.

Salesforce says exactly where it wants to take this. Its announcement describes Contentful as an enterprise content layer that will combine its composable APIs with Data 360 and Agentforce to produce personalized, AI-assembled experiences.

For a company already paying for a substantial Salesforce estate, this could be one of the acquisition’s better outcomes. Today, teams often maintain custom plumbing between CRM data, commerce, personalization, marketing automation, and their CMS. Salesforce can now turn some of those connections into first-party infrastructure.

The packaging has a catch, and it predates Salesforce. Contentful’s pricing page puts AI Actions on Enterprise plans and prices Personalization as a separate product on top of Enterprise. The agentic-content story Salesforce is selling therefore lands hardest in exactly the accounts where Salesforce has the most leverage over the wider contract.

For a smaller customer, “Salesforce bought Contentful for AI” may not mean new AI functionality arriving in an existing plan. It may mean the features used to justify the deal become another reason to move upmarket, at a moment when comparable capability is cheap elsewhere. In a five-week pilot of our own, two editors ran 31 real content tasks across 148 articles and 123 landing pages; Payload’s open-source content agent finished faster on 20 of them, at roughly $0.39 per task in model costs.

The more interesting question is what happens to companies that chose Contentful because it was neutral infrastructure.

An independent Contentful had a straightforward incentive to work equally well with Salesforce, Shopify, , a custom CRM, or whatever comes next. A Salesforce-owned Contentful still needs that ecosystem, but its owner now has an additional incentive to invest in integrations that make Data 360, Agentforce, and the broader Customer 360 platform more valuable.

The Content Delivery API does not need to be restricted for this shift to matter. Developers may still be building Next.js sites on Contentful quite happily in 2028 while the highest-investment personalization features, AI workflows, governance tools, and enterprise demonstration environments increasingly assume Salesforce products.

That is the direction worth expecting. Salesforce did not spend $1.5 billion to keep Contentful strategically neutral.

Nor does it need to make Contentful worse to change the economics for customers outside its ecosystem.

The bigger risk is bundle economics

Salesforce’s ownership of Slack is useful here because the acquisition is old enough for the boring changes to have started.

Slack still looks like Slack five years after the deal. It kept the brand, its own product identity, and a large degree of commercial separation. But from October 27, 2026, Slack support will move onto Salesforce Success Plans and Salesforce Help. Salesforce terms will apply to those support plans. Slack’s documentation also discusses customers buying through Salesforce representatives on Salesforce order forms. Importantly, Slack says this particular support migration adds no extra charge.

Hack Club’s scare was the loud version. The support migration is the quiet one, and the quiet one is a much more plausible model for Contentful than a sudden shutdown or rebrand.

Acquia’s Widen acquisition followed a similar path from another corner of the CMS market. Acquia kept Widen running after it bought it in 2021. By 2023, however, Widen had become Acquia DAM, and Acquia was combining websites, support channels, social networks, and CRM systems. At the same time, Acquia explicitly told customers that their URLs, APIs, SSO, integrations, portals, and embeds would continue working.

The software could remain stable while the commercial wrapper changed around it. For Contentful, that wrapper may matter more than a future logo.

Imagine a company spending several million dollars a year across Sales Cloud, Service Cloud, Marketing Cloud, and Data 360. Putting Contentful into the same negotiation is obvious. Salesforce can discount the bundle, eliminate another vendor review, consolidate support, and simplify procurement. Those are real benefits.

They also alter the exit price.

Suppose Contentful is nominally worth $300,000 a year inside a much larger Salesforce agreement. Three years later, replacing it with another CMS may not save $300,000 because removing Contentful changes discounts or terms elsewhere in the package. The technical API can remain perfectly open while the financial cost of switching rises.

That is the part of the deal enterprise teams should take most seriously. Salesforce does not need to create proprietary content formats to make Contentful sticky. It already has a much more effective tool: a very large enterprise contract.

enterprise bundle trap chartenterprise bundle trap chart

Contentful’s community provides some counterweight. At this scale, the platform has agencies, mature SDKs, open-source libraries, third-party applications, and developers with a commercial reason to keep integrations and migration tooling alive.

Contentful still lacks the escape route Drupal gave Acquia’s CMS customers, who could stop buying from Acquia and keep running Drupal.

Payload has a similar structural protection after its acquisition by Figma. Figma has publicly said Payload will remain open source, and Payload users can self-host the software. It is far too early to know what that acquisition will look like in five years, but users have something Contentful customers don’t: a deployable version of the product. Contentful customers can fork an SDK or maintain an integration, but they cannot take Contentful’s hosted service, editorial backend, environments, permissions, and workflow state and run the same product elsewhere.

For Contentful, the escape route is migration.

For European Customers, Frankfurt is Not the Important Part

Salesforce ownership has also triggered a much simpler story than the facts support: Contentful was German, Salesforce is American, therefore European Contentful data is now processed by an American entity and exposed to US law.

Contentful’s current paperwork does not say that.

Its Terms of Service still name Contentful GmbH in Berlin as the contracting entity for customers in Europe, the UK, the Middle East, Africa, and Asia. Its EU residency option still sets the primary region to AWS Dublin and backups to Frankfurt. Contentful also states clearly that EU-resident data is not guaranteed to be processed only in the EU or accessible only from inside the EU.

There were US dependencies before Salesforce arrived. Contentful Inc. is already a US affiliate, and the current subprocessor list contains US providers for parts of the service. The acquisition changes the question from server location to corporate control.

The US CLOUD Act makes it explicit that a company subject to US jurisdiction may be compelled to provide data in its custody or control, regardless of where it is stored. The US Department of Justice describes that rule directly. It also notes an important limit: the CLOUD Act did not itself change whether a provider falls under US jurisdiction.

So “the backups are in Frankfurt” is not enough to settle the issue, but “Salesforce owns Contentful” is not enough either.

A regulated customer needs to know which Salesforce entities can access its data, whether Salesforce personnel operate relevant systems, whether Contentful content begins flowing into Data 360 or Agentforce, and which entity ultimately controls that data.

Those details have not fully reached the public legal documents yet. Contentful’s subprocessor list is still effective as of May 22, 2026, before the acquisition closed, and Salesforce entities are not currently listed there as processors of Customer Content. The current customer DPA is dated June 19, 2025.

This is where European customers have something concrete to monitor. Under section 7 of that DPA, Contentful must provide a mechanism for notifications about new subprocessors, and customers have 21 days to make a reasonable objection on materially important data-protection grounds. If the issue cannot be resolved, the DPA provides a limited termination mechanism for the affected services.

For many companies, this will be another supplier review. For banks, healthcare, public-sector organizations, and companies with stricter sovereignty policies, it may become a reason to reconsider the platform entirely.

The Migration Market is Already Moving

Contentstack did not wait to see whether any of those risks materialized.

Its current Contentful Migration Pledge offers qualifying Contentful Premium customers a first-year price match, 90 days of deferred payment, a dedicated migration architect, pre-built Contentful migration schemas, and 90 days of post-launch support for moves completed before October 31, 2026.

Contentstack’s predictions about Salesforce pricing and lock-in should be read as competitive sales copy. The migration offer itself is more revealing. A vendor does not throw price matching, payment deferrals, engineers, and post-launch support at a market unless switching cost is the main obstacle to winning those accounts.

Contentstack now claims to automate content and code migration for lower-complexity Contentful projects in minutes. The tooling is real; the “minutes” part should not be confused with the duration of an enterprise replatform.

Sanity approaches the same problem from a different angle. Its official Contentful-to-Sanity package creates a Sanity project and schemas from a Contentful space, then prepares the dataset for import. Storyblok has a dedicated Contentful path as well, but its documentation is more interesting because it spells out where automation stops: Contentful’s models have to be mapped into Storyblok’s component system, rich text and linked entries can require transformation, webhook payloads differ, environments do not map directly, and custom apps have to be rebuilt. Storyblok’s Contentful migration guide is explicit about those differences.

This is the right way to think about Contentful portability. The content is usually not the hard part.

Contentful already forced companies to structure that content and put it behind APIs. That makes leaving easier than extracting years of pages from a conventional monolithic CMS. Its own CLI can export content types, entries, assets, locales, roles, editor interfaces, and webhooks.

The operational state around them is less portable. Contentful’s own export documentation says version history starts over, releases, tasks, and workflows need separate handling, webhook credentials have to be recreated, space memberships do not transfer, custom apps and UI extensions need reinstalling, and imported entries lose their original author history.

Those limitations apply even before changing vendors.

Once a company moves to a different CMS, it also has to deal with the assumptions embedded in the application: GraphQL queries, preview logic, localization, editorial workflows, permissions, custom apps, build pipelines, and every downstream system expecting Contentful-shaped data.

This is why counting Contentful entries is a poor way to estimate a migration. A space with 500,000 straightforward product records may be easier than a much smaller implementation with deeply customized editorial workflows and five frontends built around Contentful-specific behavior.

The real migration inventory is made of dependencies. Our CMS migration guide walks through how to map them before any content moves.

A Migration Should Start as an Experiment

Companies considering an exit after the Salesforce deal do not need to start with a six-month replatforming plan.

They need to confirm whether their assumptions about switching costs are true.

Take a difficult but representative part of the existing Contentful implementation. Include several content models with references, localized fields, rich text, one custom integration, and a frontend path that editors actually use. Move that slice to the most plausible target CMS and replace the corresponding application queries.

A good proof of concept exposes the expensive parts quickly. Perhaps the content model translates cleanly, but preview is painful. Perhaps a supposedly simple editorial workflow depends on three custom apps. Perhaps the frontend is already sufficiently decoupled that replacing Contentful queries takes days rather than weeks.

Storyblok’s general migration guidance recommends building a proof of concept and refining the target content model before migrating real content. That advice applies regardless of the destination CMS.

The result is much more useful than a generic vendor comparison. It tells the company which migration work can be automated, which dependencies need engineering, which editorial processes need redesign, and what a realistic switch might cost. A realistic estimate matters because migrations rarely happen solely because somebody dislikes an acquisition.

They happen when another event makes the existing platform expensive to keep.

Glimble, Arriva’s mobility platform, is a useful example. Around 2,000 pages, a Contentful bill of roughly €1,500 a month, and a redesign already funded. Moving to a self-hosted Payload CMS on Next.js took about two months and cut running costs to €100–150 a month, while folding multi-market support and AI-assisted translation into the same project rather than paying for them twice. Self-hosting shifts the cost to engineering rather than eliminating it. The timing worked because the redesign budget was already committed.

A Contentful customer may arrive at the same point during a website redesign, a frontend rewrite, an enterprise renewal, or a compliance review. Once the company is already paying for substantial change, the economics shift. Rebuilding around Contentful and replacing Contentful are no longer separated by the full cost of a greenfield migration.

That is the moment when the Salesforce acquisition can turn from background risk into a migration project.

The Destination Depends on Why You are Leaving

There is no useful universal ranking of Contentful alternatives.

If the company still wants a managed developer-oriented content backend, Sanity is an obvious platform to test, and its existing Contentful importer makes that test cheap.

Storyblok makes more sense to evaluate when the problem includes editor experience and component-driven content. Its modeling approach differs enough from Contentful’s that blindly translating the old schema would miss the point, another reason to prototype before committing.

Contentstack is explicitly targeting enterprise Contentful accounts that still want a managed composable platform. Its strongest pitch right now isn’t that migration is trivial, but that it is willing to absorb some of the commercial and engineering risk of the move.

If Salesforce ownership itself is the problem, however, moving immediately into another proprietary enterprise SaaS deserves more thought. Payload is interesting precisely because Figma has committed to keeping it open source and self-hostable. Strapi offers another variation on the same trade: more infrastructure responsibility in exchange for more control over the platform underneath the content.

And some migration assessments should end with Contentful.

A company using Salesforce heavily may conclude that the planned Data 360 and Agentforce integrations will eliminate enough custom infrastructure to make the acquisition a net win. Those integrations do not exist yet, so for now that plumbing is still custom work, but the direction is clear enough to factor into a decision. Migration would then solve a problem the company does not have.

The more likely candidates are companies with little Salesforce adoption, substantial Contentful costs or customization, an approaching redesign or renewal, or regulatory requirements that become awkward as Salesforce integration deepens.

For them, the most useful output today is not a signed migration project. It is a credible switching-cost estimate. That estimate should include not only migration effort but also the true cost of staying. A detailed review of Contentful pricing can provide a useful baseline before modeling alternatives.

Contentful’s APIs May Stay Open. Your Exit Cost May Not.

Contentful will probably look recognizably like Contentful for quite a while. Keeping its APIs, developer ecosystem, and existing customers intact serves Salesforce’s interests.

What will change faster is the context around those APIs.

Agentforce will get better Contentful integration. Data 360 will show up in more workflows. Salesforce will become more visible in enterprise sales and support. Some customers will discover that Contentful fits their Salesforce contracts remarkably well. The legal documents will eventually have to reflect whatever operational integration Salesforce actually builds.

None of those events has to be dramatic.

That is what makes bundle economics dangerous. Each individual decision can be rational: take the discount, adopt the native integration, consolidate support, save the engineering work. A few renewal cycles later, the APIs may still be open, while leaving becomes a much larger project.

For companies already wondering whether Contentful is still the right platform, the Salesforce acquisition is a good reason to stop guessing what that project would cost. Hack Club had to work out its exit price in a few days, under pressure. Contentful customers can do it now, while nothing is forcing them. Not because a migration is necessarily the right answer, but because the price of having the option tends to rise after you need it.

Disclosure: FocusReactive is a Contentful partner and also builds on Sanity, Storyblok and Payload.

Wrapping Up

Questions to ask Contentful before your next renewal

  • Which Salesforce entities can access your Customer Content, and will Salesforce personnel operate systems that process it?
  • When will the DPA and subprocessor list be updated to reflect the post-close structure?
  • Will your contracting entity, order form or support plan change at renewal?
  • What happens to your discount if you later remove Contentful from a bundled agreement?

If you want that number rather than the guess: our migration estimator scopes a Contentful replatform from your live site (content models, component inventory, hours, and a cost range), and a senior engineer reviews the output when a move is actually on the table. Most replatforming projects run over budget; 90% of ours land within the original offer, almost always because the dependencies were mapped up front.

Estimate your CMS migration, or send us the slice you think is hardest, and we will tell you what it would take.

Contentful and Salesforce: frequently asked questions

Yes. Salesforce signed a definitive agreement on June 1, 2026, and completed the acquisition on September 1, 2026, for roughly $1.5 billion in cash, net of the stake it already held.

No broad increase has been announced or publicly confirmed as of October 2026. The more likely change is that Contentful will be sold inside larger Salesforce agreements, which raises the cost of leaving rather than staying

Yes. Contentful's APIs, published plans, and European contracting entity are unchanged, and a Salesforce contract is not required to use it.

Not by itself. Contentful GmbH is still the contracting entity for European customers, and no Salesforce entity appears on the published subprocessor list. The issue to monitor is corporate control under the US CLOUD Act. Contentful's DPA gives customers 21 days to object to a newly added subprocessor.

Sanity and Storyblok are the common managed headless CMS options, Contentstack targets enterprise composable platforms, and Payload or Strapi suit teams that want open source and self-hosting. The right choice depends on why you are leaving, not on a feature comparison.

Content export is fast. The application built around the API sets the timeline. One recent migration of a site of around 2,000 pages took roughly two months. Custom apps, editorial workflows, preview, and localization are the usual cost drivers.

There is no standard price because cost depends on dependencies rather than content volume. A space with 500,000 simple records can be cheaper to move than a much smaller one with heavily customized workflows. A proof of concept on the hardest part of the implementation is the fastest route to a credible number.