CMS-Migration:Strategie, Ablauf und Tipps für B2B-SaaS-Websites

Bei einer CMS-Migration ziehst du die Inhalte und Funktionen deiner Website in ein neues System um. Der Import der Texte ist dabei meist der kleinste Teil. Mehr Arbeit machen Funktionen, die das alte System nebenbei erledigt hat, etwa ein Formular mit CRM-Anbindung. Wer so etwas übersieht, verliert nach dem Launch Anfragen.

Die wichtigste Entscheidung fällt deshalb vor dem ersten Export. Du legst fest, wie dein Team künftig Seiten bauen und pflegen soll. Daraus ergibt sich, welches System passt und wie viel sich beim Umzug ändern darf.

Wann sich eine CMS-Migration lohnt

Ein CMS-Wechsel lohnt sich, wenn das System selbst dein Marketing ausbremst. Das merkst du im Alltag meist früher als in einer Analyse. Passen dagegen vor allem Botschaft und Seitenstruktur nicht mehr, löst ein neues System das Problem allein nicht.

Typische Anlässe in B2B-SaaS-Teams

In B2B-SaaS-Teams sehen wir immer wieder ähnliche Anzeichen. Eine neue Landingpage wartet im Backlog der Entwicklung, obwohl die Kampagne startklar ist. Plugin-Updates und Sicherheitslücken kosten jeden Monat Zeit, die im Marketing fehlt.

Dazu kommen technische Grenzen. Schwere Themes bremsen die Ladezeit und ein Page-Builder gibt einen Aufbau vor, der nicht mehr zum Produkt passt. Auch eine zweite Sprache oder eine neue Produktlinie lässt sich in manchen Systemen nur über Umwege abbilden.

Entscheidend ist, ob eine dieser Einschränkungen dein Marketing tatsächlich ausbremst. Schon ein einziger gravierender Engpass kann einen Wechsel rechtfertigen, während sich kleinere Probleme oft im bestehenden CMS lösen lassen.

Wann du besser beim bisherigen System bleibst

Eine enge Verzahnung mit dem Produkt macht den Wechsel aufwendiger, spricht aber nicht automatisch dagegen. Liegen etwa ein Login-Bereich oder ein Shop im selben System, kannst du Marketing-Website und Produktanwendung künftig auch getrennt betreiben. Das bedeutet mehr Migrationsaufwand, löst aber oft genau die Abhängigkeit, die das Marketing heute bremst.

Gegen einen Wechsel spricht eher, wenn dein heutiges CMS die Arbeitsweise deines Teams gut abbildet. Das gilt zum Beispiel für eine große Redaktion, die mit ihren Freigaben im heutigen System zuverlässig arbeitet. Fehlt vor allem eine klare Botschaft, hilft eher eine Überarbeitung von Texten und Struktur im bestehenden System.

Strategie: Erst festlegen, wie dein Team arbeiten soll

Welches Zielsystem passt, hängt davon ab, wer künftig Seiten baut und wie strukturiert deine Inhalte sind. Das alte System bestimmt vor allem, wie der Export technisch abläuft. Halte das Ziel deshalb vor jeder Systemauswahl in einem Satz fest, zum Beispiel: „Unser Marketing veröffentlicht Kampagnenseiten ohne Entwickler.“ Dieser Satz wird später zum Abnahmekriterium für das Projekt.

Große Websites mit vielen Sprachen bringen oft zusätzliche Anforderungen mit, etwa Security-Reviews oder feste Rollen und Freigaben im CMS. Kläre solche Anforderungen vor der Systemauswahl, denn sie schränken die Auswahl oft stärker ein als der Editor.

Wann Webflow passt

Webflow passt, wenn dein Marketing Landingpages und Kampagnen selbst bauen soll, ohne Code. Editor und CMS laufen dabei in einem System, das Hosting ist inklusive. Damit das im Alltag funktioniert, gehören wiederverwendbare Komponenten und Vorlagen in den Projektumfang.

Wann Astro mit Headless-CMS passt

