Wie ihr ohne Risiko ein Legacy CMS System zu einem Headless-CMS migriert

Die gute alte Welt

Was einst als vollintegrierte Content-Management-Lösung und All-in-one-System begann, kann in der schnelllebigen digitalen Welt zunehmend zum Innovationshemmer werden. Neue Ausspielkanäle wie Online-Plattformen und native Apps erfordern, dass CMS-Daten maschinenlesbar und flexibel transformierbar sind, um sie an die jeweiligen Bedürfnisse anzupassen.

So soll beispielsweise ein neuer Blog-Beitrag automatisch auf Bluesky veröffentlicht und als Push-Nachricht in einer mobilen Shopping-App angezeigt werden. Für abgeschlossene Systeme ist dies oft eine schwierige Herausforderung.

Der Wechsel zu einem modernen CMS ist jedoch auch mit Herausforderungen verbunden: Der anfängliche Aufwand für Konfiguration, Schulung und Datenmigration kann hoch sein, ebenso wie die Hürde, einen neuen Content-Editor bei den Usern zu etablieren. Beispiele für moderne Headless-CMS-Systeme sind FirstSpirit CaaS von Crownpeak, Contentful oder Magnolia, die wir in weiteren Blog-Beiträgen bereits detailliert behandelt haben.

In diesem Blog-Beitrag konzentriere ich mich uns auf die planbare, nachhaltige und möglichst reibungslose Migration einer großen Anzahl an Inhalten zu einem neuen CMS-System.

Die Inkrementelle CMS-Einführung

Gehen wir von einem klassischen CMS aus, das über viele Jahre hinweg regelmäßig mit relevanten Inhalten gefüllt wurde und beispielsweise für Marketingzwecke, Bezahlkunden oder SEO-Optimierungen von großer Bedeutung ist. Die Webseite ist hochoptimiert, jedoch stark an das CMS gekoppelt. Wenn beispielsweise auf der Webseite ein HTML-Tag geändert werden muss, um eine Überschrift prominenter anzuzeigen, muss dies im CMS im HTML-Template erfolgen – selbst wenn sich der Text der Überschrift nicht ändert.

In einem ersten Schritt müssen daher das CMS, die Inhalte und die Darstellung in Form der Website voneinander entkoppelt werden. Hierzu wird eine Schnittstelle eingeführt, die als neuer Vertrag zwischen dem Legacy-CMS und dem Frontend dient. Dabei können beide Systeme unterschiedliche Datenstrukturen definieren.

Wichtige Aspekte für den Frontend-API-Vertrag sind:

• Nur die notwendigen Daten bereitstellen (zum Beispiel keine unnötigen Metadaten).
• Alle relevanten, verknüpften Daten werden mitgeliefert.
• Eine einfache Struktur, die top-down verarbeitet werden kann.

API Contract
Ein API-Vertrag (auch API-Contract genannt) beschreibt die formale Vereinbarung oder Spezifikation darüber, wie zwei Systeme oder Anwendungen über eine API (Application Programming Interface) miteinander kommunizieren. Er definiert die Struktur der Anfragen und Antworten, die die API erwartet beziehungsweise liefert.

Aber: „Mein CMS kann nur HTML generieren, aber keine strukturierten Daten!”

Auch HTML ist strukturiert und maschinenlesbar. Wenn HTML generiert werden kann, ist es durchaus möglich, alternativ beispielsweise JSON zu erstellen, das von der neuen Content-API konsumiert werden kann.

Aber: „Jetzt, wo mein altes CMS und das Frontend entkoppelt sind, werden neue Features super schnell umgesetzt. Eigentlich brauche ich kein neues CMS mehr ...”

Herzlichen Glückwunsch! Oft ist es auch möglich, ein bestehendes CMS mithilfe eines neuen Moduls zu einem Headless-CMS zu erweitern. Ein Beispiel hierfür ist das CMS FirstSpirit, das mithilfe der Module CaaS oder Headless2Go eine Headless-Architektur unterstützt.

No Risk. Much Fun.

Ihr wollt nun mit der Einführung des CMS weitermachen. Ihr seht zahlreiche Vorteile für die Redakteurinnen und Redakteure, beispielsweise einen modernen WYSIWYG-Editor, eine aufgeräumte Drag-and-Drop-Bibliothek für Seitenelemente, neue Storytelling-Konzepte oder einen Workflow für die Ausspielung der Inhalte auf mehreren Kanälen.

