Was ist eine CMS-Migration?
Eine CMS-Migration bringt eine Website von einem Content-Management-System in ein anderes, zum Beispiel von TYPO3, WordPress oder einer Eigenentwicklung zu Webflow. Die Inhalte ziehen um, die URLs bleiben erhalten oder werden weitergeleitet, und euer Team veröffentlicht ab dann im neuen System.
Das ist mehr als ein Redesign. Ein Redesign verändert, wie Seiten aussehen. Eine Migration verändert, wo Inhalte liegen, wie sie strukturiert sind und wer sie bearbeiten kann.
Wenn ihr noch überlegt, ob ihr euer aktuelles System verlassen sollt, startet mit unserem Leitfaden dazu, wann sich der Abschied von einem Legacy-CMS lohnt. In diesem Artikel geht es darum, wie ihr umzieht, sobald die Entscheidung steht.
Wie plant ihr eine CMS-Migration?
Plant sie in fünf Phasen und schließt die ersten beiden ab, bevor die Designarbeit beginnt. Jede spätere Phase baut darauf auf.
In den SEO-Schritten der Phasen 1 und 5 wird Traffic gewonnen oder verloren. Unsere SEO-Checkliste für die Migration von WordPress zu Webflow geht sie Schritt für Schritt durch, und das meiste davon gilt für jedes CMS.
Wie gestaltet ihr das neue Content-Modell?
Geht von den Inhalten aus, die euer Team jeden Monat erstellt und aktualisiert, nicht von den Menüs des alten Systems. Ein Content-Modell ist die Liste der Collections, Felder und Templates, die das neue CMS enthalten wird.
Stellt für jeden Content-Typ drei Fragen:
- Wie oft ändert er sich? Blogartikel, Jobs, Events und Case Studies gehören ins CMS. Eine Seite, die sich einmal im Jahr ändert, kann eine statische Seite bleiben.
- Wer bearbeitet ihn? Felder sollten so aufgebaut sein, wie Redakteure denken: ein Zusammenfassungsfeld, ein Hero-Bild, ein CTA, nicht ein großer Textblock.
- Wo wird er wiederverwendet? Inhalte, die auf mehreren Seiten erscheinen, etwa Testimonials oder Teammitglieder, gehören in eine Collection und werden von dort referenziert.
Wenn das sitzt, bleibt die neue Website über Jahre einfach zu pflegen. Unser Leitfaden zur Struktur eines Webflow CMS zeigt den Ansatz an echten Projekten.
Was sollte mit euren bestehenden Inhalten passieren?
Jede URL bekommt eine von vier Entscheidungen: behalten, zusammenführen, weiterleiten oder entfernen. Seiten mit Traffic, Rankings oder Backlinks bekommen immer ein neues Zuhause.
- Behaltet Seiten, die performen und noch das Richtige sagen.
- Führt Seiten zusammen, die dieselbe Frage beantworten, damit sie nicht mehr miteinander konkurrieren.
- Leitet jede alte URL, die sich ändert, auf die passendste neue Seite weiter.
- Entfernt Seiten ohne Traffic, ohne Links und ohne Zweck, und leitet sie auf eine übergeordnete Seite weiter.
Die meisten älteren Websites schleppen eine lange Liste von Seiten mit, die seit Jahren niemand geöffnet hat. Sie mitzunehmen kostet Zeit und macht die neue Website schwerer zu pflegen.
Aus unseren Projekten: Für Instaffo haben wir über 120 Landing Pages von Instapage nach Webflow umgezogen und eine Component Library darum aufgebaut. Die ganze Website läuft jetzt auf einem System, und das Marketing stellt neue Seiten „mit wenigen Klicks“ zusammen, so Mika Leicht von Instaffo. Zur Instaffo Case Study.
Wie zieht ihr die Inhalte selbst um?
Wählt die Methode nach Umfang. Kleine Websites werden von Hand umgezogen, größere per Import oder Automatisierung.
- Von Hand: Bei weniger als etwa 50 Seiten ist es oft am schnellsten, jede Seite zu kopieren und zu prüfen, und es erzwingt eine sinnvolle Durchsicht jeder Seite.
- CSV-Import: Blogartikel, Jobs oder Produkte mit klarer Struktur lassen sich exportieren und in CMS Collections importieren.
- Automatisierung: Bei großen oder unordentlichen Inhalten verschiebt ein Skript, eine API oder eine KI-gestützte Bereinigung die Inhalte in großen Mengen. Bei heyData haben wir für den Umzug eine KI-gestützte Content-Migration genutzt.
Egal welche Methode: Plant Zeit zum Aufräumen ein. Alter Rich Text bringt kaputte Formatierungen, veraltete Links und Bilder ohne Alt-Text mit, und jemand muss jeden importierten Eintrag prüfen.
Unser Tipp: Legt beim Kick-off einen Termin für den Content-Freeze fest. Jede Seite, die nach dem Export noch im alten CMS bearbeitet wird, muss von Hand nachgezogen werden, und genau dort gehen Wochen vor dem Launch verloren. Wenn eine dringende Änderung nicht warten kann, tragt sie in eine gemeinsame Liste ein, damit beim Launch nichts vergessen wird.
Was passiert am Launch-Tag?
Der Launch-Tag sollte ein Umschalten sein, kein Projekt. Wenn Weiterleitungen, Inhalte und QA auf Staging fertig sind, dauert das Go-live selbst nur Stunden.
Geht in dieser Reihenfolge vor:
- Letzter Content-Abgleich. Übernehmt jede Änderung aus der Freeze-Liste, damit die neue Website am Tag des Go-live der alten entspricht.
- Weiterleitungen einspielen. Importiert die vollständige Weiterleitungs-Map aus Phase 1 und testet alte URLs, zuerst die mit dem meisten Traffic und den meisten Backlinks.
- Letzter Check auf Staging. Formulare, Tracking, Cookie-Consent, Metadaten und jedes Template auf Mobilgeräten.
- Domain-Umstellung. Die IT stellt das DNS um. Behaltet den Zugang zum alten System, bis bestätigt ist, dass die neue Website live ist.
- Google Bescheid geben. Reicht die neue Sitemap in der Search Console ein und prüft, dass die Live-Website nicht auf noindex steht.
- Auf der Live-Domain erneut testen. Schickt jedes Formular ab, prüft, ob Leads im CRM ankommen und ob Tracking-Events feuern.
Dann beobachtet die Website. Prüft in den ersten Wochen nach dem Launch die Search Console auf 404- und Crawling-Fehler, vergleicht Rankings und Conversions mit der exportierten Ausgangsbasis und ergänzt fehlende Weiterleitungen, sobald sie auftauchen.
Wie lange dauert eine CMS-Migration?
Eine typische Unternehmenswebsite braucht 6 bis 8 Wochen. Größere Websites, viele Templates oder mehrere Sprachen brauchen 12 bis 16 Wochen.
Was den Zeitplan am stärksten beeinflusst:
- Die Anzahl der Templates, nicht die Anzahl der Seiten. Zwanzig Blogartikel teilen sich ein Template. Zwanzig individuelle Landing Pages nicht.
- Sprachen. Jede Sprachversion bringt zusätzliche Inhalte, URLs und Checks.
- Integrationen. CRM, Formulare, Produkt-Feeds und Tracking müssen alle neu aufgebaut und getestet werden.
- Entscheidungstempo. Eine Content-Inventur, die zwei Wochen auf eine Freigabe wartet, verzögert alles danach.
Wie sieht eine CMS-Migration in der Praxis aus?
Hier ist eine unserer Migrationen von Anfang bis Ende: der Relaunch von heyData, über 90 Seiten in zwei Sprachen, live in 12 Wochen.
Die Ausgangslage
heyData ist eine Berliner Compliance-Plattform für Regelwerke von der DSGVO bis zum EU AI Act. Das Unternehmen hatte gerade ein Rebranding abgeschlossen, aber die Website zeigte noch die alte Marke. Jahre an ergänzten Seiten hatten eine Struktur hinterlassen, die sich kaum ändern ließ, und viele Inhalte passten nicht mehr zum Produkt.
Das Team brauchte eine Website, die die neue Marke trägt, besser konvertiert und die Sichtbarkeit in der Suche hält, und das in deutlich kürzerer Zeit, als eine Website dieser Größe normalerweise braucht.
Die Entscheidungen, auf die es ankam
- Aufräumen vor dem Bauen. Wir haben über 300 veraltete URLs entfernt: alte Blogartikel, eingestellte Leistungen und umstrukturierte Angebote. Jede bekam eine Weiterleitung auf die passendste neue Seite, damit die Links und Rankings, die darauf zeigten, nicht verloren gingen.
- Components zuerst. Die neue Website läuft auf einem modularen Webflow Component-System, sodass über 90 Seiten in zwei Sprachen aus denselben Bausteinen entstehen.
- Parallel bauen. Zwei Entwickler haben gleichzeitig am Webflow-Build gearbeitet. Daher kommen die 12 Wochen.
- SEO auf jeder verbleibenden Seite. Struktur, Metadaten und interne Links wurden Seite für Seite geprüft, und die Inhalte selbst wurden per KI-gestützter Migration umgezogen.
Das Ergebnis
Nach dem Launch verbesserte sich die durchschnittliche Google-Position über alle Keywords von 20,7 auf 7,8. Die täglichen Impressionen stiegen von 8.340 vor dem Launch auf einen Höchstwert von 35.130 innerhalb weniger Wochen.
Marco Lolli, Team Lead Performance Marketing bei heyData, beschrieb das Projekt als „bemerkenswert effizient, besonders auf der Zielgeraden vor dem Launch“. Sein Fazit: „Die neue heydata.eu wird unserer Marke endlich gerecht.“ Zur vollständigen heyData Case Study.
Was geht bei einer CMS-Migration schief, und wie verhindert ihr es?
Fast jedes Migrationsproblem geht auf eine Entscheidung zurück, die zu spät getroffen wurde. Das sind die vier, die wir am häufigsten sehen, jeweils mit Lösung.
- Die alte Struktur wird 1:1 kopiert. Lösung: Baut das Content-Modell danach auf, wie euer Team heute veröffentlicht. Eine Migration, die die Menüs von gestern kopiert, behält auch die Workarounds von gestern.
- Nur Seiten werden migriert. Lösung: Nehmt PDFs, Formulare, Tracking, das Cookie-Consent-Setup und jede Integration in die Inventur auf. Sie brechen leise weg, und niemand merkt es, bis keine Leads mehr ankommen.
- Redakteure sehen das neue CMS erst zum Launch. Lösung: Lasst die Leute, die jede Woche veröffentlichen, schon vor dem Go-live darin arbeiten. Ihr Feedback ändert Feldnamen und Templates, solange das noch günstig ist.
- Niemand hält den „Vorher“-Stand fest. Lösung: Exportiert vor der Umstellung Search-Console-Daten, Rankings und Conversion-Zahlen. Ohne Ausgangsbasis könnt ihr weder belegen, dass die Migration funktioniert hat, noch erkennen, was abgerutscht ist.
Wo sollte euer Team anfangen?
Mit der Inventur. Exportiert jede URL aus eurer Sitemap und der Search Console, ergänzt Traffic und Backlinks und trefft für jede die Entscheidung: behalten, zusammenführen, weiterleiten oder entfernen. Diese Liste bestimmt das Content-Modell, den Zeitplan und das Budget. Holt die IT gleich mit dazu: Domain-Zugang und die Sicherheitsprüfung der neuen Plattform sind der häufigste Grund, warum eine fertige Website auf ihr Go-live wartet.
Wenn euer neues CMS Webflow ist, erklärt unser Überblick Was ist Webflow die Plattform selbst, und unser Webflow Rebuild folgt denselben Schritten: ein Audit mit Festpreis-Scope, der Kern-Build, QA mit URL-Mapping und Weiterleitungen, dann ein begleitetes Go-live und eine Schulung für euer Team.
FAQs
Die Marketing-Leitung. Sie verantwortet die Content-Entscheidungen und die Launch-Freigabe, während die Entwicklung den Build verantwortet und die IT Domains, Zugänge und Sicherheit.
Bei statischen Seiten oft ja. Blog- und andere CMS-URLs ändern sich meist, weil jedes System sie anders strukturiert. Das ist kein Problem, solange jede alte URL auf ihre neue Seite weiterleitet.
Nein. Ihr könnt ein bestehendes Design unverändert ins neue System übernehmen. Viele Teams kombinieren beides, aber wenn ihr das Design behaltet, geht die Migration schneller und lässt sich leichter messen.
Sie werden im neuen System neu aufgebaut. Listet jede Integration in Phase 1 auf und testet vor dem Launch jedes Formular, jedes Tracking-Event und jede Datensynchronisation. Unser Leitfaden zu Webflow-Formularen erklärt CRM-Anbindungen in Webflow.
Ja. Plant jede Sprache von Anfang an in die URL-Map und das Content-Modell ein, denn jede Sprachversion vervielfacht Seiten, Weiterleitungen und Checks.