Bei einem Headless-CMS liegen die Inhalte in einem eigenen System wie Sanity, die Darstellung übernimmt eigener Code. Mit dem Framework Astro entsteht daraus eine schnelle, schlanke Website. Das passt, wenn dein Team den Code besitzen will und Entwicklungskapazität für neue Seitentypen hat. Zusätzlich lassen sich Änderungen im Code mit AI-Agenten umsetzen, sodass auch kleinere Teams schneller neue Seiten bauen.

Umfang festlegen: 1:1-Umzug, Relaunch oder Etappen

Wie viel sich neben dem System ändert, bestimmt Aufwand und SEO-Risiko stärker als das alte CMS. Entscheidend ist, ob deine Website deine heutige Zielgruppe und dein aktuelles Angebot noch richtig beschreibt.

Unsere Einschätzung: Ein reiner 1:1-Umzug lohnt sich nur, wenn die Botschaft der Website noch stimmt. Bei SaaS-Teams, die seit dem letzten Launch gewachsen sind, ist das selten der Fall. Die Website richtet sich dann zum Beispiel noch an Gründer kleiner Teams, während Sales längst mit Marketing-Verantwortlichen im Mittelstand spricht.

Ein Umzug in Etappen klingt nach weniger Risiko, bringt aber eigene Anforderungen mit. Solange Blog und restliche Website auf verschiedenen Systemen laufen, brauchst du eine einheitliche Navigation, gemeinsames Tracking und Weiterleitungen über beide Systeme hinweg. Für kleinere Websites ist ein vollständiger Wechsel auf einmal deshalb meist einfacher.

Je mehr sich gleichzeitig ändert, desto schwerer erkennst du nach dem Launch, woher eine Veränderung bei Rankings oder Anfragen kommt. Ändere URLs deshalb nur dort, wo es einen Grund dafür gibt.

Was bei einer CMS-Migration umzieht und was neu gebaut wird

Wiederkehrende Inhalte wie Blogbeiträge oder Use Cases ziehen strukturiert ins neue CMS um. Seitenlayouts entstehen im neuen System neu, ebenso alles, was bisher ein Plugin oder Modul erledigt hat. Jede URL, die sich dabei ändert, braucht einen Plan, meist eine Weiterleitung.

Inhalte und Content-Modell

Das Content-Modell legt fest, welche Inhaltstypen deine Website hat und welche Felder jeder Typ braucht. Ein Blogbeitrag hat zum Beispiel Titel, Autor, Kategorie und Text. Gib dieses Modell frei, bevor importiert wird. Jede spätere Änderung an den Feldern musst du in allen bereits importierten Einträgen nacharbeiten.

Plugins und Sonderfunktionen

Beim Umzug geht vor allem verloren, was das alte System über Erweiterungen erzeugt hat. In WordPress sind das Plugins und Shortcodes, in TYPO3 Extensions und in HubSpot eigene Module. Im importierten Text tauchen solche Elemente oft nur als Fragment oder gar nicht mehr auf.

Lege deshalb eine Funktionsliste an. Entscheide für jeden Eintrag, ob das neue System ihn selbst abdeckt, ob eine eigene Komponente oder Integration nötig ist oder ob die Funktion entfällt. Diese Liste bestimmt den Aufwand stärker als die Zahl der Seiten.

URLs und Seitenstruktur

Jedes System gibt eigene Muster für URLs vor. Dynamische CMS-Seiten in Webflow bestehen standardmäßig aus dem Pfad der Collection und dem Slug des Eintrags, etwa /blog/onboarding-checkliste. Datumsbasierte WordPress-Adressen wie /2024/05/onboarding-checkliste/ lassen sich für CMS-Beiträge deshalb nicht abbilden. In Astro legst du das Routing im Code selbst fest und kannst alte Pfade oft beibehalten.

Lege das neue URL-Schema deshalb früh fest und behalte bestehende URLs, wo das System es erlaubt. Daraus leitest du die Redirect-Map ab, also die Tabelle, die jeder alten URL ihre neue Adresse zuordnet.

Sonderfälle nach Ausgangssystem

Welche Sonderfälle auftreten, hängt vom Ausgangssystem ab. Die Übersicht zeigt die häufigsten Punkte und führt zu den Detailseiten für deinen Migrationspfad.

Ablauf einer CMS-Migration in sechs Phasen

