Mein Take ist: Die Salesforce-Contentful-Übernahme ist kein CMS-Problem. Sie ist ein Architektur-Problem. Genauer gesagt: Sie macht sichtbar, ob du ein Architektur-Problem hast oder nicht.

4.800 Marken weltweit haben mit dem Definitive Agreement vom 1. Juni 2026 einen neuen Vertragspartner bekommen - ohne einen Vertrag unterschrieben zu haben. Das ist kein Katastrophen-Szenario, aber es ist eine Situation, die du architektonisch entweder vorbereitet oder nicht vorbereitet bist. Wer jetzt auf den Markt schaut und sieht, wie Wettbewerber Migration-Guides pushen, kann in die Falle tappen: das Problem ist nicht dein CMS. Das Problem ist, dass dein Frontend von einem CMS abhängig ist.

Das Marktsignal: 4.800 Brands, ein Vertragspartner-Wechsel

Salesforce hat Contentful übernommen. Deal-Volumen zwischen 1,0 und 1,5 Milliarden Dollar, Closing erwartet Q3 FY2027. Strategisch macht das Sinn: Contentful schließt den CMS-Slot in Salesforce Headless 360 - das Content-Management-Gap, das Agentforce bis jetzt für seine Content-Use-Cases hatte.

Was bedeutet das für Contentful-Bestandskunden?

Erstens: Kurzfristig nichts. Contentful läuft weiter. Kein Forced-Migration, kein sofortiger Pricing-Sprung, kein Roadmap-Reset zum Closing-Datum. Das Salesforce-Playbook bei Übernahmen (MuleSoft, Tableau, Slack) zeigt, dass Integration mehrere Jahre dauert.

Zweitens: Mittelfristig stehen drei echte Risiken im Raum - und keines davon lässt sich mit einem schnellen CMS-Wechsel lösen, wenn das Frontend nicht vorbereitet ist.

Was architektonisch passiert, wenn dein CMS-Layer den Owner wechselt

Wenn eine Übernahme eintritt, ändern sich nicht sofort die APIs. Aber drei Dinge verändern sich strukturell:

Roadmap-Souveränität wechselt den Besitzer. Contentful hat bis heute eine eigenständige Produkt-Roadmap verfolgt - GraphQL-First, developer-friendly, CMS-agnostisch in der Delivery. In einem Salesforce-Kontext wird diese Roadmap zunehmend von Salesforce-Produktstrategie geprägt: Agentforce-Integration, Einstein AI, Customer 360-Kompatibilität. Das ist keine schlechte Roadmap - aber sie ist nicht mehr die Roadmap, für die du ursprünglich evaluiert hast.

Pricing-Struktur wird neu verhandelt. Renewal-Verhandlungen ab 2027 laufen in einem anderen Kontext. Salesforce hat bei Tableau und MuleSoft die Pricing-Logik nach Enterprise-Suite ausgerichtet - Bundles, Platform-Fees, Connector-Lizenzen. Wer heute ein Self-Service-Team-Modell auf Contentful betreibt, sollte prüfen, ob dieser Pricing-Pfad nach dem Closing stabil bleibt.

Datenhoheit-Fragen werden komplexer. Contentful ist europäisch (Berlin), aber seit 2021 von US-Investoren (Sapphire Ventures, Salesforce Ventures) getrieben. Unter Salesforce-Ownership greifen CLOUD-Act-Risiken unmittelbarer - der US-Behörden-Zugriff auf Daten, die auf Salesforce-Infra liegen, ist rechtlich näher als bei einem unabhängigen europäischen Vendor. Das ist kein Showstopper, aber ein DACH-Enterprise-Argument, das in Procurement-Gesprächen 2027 auftauchen wird.

Drei reale Renewal-Risiken - neutral bewertet

Ich bewerte diese drei Risiken nicht dramatisch, aber ich wäre unehrlich, wenn ich sie wegretuschiere:

