Wenn dein Konkurrent dir gerade einen Migration-Guide pusht, lös das nicht mit einem Migration-Gegen-Guide. Lös es mit einem Architekturansatz.

Das ist nicht rhetorisch gemeint. Der Unterschied zwischen einer Frontend Management Platform und einem CMS-Wechsel ist ein architektonischer, kein Marketing-Unterschied. Ein CMS-Wechsel ersetzt eine Infrastruktur-Komponente durch eine andere. Eine FMP ändert die Art, wie der Frontend-Layer auf Infrastruktur-Komponenten zugreift. Das klingt subtil, hat aber grundlegend verschiedene Konsequenzen - für Implementierungsaufwand, Risiko und Optionalität.

Dieser Post ist für Solution Architects und CTOs, die in den nächsten 90 Tagen eine konkrete Entscheidung treffen müssen: Reagieren wir auf die Salesforce-Contentful-Übernahme mit einem CMS-Wechsel, oder reagieren wir mit einer Architektur-Entscheidung?

Was ein CMS-Wechsel tatsächlich kostet

Die Wettbewerber-Seite verspricht "einfache Migration". Und für die Daten-Migration stimmt das in vielen Fällen - Contentful hat offene Export-APIs, und Tools wie `contentful-export` generieren valides JSON, das mit der entsprechenden Konverter-Logik in ein Ziel-CMS importierbar ist.

Das eigentliche Kosten-Problem ist nicht der Daten-Transfer. Es sind drei andere Layer:

Layer 1: Frontend-Code-Anpassung

Jeder CMS-Wechsel bedeutet, dass die SDK-Aufrufe im Frontend-Code geändert werden. Das klingt nach einer trivialen Suchen-und-Ersetzen-Operation. In der Praxis bedeutet es:

// Vorher: Contentful-SDK direkt
import { createClient } from 'contentful'

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

// Nachher: 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}" }) { ... } }`)

Das ist nicht eine Änderung. Das ist eine Änderung pro Content-Type pro Seite des Storefronts. Bei einem Mid-Market-Frontend mit 15 - 30 unterschiedlichen Content-Types und 50 - 80 Seiten sind das mehrere Wochen Engineering-Arbeit.

Layer 2: Content-Model-Mapping

Content-Models sind nie 1-zu-1 kompatibel. Contentful hat Rich-Text als eingebettetes JSON-Format; Hygraph liefert Slate-AST; Storyblok arbeitet mit Block-Nested-Components; Sanity hat GROQ. Jedes Ziel-CMS hat ein anderes Modell für verschachtelte Inhalte, Referenzen zwischen Einträgen, Asset-Delivery und Localisation.

Das Mapping dieser Unterschiede ist der unsichtbare Aufwand bei jeder Migration. Er wird in Migration-Guides selten quantifiziert.

Layer 3: Editor-Workflow-Disruption

Marketing-Teams haben Editor-Workflows in Contentful aufgebaut: Approval-Prozesse, Scheduled-Publishing-Regeln, Content-Modeling-Konventionen, Preview-URLs. Jeder neue CMS hat eigene Editor-UX, eigene Permissions-Struktur, eigene Preview-Logik. Die Schulungszeit für Marketing-Teams ist in keinem Migration-Guide als Cost-of-Migration ausgewiesen.

Der kombinierte Aufwand - Frontend-Anpassung + Content-Model-Mapping + Editor-Workflow-Disruption - ist in DACH-Enterprise-Projekten typischerweise 3 - 6 Monate. Das ist der reale Preis eines CMS-Wechsels.

Was eine FMP stattdessen macht

Eine Frontend Management Platform operiert auf einer anderen Schicht. Sie ersetzt keine CMS-Infrastruktur. Sie abstrahiert den Zugriff auf diese Infrastruktur - so dass der Frontend-Layer CMS-agnostisch wird.

Der kritische Unterschied ist die Render-Boundary. Bei einem direkt integrierten CMS hat jede Seite, jede Komponente, jedes Page-Template explizites Wissen, aus welchem CMS der Content kommt. Die Render-Boundary liegt im Component-Code selbst.

Bei einer FMP liegt die Render-Boundary im Platform-Layer. Die Component kennt kein CMS - sie kennt ein Content-Interface. Das CMS ist eine Implementierung hinter diesem Interface.

// FMP-Ansatz: Component kennt kein CMS
interface ContentEntry {
  id: string
  type: string
  fields: Record<string, unknown>
  assets: Asset[]
  locale: string
}

// Hero-Component: CMS-agnostisch
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-Abstraktion
type CMSHandler = {
  fetchEntry(slug: string, type: string, locale: string): Promise<ContentEntry>
  fetchCollection(type: string, locale: string, filter?: Filter): Promise<ContentEntry[]>
}

// Contentful-Implementierung
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-Implementierung — gleiches Interface
const hygraphHandler: CMSHandler = {
  async fetchEntry(slug, type, locale) {
    const data = await hygraphClient.request(FETCH_ENTRY_QUERY, { slug, type, locale })
    return mapHygraphEntry(data.entry)
  },
  // ...
}

