Wie führen Sie ein CMS-Replatforming 2026 durch? Der umfassende Leitfaden
Kurzantwort: Ein CMS-Replatforming gelingt in sechs Schritten: Bedarfsanalyse mit Content-Inventur, Architekturentscheidung, neues Content-Modell, automatisierte (heute oft KI-gestützte) Content-Migration, SEO-Migration mit vollständigem 301-Redirect-Mapping und ein schrittweiser Go-live. Wer bereichsweise nach dem Strangler-Pattern migriert und die Barrierefreiheitspflichten des BFSG von Anfang an einplant, senkt das Geschäftsrisiko deutlich.
Irgendwann hält das CMS nicht mehr mit dem Unternehmen Schritt: Änderungen dauern zu lange, Integrationen werden teuer, und das Marketing braucht für einfache Aktualisierungen Entwickler. Dieser Leitfaden zeigt, wie Sie Bedarf analysieren, eine Plattform wählen und Inhalte sowie Rankings sicher migrieren.
Das Wichtigste in Kürze:
CMS-Replatforming ist eine Architekturentscheidung: Es verändert, wie Inhalte gespeichert, bearbeitet und an andere Systeme ausgeliefert werden.
Headless- und hybride CMS trennen Inhalt von Darstellung und bedienen mehrere Kanäle über APIs.
Die größten Risiken liegen in der SEO-Migration: Laut Google sollten 301-Weiterleitungen mindestens ein Jahr bestehen bleiben.
Seit dem 28.06.2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) für viele B2C-Websites und Onlineshops. Das neue CMS muss barrierefreie Inhalte technisch erzwingen können.
Eine schrittweise Migration (Strangler-Pattern) und KI-gestützte Content-Transformation reduzieren Risiko und manuellen Aufwand.
Was bedeutet CMS-Replatforming?
CMS-Replatforming ist der Umzug von Inhalten, Content-Prozessen und Integrationen auf ein Content-Management-System, das besser zu den aktuellen Anforderungen passt. Anders als ein Redesign betrifft es das Fundament: Datenmodell, Redaktionsprozesse und Schnittstellen zu E-Commerce, CRM oder Apps.
| Vorhaben | Was ändert sich? | Typisches Risiko |
|---|---|---|
| Redesign | Layout, UX, Frontend | Conversion-Verluste durch neue Nutzerführung |
| Relaunch | Design, Inhalte, oft URLs | Ranking-Verluste bei geänderten URLs |
| Replatforming | CMS, Datenmodell, Integrationen, oft auch URLs und Frontend | Datenverluste, SEO-Einbruch, Prozessbrüche |
Headless CMS bezeichnet ein Content-Management-System, das Inhalte ausschließlich strukturiert über APIs ausliefert und kein eigenes Frontend besitzt. Ein hybrides CMS bietet zusätzlich visuelle Bearbeitung und Seitenvorschau, ein monolithisches CMS (z. B. klassisches WordPress) verbindet Backend und Darstellung in einem System.
Wann lohnt sich ein CMS-Replatforming?
Ein Replatforming lohnt sich, wenn das bestehende System Wachstum, Integrationen oder Compliance messbar behindert. Typische Signale:
- Änderungen an der Seitenstruktur erfordern wochenlange Wartezeiten auf die IT.
- Das CMS bewältigt keine Multi-Language- oder Multi-Brand-Szenarien.
- Jede neue Anbindung (Marketing Automation, Analytics, PIM) verlangt teure Individualentwicklung.
- Ladezeiten und Sicherheitsniveau genügen nicht mehr.
- Der Betrieb des Altsystems kostet mehr als der Umstieg, etwa weil Versionen auslaufen.
- Das System kann die Anforderungen an Barrierefreiheit nicht mit vertretbarem Aufwand erfüllen.
Wie führen Sie ein CMS-Replatforming Schritt für Schritt durch?
Ein Replatforming folgt sechs Phasen, von der Inventur bis zum Hypercare. So gehen die Univio-Teams in Projekten vor:
| Phase | Ziel | Ergebnis |
|---|---|---|
| 1. Analyse und Inventur | Ist-Zustand verstehen | Content-Inventar, Anforderungskatalog, Barrierefreiheits-Audit |
| 2. Architektur | Zielplattform wählen | Architekturentwurf, CMS-Auswahl, Migrationsstrategie |
| 3. Content-Modell | Struktur neu denken | Content-Typen, Felder, Taxonomie, Komponenten |
| 4. Content-Migration | Inhalte übertragen | Migrationsskripte, bereinigte und angereicherte Inhalte |
| 5. SEO-Migration | Sichtbarkeit erhalten | Redirect-Mapping, Crawl-Vergleich, Monitoring |
| 6. Test und Go-live | Risiko begrenzen | Abnahme, schrittweiser Rollout, Hypercare |
Die Dauer hängt vor allem von Content-Menge, Integrationen und Sprachversionen ab. Planen Sie Phase 1 und 3 großzügig: Fehler im Content-Modell sind später am teuersten.
1. Bedarfsanalyse und Content-Inventur
Prüfen Sie vor der Technologiewahl, was Sie tatsächlich besitzen. Die Content-Inventur erfasst alle URLs und Content-Typen (Artikel, Produkte, Landingpages, Downloads) samt Traffic, Backlinks und Conversions. Quellen sind ein vollständiger Crawl, XML-Sitemaps, Server-Logs, Analytics und die Google Search Console.
Bewerten Sie jede Seite nach dem ROT-Prinzip (redundant, outdated, trivial): behalten, zusammenführen, überarbeiten oder löschen. Was nicht migriert wird, muss nicht getestet und übersetzt werden. Erfassen Sie zudem alle angebundenen Systeme und überprüfen Sie Informationsarchitektur, Nutzerpfade und Tone of Voice.
2. Architekturentscheidung: Wann ist Headless sinnvoll?
Headless lohnt sich, wenn Inhalte in mehreren Kanälen erscheinen (Website, App, Screens im Store), viele Systeme angebunden sind oder Frontend-Teams unabhängig arbeiten sollen. Dem stehen höhere Anforderungen an Frontend-Entwicklung und Betrieb gegenüber. Achten Sie deshalb auf Vorschau und visuelle Bearbeitung für Redakteure. Für einfache Websites genügt oft ein klassisches CMS.
Im Commerce-Umfeld arbeitet das CMS meist mit einem PIM-System für Produktdaten zusammen. Mehr dazu in unserem Beitrag zur Integration von PIM und CMS.
3. Neues Content-Modell gestalten
Übernehmen Sie die Altstruktur nicht eins zu eins, sonst migrieren Sie technische Schulden mit. Zerlegen Sie Seiten in wiederverwendbare Content-Typen und Felder (z. B. Teaser, FAQ-Block, Produktreferenz) statt großer Rich-Text-Blöcke. Das ist Voraussetzung für Mehrkanalfähigkeit und maschinelle Lesbarkeit.
4. Content-Migration automatisieren
Übertragen Sie Inhalte per Skript über die APIs von Quell- und Zielsystem statt per Copy-and-paste. Planen Sie mehrere Probeläufe mit Stichproben ein und frieren Sie Inhalte vor der finalen Migration kurz ein (Content Freeze). Wie KI hier hilft, lesen Sie weiter unten.
5. SEO-Migration: Redirect-Mapping, Crawl-Vergleich, Search Console
Hier entscheidet sich, ob Rankings erhalten bleiben. Drei Bausteine sind Pflicht:
- Redirect-Mapping: Ordnen Sie jeder alten URL die inhaltlich passende neue URL zu, priorisiert nach Traffic, Umsatz und Backlinks. Google empfiehlt serverseitige Weiterleitungen (301 oder 308), keine Ketten und eine Laufzeit von mindestens einem Jahr. Bilder, PDFs und andere Dateien gehören ebenfalls ins Mapping.
- Crawl-Vergleich: Crawlen Sie Alt- und Staging-System (z. B. mit Screaming Frog) und vergleichen Sie Statuscodes, Titles, Meta-Descriptions, Canonicals, hreflang, strukturierte Daten und interne Links. Nach dem Go-live prüft ein Crawl der alten URL-Liste, ob alle Redirects greifen.
- Search Console: Reichen Sie die neue XML-Sitemap ein und beobachten Sie die Berichte zu Indexierung, Sitemaps und Leistung. Das Adressänderungs-Tool ist nur bei einem Domain- oder Subdomain-Wechsel nötig.
Rechnen Sie mit Schwankungen: Laut Google kann es bei mittelgroßen Websites einige Wochen dauern, bis die neuen URLs vollständig angezeigt werden. Eine Auswertung von Search Engine Journal über 892 Domain-Migrationen ermittelte im Schnitt 523 Tage bis zur Erholung des organischen Traffics. Ändern Sie deshalb möglichst nicht Domain, URLs, Design und Inhalte gleichzeitig.
6.Tests, Go-live und Hypercare
Testen Sie Funktionen, Integrationen, Core Web Vitals, Barrierefreiheit und Redirects auf einer für Suchmaschinen gesperrten Staging-Umgebung. Legen Sie den Go-live früh in die Woche, benennen Sie eine Person mit Rollback-Befugnis und beobachten Sie Server-Logs, Fehlerseiten und Rankings in den ersten Wochen eng.
Was verlangt das BFSG von Ihrem neuen CMS?
Seit dem 28.06.2025 müssen B2C-Dienstleistungen im elektronischen Geschäftsverkehr, etwa Onlineshops und Buchungsportale, barrierefrei sein (Ausnahme: Kleinstunternehmen, siehe FAQ). Maßstab ist die Norm EN 301 549, die auf WCAG 2.1 Stufe AA verweist. Verstöße können mit Bußgeldern bis 100.000 Euro geahndet werden, zudem ist eine Erklärung zur Barrierefreiheit Pflicht.
Im September 2026 wurde EN 301 549 in Version 4.1.1 veröffentlicht, die WCAG 2.2 übernimmt. Rechtlich maßgeblich bleibt bis zur Veröffentlichung im EU-Amtsblatt die Version 3.2.1. Wer jetzt migriert, sollte trotzdem WCAG 2.2 als Zielniveau ansetzen.
Für das CMS heißt das: Pflichtfelder für Alternativtexte, saubere Überschriftenhierarchie, barrierefreie Komponenten und Formulare sowie automatisierte Prüfungen im Redaktionsprozess. Ein Replatforming ist der günstigste Zeitpunkt, das im System zu verankern.
Big Bang oder Strangler-Pattern: Wie migrieren Sie mit geringem Risiko?
Für größere Portale ist eine schrittweise Migration nach dem Strangler-Pattern meist sicherer als ein Big-Bang-Wechsel. Das Muster stammt aus der Softwarearchitektur: Eine vorgeschaltete Routing-Schicht (Reverse Proxy oder CDN) leitet Anfragen je nach Pfad an das alte oder neue System. Bereich für Bereich wandert auf die neue Plattform, bis das Altsystem abgeschaltet werden kann.
Bewährt hat sich der Start mit Blog oder Hilfebereich: So validieren Sie Content-Modell, Skripte und SEO-Setup unter realen Bedingungen. Der Preis ist ein Parallelbetrieb beider Systeme mit konsistenter Navigation. Für kleine Websites ist ein vollständiger Wechsel oft einfacher.
Wie kann KI die Content-Migration unterstützen?
KI-Modelle übernehmen Routinearbeiten, die früher manuell anfielen:
- Inhalte klassifizieren und den Content-Typen des neuen Modells zuordnen
- Rich Text in strukturierte Felder zerlegen
- fehlende Metadaten, Teaser und Alternativtexte vorschlagen
- Dubletten und veraltete Inhalte für die ROT-Bewertung markieren
- KI liefert Vorschläge, keine Freigaben. Praxisberichte nennen Fehler wie falsch aufgelöste Bild-URLs. Planen Sie daher ein Zielschema im Prompt, Stichproben und eine redaktionelle Abnahme ein.
Welche Risiken hat ein CMS-Replatforming und wie vermeiden Sie sie?
Die meisten Probleme entstehen durch fehlende Vorbereitung.
| Risiko | Folge | Gegenmaßnahme |
|---|---|---|
| Unvollständiges Redirect-Mapping | Ranking- und Traffic-Verlust | Mapping vor Go-live, priorisiert nach Traffic und Backlinks |
| Zu viele Änderungen gleichzeitig | Ursachen für Einbrüche nicht erkennbar | URLs und Domain möglichst stabil halten, in Etappen ändern |
| Barrierefreiheit nachträglich | Bußgeldrisiko, teure Nacharbeit | Anforderungen in Komponenten und Workflows verankern |
| Staging-Sperre bleibt aktiv | Seiten fallen aus dem Index | Go-live-Checkliste mit robots.txt und noindex |
Wie sieht CMS-Replatforming in der Praxis aus?
Zwei Univio-Projekte aus Branchen mit hohen Sicherheitsanforderungen:
LUX MED: über 20 Marken in einem CMS
LUX MED, führender Anbieter privater Gesundheitsversorgung in Polen und Teil der Bupa-Gruppe, verwaltete nach zahlreichen Akquisitionen viele Websites, und jede Aktualisierung band Entwickler. Univio setzte eine Lösung auf Basis von Kontent.ai und Microsoft Azure mit Static Site Generation um. Heute pflegt das Marketing Inhalte für mehr als 20 Marken in einem CMS ohne IT-Unterstützung. Ein Design System mit rund 170 Komponenten beschleunigt den Start neuer Portale
mBank: Portal in MACH-Architektur
mBank wollte die mobile UX verbessern und Redakteure unabhängiger vom Entwicklungszeitplan machen. Das Portal basiert auf MACH (Microservices, API-first, Cloud-native, Headless) und nutzt partielle Static Site Generation: Nur geänderte Seiten werden neu generiert, was Veröffentlichungen beschleunigt. Eigene CMS-Module decken Dokumente und Rechner ab, die Umsetzung erfüllt WCAG 2.2. Das Portal verarbeitet rund 12 Millionen Seitenaufrufe pro Monat.
Womit sollten Sie beim CMS-Replatforming beginnen?
Beginnen Sie mit einer Bestandsaufnahme aus Content-Inventur, Integrationsübersicht, SEO-Baseline und Barrierefreiheits-Audit. Daraus ergeben sich Architektur und Migrationsreihenfolge.
Möchten Sie prüfen, ob Ihr aktuelles CMS Ihr Wachstum bremst? Das Univio-Team analysiert in einem Architektur-Audit Ihr System, Ihre Inhalte und Ihre SEO-Risiken und erstellt daraus einen konkreten Migrationsplan.
FAQ: Häufig gestellte Fragen
Was bedeutet Replatforming?
Replatforming ist der Wechsel einer zentralen Technologie, etwa des CMS, auf eine modernere Plattform, ohne das Geschäftsmodell grundlegend zu ändern. Anders als bei einem Redesign ändern sich Datenmodell, Redaktionsprozesse und Schnittstellen. Ziel sind schnellere Veröffentlichung, einfachere Integrationen und geringere Betriebskosten.
Was ist ein Beispiel für Replatforming?
Ein häufiges Beispiel ist der Wechsel von WordPress oder einem individuellen Monolithen zu einem Headless CMS wie Contentful, Kontent.ai oder Strapi. Die Inhalte werden dabei in ein strukturiertes Content-Modell überführt und anschließend über APIs an Website, App und weitere Kanäle ausgeliefert.
Wie verhindere ich Ranking-Verluste bei einer CMS-Migration?
Erstellen Sie vor dem Go-live ein vollständiges 301-Redirect-Mapping, vergleichen Sie Crawls von Alt- und Neusystem und reichen Sie die neue Sitemap in der Google Search Console ein. Halten Sie Weiterleitungen laut Google mindestens ein Jahr aktiv und ändern Sie URLs nur, wo es nötig ist.
Muss meine Website nach dem BFSG barrierefrei sein?
Wenn Sie Verbrauchern Dienstleistungen im elektronischen Geschäftsverkehr anbieten, etwa einen Onlineshop, gilt das BFSG seit dem 28.06.2025. Ausgenommen sind Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz. Maßstab ist WCAG 2.1 AA über die Norm EN 301 549.
Was ist das Strangler-Pattern bei einer CMS-Migration?
Beim Strangler-Pattern ersetzen Sie das alte CMS schrittweise. Eine Routing-Schicht leitet einzelne Bereiche, etwa zuerst den Blog, an das neue System, während der Rest weiter vom Altsystem ausgeliefert wird. So testen Sie unter realen Bedingungen und begrenzen das Risiko eines Totalausfalls.
Quellen und weiterführende Informationen
- Google Search Central: Websiteumzüge mit URL-Änderungen
- Search Console-Hilfe: Tool zur Adressänderung
- Search Engine Journal: How Long Should An SEO Migration Take? (Studie mit 892 Migrationen)
- OMR Reviews: SEO-Strategie beim Website-Relaunch
- IHK Region Stuttgart: Barrierefreiheitsstärkungsgesetz (BFSG)
- AccessibleEU: EN 301 549 wurde aktualisiert (v4.1.1)
- Microsoft Learn: Strangler Fig Pattern
- comspace: Content-Migration mit KI
- Univio Case Study: LUX MED, 20+ Marken in einem CMS
- Univio Case Study: Implementierung der neuen mBank-Website








