If your competitor is pushing a migration guide at you right now, do not respond with a counter-migration guide. Respond with an architecture approach.

That is not rhetorical. The difference between a Frontend Management Platform and a CMS swap is architectural, not a marketing distinction. A CMS swap replaces one infrastructure component with another. An FMP changes how the frontend layer accesses infrastructure components. That sounds subtle but has fundamentally different consequences - for implementation effort, risk, and optionality.

This post is for solution architects and CTOs who have a concrete decision to make in the next 90 days: do we respond to the Salesforce-Contentful acquisition with a CMS swap, or with an architecture decision?

What a CMS swap actually costs

The competitor pitch promises "simple migration". And for data migration that is often true - Contentful has open export APIs, and tools like `contentful-export` generate valid JSON that is importable into a target CMS with the right converter logic.

The actual cost problem is not the data transfer. It is three other layers:

Layer 1: Frontend code changes

Every CMS swap means that SDK calls in frontend code must change. That sounds like a trivial search-and-replace operation. In practice it means:

// Before: Contentful SDK directly
import { createClient } from 'contentful'

const client = createClient({ space: '...', accessToken: '...' })
const entries = await client.getEntries({ content_type: 'blogPost', 'fields.slug': slug })

// After: Hygraph client
import { GraphQLClient } from 'graphql-request'

const hygraph = new GraphQLClient('https://eu-west-2.cdn.hygraph.com/content/...', {
  headers: { authorization: `Bearer ${token}` }
})
const { blogPost } = await hygraph.request(`query { blogPost(where: { slug: "${slug}" }) { ... } }`)

That is not one change. That is one change per content type per page of the storefront. A mid-market frontend with 15 - 30 different content types and 50 - 80 pages is several weeks of engineering effort.

Layer 2: Content model mapping

Content models are never 1-to-1 compatible. Contentful has rich text as embedded JSON; Hygraph delivers Slate AST; Storyblok works with block-nested components; Sanity has GROQ. Every target CMS has a different model for nested content, cross-entry references, asset delivery, and localisation.

Mapping these differences is the invisible effort in every migration. It is rarely quantified in migration guides.

Layer 3: Editor workflow disruption

Marketing teams have built editor workflows in Contentful: approval processes, scheduled publishing rules, content modelling conventions, preview URLs. Every new CMS has its own editor UX, its own permissions structure, its own preview logic. Training time for marketing teams is not listed as a cost of migration in any migration guide.

The combined effort - frontend changes + content model mapping + editor workflow disruption - in DACH enterprise projects is typically 3 - 6 months. That is the real price of a CMS swap.

What an FMP does instead

A Frontend Management Platform operates on a different layer. It does not replace CMS infrastructure. It abstracts access to that infrastructure - so that the frontend layer becomes CMS-agnostic.

The critical difference is the render boundary. With a directly integrated CMS, every page, every component, every page template has explicit knowledge of which CMS content comes from. The render boundary sits inside the component code itself.

With an FMP, the render boundary sits in the platform layer. The component knows no CMS - it knows a content interface. The CMS is one implementation behind that interface.

// FMP approach: component knows no CMS
interface ContentEntry {
  id: string
  type: string
  fields: Record<string, unknown>
  assets: Asset[]
  locale: string
}

// Hero component: CMS-agnostic
const HeroComponent: React.FC<{ entry: ContentEntry }> = ({ entry }) => {
  const { headline, subtext, ctaUrl, ctaLabel, image } = entry.fields

  return (
    <section className="hero">
      <h1>{String(headline)}</h1>
      <p>{String(subtext)}</p>
      <a href={String(ctaUrl)}>{String(ctaLabel)}</a>
      {image && <Image asset={image as Asset} priority />}
    </section>
  )
}

// Platform layer: handler abstraction
type CMSHandler = {
  fetchEntry(slug: string, type: string, locale: string): Promise<ContentEntry>
  fetchCollection(type: string, locale: string, filter?: Filter): Promise<ContentEntry[]>
}