Eine CMS-Migration läuft in Phasen ab, die jeweils mit einem Ergebnis enden. Dein Team nimmt jedes Ergebnis ab, bevor die nächste Phase beginnt. So fallen Lücken im Inventar oder in der Redirect-Map auf, solange sie noch leicht zu beheben sind.

Die Phasen gelten für jedes Zielsystem. Das Inventar erstellst du am einfachsten mit einem Crawler wie Screaming Frog und ergänzt es um die Seiten mit Zugriffen aus der Google Search Console. Für Webflow haben wir den Projektplan mit allen Rollen im Artikel zur Webflow-Migration ausführlich beschrieben.

Wer was liefert

Dein Team bleibt für die Entscheidungen verantwortlich, auch wenn eine Agentur den größten Teil umsetzt. Dazu gehört vor allem der Seitenumfang. Auch die Redirect-Map und die Formulare nimmt am Ende dein Team ab. Benenne im Marketing eine Person, die das Projekt verantwortet und entscheiden darf.

Wovon die Dauer abhängt

Die Dauer hängt vor allem vom gewählten Weg ab. Der Import selbst fällt kaum ins Gewicht: In unseren Projekten ist die reine Inhaltsmigration meist in wenigen Stunden Arbeitszeit erledigt. Einen vollständigen Relaunch mit Migration setzen wir in der Regel in 12 bis 20 Wochen um.

Die meiste Kalenderzeit kosten Freigaben, allen voran die des Content-Modells. Jeder weitere Inhaltstyp und jede Integration verlängern vor allem die Testphase. Eine zweite Sprache bringt zusätzliche Prüfungen für Weiterleitungen und die Zuordnung der Sprachversionen mit.

Rankings und Anfragen beim Wechsel schützen

Weiterleitungen sind beim Erhalt deiner Rankings einer der wichtigsten Punkte, aber nicht der einzige. Auch geänderte Inhalte, eine neue interne Verlinkung, falsche Canonicals oder versehentlich gesperrte Seiten können Rankings kosten. Anfragen gehen dagegen meist verloren, wenn Formulare nach dem Umzug nicht mehr im CRM ankommen. Ohne gesicherte Ausgangswerte bemerkst du solche Verluste erst spät.

Weiterleitungen und URL-Plan

Leite jede alte URL per 301-Weiterleitung direkt auf die inhaltlich passende neue Seite. Google rät in seiner Anleitung zu Website-Umzügen davon ab, viele alte Adressen auf die Startseite zu leiten. Gibt es für eine alte Seite bewusst keinen sinnvollen Nachfolger, erzwinge keine unpassende Weiterleitung. Dann ist ein 404- oder 410-Status die sauberere Lösung.

Die Redirect-Map bereitest du vorab vor und prüfst ihre Zieladressen auf Staging. Ob die Weiterleitungen von den bisherigen Live-URLs tatsächlich greifen, lässt sich aber erst nach der Umschaltung vollständig testen. Plane diesen Test deshalb fest für den Go-live ein und vermeide Ketten aus mehreren Weiterleitungen. Google empfiehlt, die Weiterleitungen so lange wie möglich zu behalten, in der Regel mindestens ein Jahr.

Formulare und Tracking

Formulare verbindest du im neuen System neu. Prüfe danach für jedes Formular, ob alle Felder vollständig im CRM ankommen. Kontrolliere außerdem, ob die Quelle der Anfrage richtig erfasst wird und die Anfrage beim zuständigen Vertriebsteam landet.

Am zuverlässigsten testet Sales Ops das mit echten Testanfragen aus jedem Formular. Auch Tracking und Consent-Banner richtest du neu ein. Sichere vorher die Zahlen aus dem alten System, sonst fehlt dir nach dem Launch der Vergleich.

Metadaten, Indexierung und AI-Search

Seitentitel und Meta-Beschreibungen ziehen nicht in jedem System automatisch mit um, das gilt auch für strukturierte Daten. Übertrage sie bewusst und prüfe die internen Links auf die neuen Adressen. Kontrolliere außerdem Canonicals und stelle sicher, dass keine Live-Seite auf noindex steht. Bei mehreren Sprachen gehört die Zuordnung der Sprachversionen (hreflang) dazu.

Google beschreibt in seiner Dokumentation zu AI-Funktionen, dass für AI Overviews dieselben Grundlagen gelten wie für die klassische Suche. Gut zugänglicher Text und eine klare Struktur helfen also beiden.