Oft entsteht ein hoher Aufwand bei der Migration der Daten vom alten ins neue CMS. Dies bietet jedoch auch die Gelegenheit, die vorhandenen Daten zu optimieren, nicht mehr benötigte Inhalte zu entfernen und technische Schulden abzubauen. Wenn alte Abhängigkeiten im Code entfernt werden können, lässt sich die Ladezeit einer Webseite häufig beschleunigen, was wiederum positive SEO-Effekte mit sich bringt.

Grundsätzlich kann zwischen zwei gängigen Arten der Migration unterschieden werden:

• Big Bang Migration
  Die Daten werden einmalig vom alten ins neue CMS übertragen. Diese Methode eignet sich besonders für kleinere Datenmengen. Tritt ein Fehler auf, muss die Migration erneut durchgeführt werden.
• Permanent Migration
  Änderungen im alten CMS werden in Echtzeit ins neue CMS gespiegelt. Das alte CMS bleibt führend, während das neue CMS zunächst nur lesend genutzt wird.

Eine permanente Migration eignet sich besonders für große Datenmengen und eine agile Arbeitsweise, bei der Ergebnisse schnell produktiv gehen sollen und wirtschaftlichen Mehrwert generieren. In einem Projekt wurden beispielsweise zunächst bestimmte Live-Blog-Inhalte auf das neue CMS umgestellt, während Agenturmeldungen weiterhin aus dem alten CMS ausgespielt wurden. Die Zufriedenheit der Redakteurinnen und Redakteure über den neuen, deutlich einfacheren Editor war enorm, und der Effizienzgewinn bei den neu erstellten Inhalten messbar.

Dies gelang auch dank des schnellen Feedbacks von Key-Usern, die das neue CMS als Erste im produktiven Einsatz nutzten und frühzeitig Optimierungsvorschläge einbrachten. Diese ersten User fungierten als Multiplikatoren und begeisterten ihre Kollegen, was zu einer hohen Akzeptanz der neuen Software führte.

Nicht nur Migrationen: Headless in der Anwendung

Bei der Einführung einer neuen Kundenwebseite wurde von Anfang an eine Headless-Architektur genutzt, um Inhalte flexibel und kanalübergreifend bereitzustellen. Die Inhalte werden im FirstSpirit CMS gepflegt und beim Publizieren über das Headless2Go-Modul automatisch in Elasticsearch gespeichert. Das Next.js-Frontend greift in Echtzeit auf diese Daten zu, bereitet sie für das Rendering auf und liefert fertige Seiten direkt an die Nutzer aus (Server-Side-Rendering zur SEO-Optimierung). Nach der initialen Ausspielung lädt die Website neue Inhalte über eine JSON-Schnittstelle nach und rendert sie direkt beim Nutzer – schnell und effizient.

Die richtigen Weichen stellen
Ein weiterer Vorteil der Content-API als Bindeglied zwischen CMS und Ausgabekanälen ist ihre Funktion als Weiche. So kann beispielsweise festgelegt werden, dass nur bestimmte Bereiche der Website aus dem neuen CMS bespielt werden oder dass die neue Seite zunächst nur einer definierten Gruppe von „Beta“-Nutzern oder Testern zur Verfügung gestellt wird.

Zukunftssicher aufgestellt

Egal, welche neuen Anforderungen in der Zukunft auf euch zukommen – mit einer entkoppelten Architektur für euren Onlineauftritt seid ihr bestens gerüstet:

• Ein neues Design für Ihre Webseite oder ein neuer Ausgabekanal kann ohne Änderungen am CMS umgesetzt werden.
• Erweiterungen im CMS können vorgenommen werden, ohne dass dies die Konsumenten der Content-API beeinträchtigt.

Content API: Backend-for-Frontend
Beim Backend-for-Frontend-Architekturmuster werden die Aufbereitung der Daten für die Ausgabe und die Präsentation im CMS entkoppelt, ähnlich wie bei der Entkopplung von Inhalten. Für jeden Kanal werden die Daten maßgeschneidert bereitgestellt. Dadurch wird die Komplexität reduziert und eine unnötige Datenlast – etwa bei Single-Page-Applications – vermieden. Das Backend führt dabei unterschiedliche Datenquellen zusammen und stellt sie über eine klar definierte, einheitliche Schnittstelle zur Verfügung.

Unsere Business Line Digital Experience bietet eurem Unternehmen die ideale Kombination aus strategischer und fachlicher Beratung, tiefem Branchenwissen, vielfältiger Projekterfahrung und technischem Know-how für CMS-Migrationen jeglicher Größe.