// Contentful implementation
const contentfulHandler: CMSHandler = {
  async fetchEntry(slug, type, locale) {
    const response = await contentfulClient.getEntries({
      content_type: type, 'fields.slug': slug, locale
    })
    return mapContentfulEntry(response.items[0])
  },
  // ...
}

// Hygraph implementation — same interface
const hygraphHandler: CMSHandler = {
  async fetchEntry(slug, type, locale) {
    const data = await hygraphClient.request(FETCH_ENTRY_QUERY, { slug, type, locale })
    return mapHygraphEntry(data.entry)
  },
  // ...
}

Switching from Contentful to Hygraph in this architecture is: `setCMSHandler(hygraphHandler)`. No component changes. No template updates. No editor workflow disruption when the editor lives on the frontend layer (not in the CMS).

Render boundary semantics: why the line is decisive

The render boundary is the line where frontend code stops having CMS knowledge. The deeper this boundary sits in the component tree, the more expensive a CMS swap becomes.

Three render boundary positions, from expensive to cheap:

Position 1 - in the component (most expensive): Every component contains SDK calls. Content type IDs are hardcoded. A CMS swap requires changes across hundreds of files.

Position 2 - in the page template: SDK calls are bundled in page templates, not in individual components. A CMS swap requires changes in 20 - 40 template files. Better, but still significant effort.

Position 3 - in the platform handler (cheapest): A single handler encapsulates all CMS interactions. Components and templates know only `ContentEntry`. A CMS swap is an implementation change in a single module. The Agentic Frontend Management Platform places the render boundary systematically at Position 3.

This is not just a refactoring goal. It is a strategic architecture decision that determines how high your switching costs are - for CMS, but also for search backends, personalisation engines, and commerce APIs. The Composable Headless Frontend is the layer on which this abstraction holds.

The concrete decision tree for solution architects

If you are a solution architect who needs to make a recommendation for the next 90 days:

If the frontend is today directly coupled to Contentful (Position 1 or 2):

• Short-term recommendation: refactor to handler abstraction before any CMS swap is discussed. A CMS swap in the current state is a 3 - 6 month project. Refactoring to handler abstraction is 4 - 8 weeks.
• Medium-term: after the refactor, a CMS swap is a 2 - 4 week project if needed.

If the frontend already has an abstract content layer (Position 3 or similar):

• Short-term: the CMS decision is strategic (pricing, roadmap, sovereignty), not technically driven. You have time for a well-founded evaluation without time pressure.
• Medium-term: vendor comparison with real terms (renewal pricing, roadmap commitments, data residency) - without implementation costs as the dominant factor.

If the frontend is built on an FMP:

• The question is not "which CMS do I switch to", but "which CMS delivers the best combination of pricing, roadmap, and compliance short- and medium-term" - because the switch is feasible at any time without a storefront rewrite.

What an FMP is not

For clarity, because the term currently carries many meanings:

An FMP is not a headless CMS. It does not store content. It has no content model system of its own. It is not a DAM. It is not a PIM.

An FMP is the layer between the frontend code and the content/commerce/data backends. It is the rendering layer, the handler layer, the visual editor layer, the component library layer. It makes backends interchangeable - CMS, commerce, search, personalisation.

The difference is conceptual, but it has concrete consequences: whoever buys an FMP does not buy a CMS alternative. They buy the ability to have CMS alternatives without paying for it.

Conclusion

If the answer to a CMS acquisition is a CMS swap, you are solving a symptom, not the problem. The problem is architectural dependency. The solution is a render boundary that eliminates that dependency.

A Frontend Management Platform is the tool that establishes this boundary systematically - and makes a CMS swap a configuration step rather than a project.

Related: When your CMS layer changes hands · Salesforce Buys Contentful: The Frontend-Layer Gap · Headless CMS for Next.js eCommerce 2026