Pricing-Risiko: Je nach Vertragssituation und Nutzungsvolumen kann der Renewal 2027 unter neuen Bedingungen liegen. Wer jetzt Klarheit braucht, sollte das schriftlich klären - nicht warten.

Roadmap-Risiko: Contentfuls Feature-Kadenz (neue Content-Types, Content-Source-API, Edge-Delivery) war engineering-getrieben. Ob das so bleibt, wenn Salesforce-Produkt-Management übernimmt, ist offen. Für Teams, die stark auf Contentful-Native-Features aufgebaut haben, ist das eine Abhängigkeit, die sie bewerten sollten.

Datenhoheit-Risiko: Für regulated industries (Finanzdienstleistung, öffentliche Hand, Gesundheit) ist die CLOUD-Act-Exposition relevant. Das ist kein unmittelbares Compliance-Problem, aber einer, der in Risikoregistern landet.

Was alle drei Risiken verbindet: Sie treffen dich nur dann hart, wenn dein Frontend so tief mit Contentful verwoben ist, dass ein Wechsel einen Storefront-Rewrite bedeutet. Wenn das nicht der Fall ist, hast du Optionen. Wenn es der Fall ist - dann ist das das eigentliche Problem.

Die Architektur-Antwort: Frontend-Layer als CMS-Container

Die Wettbewerber-Reaktion auf die Übernahme ist vorhersehbar: Migration-Guides. "Wechsle von Contentful zu uns." Das ist eine legitime Reaktion - wenn du tatsächlich wechseln willst. Aber sie löst das strukturelle Problem nicht.

Das strukturelle Problem ist: Wer einen 1-zu-1-CMS-Tausch macht, landet in 3 Jahren im selben Dilemma - mit einem anderen CMS, das von einem anderen Investor übernommen wird, mit einer anderen Roadmap, einem anderen Pricing-Modell.

Die architektonische Antwort ist eine andere: Der Frontend-Layer muss CMS-agnostisch sein. Nicht weil CMS-Wechsel wahrscheinlich ist - sondern weil die Option dazu existieren muss, ohne dass ein Storefront-Rewrite daraus folgt.

Was das konkret bedeutet: Der Content-Delivery-Layer muss über einen abstrakten Handler laufen, nicht direkt über Contentful-SDK-Aufrufe im Frontend. Inhalte kommen rein, das Frontend weiß nicht (und darf nicht wissen), ob sie aus Contentful, Hygraph, Storyblok oder einem selbst-gehosteten Strapi kommen. Der Composable Headless Frontend ist der Layer, der diese Abstraktion real macht.

Der Orchestr-Handler-Pattern: wie CMS-Agnostizität technisch aussieht

[Sebastian-Tech-Box]

CMS-Agnostizität im Frontend bedeutet nicht, keine CMS-Integration zu haben. Es bedeutet, die Integration so zu strukturieren, dass der CMS-Vendor austauschbar ist. Das Orchestr-Handler-Pattern macht das operational:

// Abstraktes Content-Interface — CMS-unabhängig
interface ContentHandler {
  getPage(slug: string, locale: string): Promise<PageContent>
  getEntries(type: string, filters: ContentFilters): Promise<ContentEntry[]>
  getAsset(id: string): Promise<Asset>
}

// Contentful-Handler — eine Implementierung von vielen
class ContentfulHandler implements ContentHandler {
  private client: ContentfulClient

  async getPage(slug: string, locale: string): Promise<PageContent> {
    const entry = await this.client.getEntries({
      content_type: 'page',
      'fields.slug': slug,
      locale: locale
    })
    return this.mapToPageContent(entry.items[0])
  }
}

// Frontend-Orchestrator bindet an Interface, nicht an SDK
class FrontendOrchestrator {
  constructor(private contentHandler: ContentHandler) {}

  async renderPage(slug: string): Promise<RenderedPage> {
    // Frontend ruft Interface auf — nicht Contentful direkt
    const content = await this.contentHandler.getPage(slug, this.locale)
    return this.renderComponents(content)
  }
}