Der Wechsel von Contentful zu Hygraph ist in dieser Architektur: `setCMSHandler(hygraphHandler)`. Keine Component-Änderungen. Keine Template-Updates. Keine Editor-Workflow-Disruption, wenn der Editor auf dem Frontend-Layer lebt (nicht im CMS).

Render-Boundary-Semantik: warum die Grenze entscheidend ist

Die Render-Boundary ist die Linie, an der der Frontend-Code aufhört, CMS-Wissen zu haben. Je tiefer diese Grenze im Komponent-Baum liegt, desto teurer ist ein CMS-Wechsel.

Drei Render-Boundary-Positionen, von teuer zu günstig:

Position 1 - im Component (teuerste): Jede Komponente enthält SDK-Aufrufe. Content-Type-IDs sind hardgecoded. Ein CMS-Wechsel erfordert Änderungen in hunderten von Dateien.

Position 2 - im Page-Template: SDK-Aufrufe sind in Page-Templates gebündelt, nicht in einzelnen Components. Ein CMS-Wechsel erfordert Änderungen in 20 - 40 Template-Dateien. Besser, aber immer noch aufwändig.

Position 3 - im Platform-Handler (günstigste): Ein einziger Handler kapselt alle CMS-Interaktionen. Components und Templates kennen nur `ContentEntry`. Ein CMS-Wechsel ist eine Implementierungs-Änderung in einem einzigen Module. Die Agentic Frontend Management Platform setzt die Render-Boundary systematisch auf Position 3.

Das ist nicht nur ein Refactoring-Ziel. Es ist eine strategische Architektur-Entscheidung, die bestimmt, wie hoch deine Switching-Kosten sind - für CMS, aber auch für Search-Backends, Personalisation-Engines, Commerce-APIs. Der Composable Headless Frontend ist der Layer, auf dem diese Abstraktion gilt.

Der konkrete Entscheidungsbaum für Solution Architects

Wenn du als Solution Architect eine Empfehlung für die nächsten 90 Tage geben musst:

Wenn das Frontend heute direkt an Contentful gekoppelt ist (Position 1 oder 2):

• Short-Term-Empfehlung: Refactoring auf Handler-Abstraktion, bevor irgendein CMS-Wechsel diskutiert wird. Ein CMS-Wechsel auf dem aktuellen Stand ist ein 3 - 6-Monats-Projekt. Refactoring auf Handler-Abstraktion ist 4 - 8 Wochen.
• Medium-Term: Nach dem Refactoring ist ein CMS-Wechsel ein 2 - 4-Wochen-Projekt, falls nötig.

Wenn das Frontend bereits einen abstrakten Content-Layer hat (Position 3 oder ähnlich):

• Short-Term: Die CMS-Entscheidung ist strategisch (Pricing, Roadmap, Sovereignty), nicht technisch getrieben. Du hast Zeit für eine fundierte Evaluation ohne Zeitdruck.
• Medium-Term: Vendor-Vergleich mit echten Konditionen (Renewal-Pricing, Roadmap-Commitments, Data-Residency) - ohne die Implementierungskosten als dominierenden Faktor.

Wenn das Frontend auf einer FMP aufgebaut ist:

• Die Frage ist nicht "welches CMS wechsle ich zu", sondern "welches CMS ergibt kurz- und mittelfristig die beste Kombination aus Pricing, Roadmap und Compliance" - weil der Wechsel jederzeit machbar ist, ohne Storefront-Rewrite.

Was FMP nicht ist

Zur Klarstellung, weil der Begriff aktuell viele Bedeutungen trägt:

Eine FMP ist kein Headless CMS. Sie speichert keinen Content. Sie hat kein eigenes Content-Model-System. Sie ist kein DAM. Sie ist kein PIM.

Eine FMP ist der Layer zwischen dem Frontend-Code und den Content-/Commerce-/Data-Backends. Sie ist der Rendering-Layer, der Handler-Layer, der Visual-Editor-Layer, der Component-Library-Layer. Sie macht die Backends austauschbar - CMS, Commerce, Search, Personalisation.

Der Unterschied ist konzeptuell, aber er hat konkrete Auswirkungen: Wer eine FMP kauft, kauft keine CMS-Alternative. Er kauft die Fähigkeit, CMS-Alternativen zu haben, ohne dafür zu zahlen.

Fazit

Wenn die Antwort auf eine CMS-Übernahme ein CMS-Wechsel ist, löst du ein Symptom, nicht das Problem. Das Problem ist architektonische Abhängigkeit. Die Lösung ist eine Render-Boundary, die diese Abhängigkeit eliminiert.

Eine Frontend Management Platform ist das Werkzeug, das diese Boundary systematisch etabliert - und damit den CMS-Wechsel von einem Projekt zu einem Konfigurationsschritt macht.

Verwandte Themen: Wenn der CMS-Layer den Besitzer wechselt · Salesforce kauft Contentful: Warum die Frontend-Lücke bleibt · Headless CMS für Next.js eCommerce 2026