Vier Tipps aus unseren Migrationsprojekten

Viele Korrekturschleifen lassen sich mit wenigen Regeln vermeiden, die du vor dem ersten Import festlegst. Diese vier Punkte sparen nach unserer Erfahrung am meisten Nacharbeit.

Kampagnen-URLs zuerst sichern

Anzeigen und Newsletter verlinken oft auf Landingpages, die in keiner Sitemap auftauchen. Auch in Sales-Decks und auf Partnerseiten stehen alte Links. Frag deshalb Performance-Marketing und Sales nach ihren aktiven Links, bevor die Redirect-Map steht.

Mit den schwierigsten Seiten testen

Wähle für den Testimport 5 bis 10 typische Seiten aus und nimm bewusst die komplexesten dazu. Das sind etwa Beiträge mit Tabellen und eingebetteten Elementen. Formatierungen, die das neue System nicht unterstützt, fallen so auf, bevor du hunderte Einträge nacharbeiten musst.

Content-Freeze und abschließende Synchronisierung einplanen

Während des Projekts entstehen im alten System weiter neue Beiträge. Lege deshalb einen Zeitpunkt fest, ab dem dort nichts mehr veröffentlicht wird. Kurz vor dem Go-live überträgst du dann nur die neuen und geänderten Inhalte aus der Projektzeit. Ein solcher Delta-Import verhindert, dass bereits bearbeitete Einträge überschrieben oder doppelt angelegt werden.

Den Rückweg vor dem Launch-Tag festlegen

Kläre vorher, wer am Launch-Tag entscheidet und bei welchen Fehlern dein Team auf die alte Website zurückschaltet. Ein fehlerhaftes Formular lässt sich oft live beheben. Fehlen die Weiterleitungen für wichtige Seiten, ist ein geplanter Rückweg die sicherere Wahl. Dafür bleiben die alte Website und ein vollständiges Backup verfügbar, bis die neue stabil läuft.

Checkliste für den Go-live deiner CMS-Migration

Diese Prüfungen entscheiden bei einer CMS-Migration darüber, ob Suchzugriffe und Anfragen den Wechsel überstehen. Hake sie rund um den Go-live gemeinsam mit der verantwortlichen Person ab:

• Inventar, Ausgangswerte und vollständiges Backup vor der Umsetzung gesichert
• Redirect-Map mit allen alten URLs freigegeben, Seiten ohne Nachfolger bewusst auf 404 oder 410 gesetzt
• Weiterleitungen nach der Umschaltung auf der Live-Domain getestet, ohne Ketten
• Canonicals geprüft und kein noindex auf Live-Seiten
• Neue XML-Sitemap in der Google Search Console eingereicht
• Testanfragen aus jedem Formular bis ins CRM nachverfolgt, inklusive Quelle und Zuständigkeit
• Tracking und Consent-Banner auf der Live-Domain geprüft
• Suchzugriffe, Fehlerseiten und Anfragen in den Folgewochen mit den Ausgangswerten verglichen

Die allgemeinen Prüfungen für den Launch-Tag findest du in unserer Website-Relaunch-Checkliste, die es auch als PDF mit Platz für Zuständigkeiten gibt.

Selbst umsetzen oder mit einer Agentur?

Eine kleine Website ohne Sprachversionen und ohne CRM-Anbindung kann ein Team mit Erfahrung im Zielsystem selbst umziehen. Bringen viele Seiten Anfragen über die Suche oder hängen Integrationen an der Website, wächst das Risiko von Fehlern nach dem Launch. Dann spart erfahrene Unterstützung vor allem Korrekturschleifen.

Kläre vor dem Angebot, wer die Redirect-Map erstellt und testet. Frag außerdem, wer den Import verantwortet und wer die Formulare bis ins CRM abnimmt. An den Antworten erkennst du, ob die Migration im Angebot eingeplant ist oder nebenbei mitlaufen soll.

Sollen neben dem System auch Positionierung und Design neu entstehen, ist ein Relaunch der passende Rahmen. Dann planst du Botschaft, Struktur und Migration gemeinsam, statt die alte Website nur in ein neues System zu kopieren.