Der Austausch bedeutet: `new HygraphHandler()` statt `new ContentfulHandler()`. Die Frontend-Components, die Routing-Logik, die Component-Library - nichts davon ändert sich. Das ist kein theoretisches Muster. Das ist der Mechanismus, mit dem das Agentic Frontend Management Platform-Konzept CMS-Unabhängigkeit in der Praxis umsetzt.

[Ende Tech-Box]

Visual Page Builder, der nicht am CMS hängt

Der zweite Schmerzpunkt bei CMS-Wechseln ist oft nicht die Content-Delivery - sondern der Editor. Wenn dein Visual Page Builder tief in Contentful integriert ist (Contentful Studio, Live Preview, Contentful-native Visual Editor), dann ist ein CMS-Wechsel ein Editor-Wechsel. Das bedeutet: Editor-Workflows neu definieren, Marketing-Teams neu schulen, Approval-Prozesse neu aufsetzen.

Die Composable Visual Page Builder-Architektur löst dieses Problem auf der Ebene, wo es entsteht: Der Editor lebt auf dem Frontend-Layer - er bezieht Content von wherever du willst. Heute Contentful. Morgen Hygraph. Übermorgen self-hosted. Der Marketing-Editor-Workflow ändert sich nicht.

Das ist der Unterschied zwischen "CMS-gebundenem Editor" (Contentful Studio, Storyblok Studio, Sanity Studio - alle CMS-spezifisch) und einem Editor auf dem Frontend-Layer. Letzterer gibt dir die Optionalität, die du brauchst.

Was du jetzt tun kannst - ohne CMS zu wechseln

Ich empfehle niemandem, Contentful heute zu kündigen. Das ist nicht die richtige Reaktion auf eine Übernahme, die noch nicht abgeschlossen ist. Was ich empfehle: Die nächsten 30 Tage für eine technische Bewertung nutzen.

Konkrete Schritte:

1. Frontend-Coupling-Audit. Wie viele direkte Contentful-SDK-Aufrufe gibt es im Frontend-Code? Wo sind Content-Type-IDs hardgecoded? Wo ist Contentful-Preview-SDK direkt eingebunden? Das ist die technische Schuld, die einen CMS-Wechsel teuer macht.

2. Editor-Abhängigkeits-Check. Nutzt das Marketing-Team Contentful-native Features (Contentful Studio, Live Preview, Scheduled Publishing), die tief in Contentful-Infra verankert sind? Wenn ja: Was ist der Migrations-Aufwand pro Feature?

3. Pricing-Transparenz schaffen. Gibt es schriftliche Zusagen zum Pricing nach Closing? Falls nicht: Jetzt nachfragen, nicht nach dem Closing.

4. Datenhoheit-Status klären. Wo liegen eure Contentful-Daten? EU-Region oder US-Region? Gibt es Data-Residency-Commitments im Vertrag, die unter Salesforce-Ownership Bestand haben?

Das Ziel dieser vier Schritte ist nicht, zu flüchten. Das Ziel ist, Optionalität herzustellen. Wer weiss, wie aufwändig ein Wechsel wäre, kann besser verhandeln.

CTA: 30-Minuten Architektur-Sparring

Wenn du die oben genannten vier Schritte durchgehen willst und konkrete Einschätzungen brauchst - für deinen spezifischen Stack, nicht theoretisch - dann ist ein 30-Minuten-Architektur-Sparring der schnellste Weg dazu.

Wir gehen dabei durch: welche Teile eures Frontends CMS-spezifisch sind, was ein agnostischer Umbau kosten würde, und ob der jetzt sinnvoll ist oder nicht. Kein Sales-Pitch. Eine technische Einschätzung.

Und für den Procurement-Kontext: Die Checklist "8 Fragen, die du beim CMS-Renewal stellen solltest" ist ein separates Dokument - kommt als Slot 4 dieser Content-Welle.

Verwandte Themen: Contentful Alternative: Laioutr Compared (2026) · Headless CMS for Next.js eCommerce in 2026