CMS-Migration: Ablauf, Kosten und wie deine Rankings halten
Was bei jedem CMS-Wechsel gleich läuft und was pro Ausgangssystem anders ist: sechs Phasen, Redirect-Map, Kosten und Dauer, und wie du dich für das Zielsystem entscheidest.
Eine CMS-Migration ist der Umzug deiner Inhalte von einem Redaktionssystem in ein anderes, mit neuem Content-Modell, neuen Templates und meist neuen URLs. Sie lohnt sich, wenn die Struktur deiner Inhalte dich bremst, nicht wenn dir nur das Aussehen nicht mehr gefällt. Diese Unterscheidung entscheidet über mehrere Wochen Projektzeit und einen fünfstelligen Betrag. Wir haben unsere eigene Website 2026 von Wix auf Next.js mit Sanity umgezogen und begleiten Wechsel aus WordPress, TYPO3, Webflow und Baukästen. Dieser Artikel zeigt dir den Ablauf in sechs Phasen, was sich beim Umzug immer ändert, welche Eigenheit jedes Ausgangssystem beim Export mitbringt, und wie du das Zielsystem entscheidest.
Das Wichtigste in Kürze
- Migration heißt Systemwechsel, Redesign heißt neue Oberfläche auf demselben System. Beantworte diese Frage zuerst, dann das Budget.
- Der Ablauf ist immer derselbe: Inventar, Content-Modell, Frontend, Import, Weiterleitungen, Launch mit Monitoring.
- Eine Marketing-Website mit 10-30 Seiten ist typischerweise in 3-6 Wochen live, danach folgen zwei Wochen Monitoring.
- Wir rechnen jede Migration als Relaunch-Projekt ab, unsere Relaunch-Pakete starten bei 8.000 € netto.
- Jede alte URL braucht ein 1:1-Ziel per 301, sonst verlierst du Positionen, die du vorher schon hattest.
- Bis etwa 30 Seiten, ein oder zwei Sprachen und ohne programmatische Seiten reicht Webflow. Darüber gehst du auf Sanity mit eigenem Frontend.
Die kurze Antwort
Eine CMS-Migration ist der Wechsel des Redaktionssystems hinter deiner Website. Inhalte werden aus dem alten System geholt, in ein neues Content-Modell überführt und über neue Templates ausgeliefert. Der Ablauf ist unabhängig vom Ausgangssystem gleich: Content-Inventar mit Vorher-Crawl, Content-Modell, Frontend und Templates, Import, Redirect-Map, Launch mit Monitoring.
Unterschiedlich ist nur der Export. WordPress gibt dir Inhalte über den WXR-Export oder die Programmierschnittstelle heraus, Webflow liefert beim Export Markup, aber keine CMS-Inhalte, und bei Baukästen bleibt am Ende oft Textübernahme statt Datei-Umzug. Der Aufwand entsteht nicht beim Herausholen, sondern beim Umformen in saubere Felder.
Für eine Marketing-Website mit 10-30 Seiten planen wir typischerweise 3-6 Wochen bis Go-Live plus zwei Wochen Monitoring, abgerechnet als Relaunch-Projekt ab 8.000 € netto. Die Rankings halten, wenn jede alte URL per permanenter Weiterleitung auf ihr inhaltliches Gegenstück zeigt und du nach dem Launch 404-Fehler und Positionen aktiv nachverfolgst. Wie das im Detail abläuft, steht in unserem Leitfaden zum Relaunch ohne SEO-Verlust.
Wann eine Migration nötig ist und wann ein Redesign reicht
Ein Redesign tauscht die Oberfläche, eine Migration tauscht das System darunter. Wenn deine Inhalte sauber in Feldern liegen, deine Redaktion arbeiten kann und dich nur das Aussehen stört, bleib im System und spar dir den Umzug. Sobald die Struktur der Inhalte das Problem ist, hilft kein neues Design.
Diese fünf Auslöser sprechen für einen echten Systemwechsel:
- Du brauchst Inhaltstypen und Felder, die dein System nicht abbilden kann, etwa Produkte, Anwendungsfälle und Referenzen als eigene Objekte statt als Textblöcke.
- Eine zweite oder dritte Sprache steht an und dein System rechnet pro Sprache ab oder zwingt dich zu Dubletten.
- Die Seite schleppt zu viel Code mit. Eine unserer Webflow-Kundenseiten lädt auf der Startseite rund 740 KB JavaScript in dreizehn Dateien, leanwave.com, das wir statisch mit Astro bauen, an derselben Stelle rund 39 KB in drei Dateien.
- Du willst Seiten programmatisch aus Daten erzeugen und stößt an Vorlagen- und Mengengrenzen der Plattform.
- Der Sicherheits-Support deiner Version läuft aus. Bei TYPO3 endete der kostenlose Community-Support für v11 im Oktober 2024 und für v12 im April 2026.
Trifft nichts davon zu, ist ein Relaunch im bestehenden System der günstigere Weg. Trifft mehr als eines zu, verschiebt der Umzug nur Kosten in die Zukunft, wenn du ihn aufschiebst.
Die sechs Phasen einer CMS-Migration
Wir fahren jede Migration in derselben Reihenfolge, egal ob das alte System WordPress, TYPO3, Webflow oder ein Baukasten ist. Die Reihenfolge ist kein Ritual: Jede Phase liefert das Material, ohne das die nächste raten müsste.
Inventar und Messung
Vorher-Crawl mit Screaming Frog oder Ahrefs, dazu ein Ranking-Snapshot. Du weißt danach, welche URLs existieren, welche Traffic bringen und welche du ersatzlos streichen kannst.
Content-Modell
Inhaltstypen und Felder werden definiert, bevor eine Zeile Frontend entsteht. Hier entscheidet sich, ob die Website später wächst oder wieder zur Sammlung von Textblöcken wird.
Frontend und Templates
Komponenten und Seitenvorlagen werden im neuen System gebaut und gegen das Modell verdrahtet.
Import
Die alten Inhalte werden transformiert und eingespielt, bei Sanity als NDJSON, einem Format mit einem Datensatz pro Zeile, über `sanity dataset import`. Assets werden heruntergeladen und neu hochgeladen.
Weiterleitungen und Launch-Checkliste
Für jede alte URL steht ein 1:1-Ziel in der Redirect-Map. Fehlende Ziele fallen hier auf, nicht nach dem Launch.
Launch und Monitoring
Einreichung in Search Console und Bing, IndexNow für schnelle Meldung neuer URLs, danach zwei Wochen Monitoring mit 404-Report und Ranking-Abgleich.
Phase 1 und Phase 2 kosten Zeit und fühlen sich nach wenig Fortschritt an. Genau dort entscheidet sich, ob der Rest glatt läuft.
Content-Inventar und Content-Modell
Das Inventar ist die Liste aller URLs mit Seitentyp, Traffic und Position. Das Content-Modell ist die Antwort darauf: Welche Inhaltstypen gibt es wirklich, welche Felder braucht jeder, und was hängt womit zusammen. Beides zusammen ersetzt das Bauchgefühl, welche Seiten wichtig sind.
Ein brauchbares Modell beschreibt vier Dinge:
- Dokumenttypen: Service, Wissen-Artikel, Referenz, Person, Standort. Jeder Typ bekommt sein eigenes Template.
- Felder: Titel, Meta-Description, Kurztext, strukturierte Textabschnitte, FAQ-Einträge. Kein einzelnes HTML-Feld, in dem alles zusammenklebt.
- Referenzen: Ein Wissen-Artikel verweist auf Service-Seiten, eine Referenz auf die eingesetzten Technologien. Daraus entsteht interne Verlinkung, die nicht von Hand gepflegt wird.
- Assets: Bilder mit Alt-Text und Bildunterschrift als eigene Objekte, nicht als Dateianhang irgendeines Absatzes.
Genau das ist der Unterschied zwischen einem klassischen System und einem Headless-CMS, also einem Redaktionssystem ohne eigenes Frontend, das Inhalte nur über eine Schnittstelle herausgibt. Wir nutzen dafür Sanity: Inhalte liegen als strukturierte Dokumente, das Frontend entscheidet getrennt davon, wie sie aussehen. Wenn du die Felder einmal sauber hast, kostet die dritte Sprache oder das vierte Template kein neues Projekt mehr.
Was sich beim Umzug immer ändert
Drei Dinge ändern sich bei jedem Systemwechsel, unabhängig davon, wohin du gehst. Wer sie vorher einplant, verliert keine Sichtbarkeit. Wer sie nachträglich entdeckt, repariert unter Zeitdruck.
- URLs. Neue Systeme bringen neue Pfadlogik mit, Kategorien verschwinden, Sprachsegmente kommen dazu. Jede Änderung braucht eine Weiterleitung.
- Rendering. Also die Frage, wo die Seite entsteht: beim Build, auf dem Server pro Anfrage oder im Browser. Das verändert Ladeverhalten und Auslieferung, auch wenn das Design identisch bleibt.
- Templates. Ein Template hängt im neuen System an einem Dokumenttyp. Seiten, die vorher handgebaute Sonderfälle waren, müssen entweder ins Modell passen oder als eigener Typ definiert werden.
Bei den URLs gilt: permanent sind 301 und 308, und Google nutzt sie als Signal dafür, dass das Ziel die kanonische, also die maßgebliche URL sein soll. 302, 303 und 307 sind temporär, Google folgt ihnen zwar, wertet sie aber nicht als Kanonisierungssignal, die alte URL kann im Index bleiben. Serverseitige Weiterleitungen sind laut Google die zuverlässigste Variante, danach kommt `meta refresh`, JavaScript-Weiterleitungen nur als letztes Mittel. Zwischenstationen nimmst du raus, die alte URL zeigt direkt auf das Endziel. Alle Details dazu stehen in unserem Artikel zur 301-Weiterleitung.
Ausgangssystem für Ausgangssystem: was beim Export zu erwarten ist
Die Phasen bleiben gleich, der Aufwand in Phase 4 nicht. Jedes Ausgangssystem gibt Inhalte anders heraus, und daran hängt, wie viel Transformation zwischen Export und Import liegt. Ein Satz pro System, der Rest steht im jeweiligen Detail-Artikel.
Ausgangssystem für Ausgangssystem: was beim Export zu erwarten ist
| Ausgangssystem | Was beim Export zu erwarten ist | Detail |
|---|---|---|
| WordPress | Der WXR-Export oder die REST-API beziehungsweise WPGraphQL geben Inhalte heraus, allerdings als HTML-Blöcke statt als saubere Felder. Die Transformation nach NDJSON ist die eigentliche Arbeit, nicht der Export. | [WordPress zu Next.js](/wissen/wordpress-zu-nextjs-migrieren) |
| TYPO3 | Der Auslöser ist selten das Design: Wer auf v11 oder v12 sitzt, ist aus dem kostenlosen Support heraus und zahlt ELTS oder fährt ohne Sicherheitsupdates. Inhalte und Konfiguration liegen in PHP und TypoScript, der eigenen Konfigurationssprache, der Export ist damit Entwicklerarbeit. | [TYPO3 zu Next.js](/wissen/typo3-zu-nextjs-migrieren) |
| Webflow | Der Export liefert HTML, CSS und JavaScript, aber weder die CMS-Inhalte noch die Interaktionen. Inhalte holst du als CSV pro Collection oder über die Webflow-Schnittstelle, Animationen werden mit GSAP, einer JavaScript-Bibliothek für Bewegung, oder mit CSS neu gebaut. | [Webflow zu Next.js](/wissen/webflow-zu-nextjs-migrieren) |
| Wix | Wix rechnet pro Website und Monat ab, von Light für 17 $ bis Business Elite für 159 $, und die Technik darunter ist gemietet. Diesen Weg sind wir mit unserer eigenen Website gegangen: Texte werden übernommen, die Struktur entsteht im neuen Content-Modell. | [Wix zu Next.js](/wissen/wix-zu-nextjs-migrieren) |
| Baukästen | Squarespace, Jimdo und IONOS binden dich beim Export: Du bekommst Markup zurück, aber kein nutzbares Content-Modell. Rechne mit Neuaufbau plus Textübernahme und plane die Felder vorher. | [Squarespace-Alternative](/wissen/squarespace-alternative) |
Eine Anmerkung zu WordPress, weil die Frage in jedem Gespräch kommt: Wir arbeiten nicht mit WordPress und bieten auch kein Headless WordPress an. Der Umbau auf headless kostet den vollen Relaunch-Aufwand und lässt die WordPress-Installation mit Updates, Plugin-Abhängigkeiten und Angriffsfläche trotzdem stehen, du betreibst danach zwei Systeme statt einem. Ausgenommen ist der Fall, dass auf der Installation Geschäftslogik liegt, die sich kurzfristig nicht ablösen lässt, etwa WooCommerce, eine Mitgliederverwaltung oder eine ERP-Schnittstelle. Headless trägt dort als befristeter Zwischenschritt, mit festem Enddatum. Verlässt ein Unternehmen WordPress, gehen wir direkt auf Sanity mit eigenem Frontend. TYPO3 behandeln wir anders: Das ist ein ernsthaftes Enterprise-System mit echten Stärken bei großen Redaktionen, Rechte- und Freigabestrukturen und im öffentlichen Sektor. Für eine reine Marketing-Website ist es meist überdimensioniert, weil TypoScript und das Backend Spezialisten brauchen und jedes Major-Upgrade ein Projekt ist.
Risiken und wie wir sie abfangen
Migrationen scheitern selten am Design und fast immer an Details, die niemand gemessen hat. Deshalb steht am Anfang die Messung und am Ende das Monitoring, nicht der Launch-Termin.
- Verlorene URLs. Gegenmittel ist der Vorher-Crawl mit Screaming Frog oder Ahrefs und eine Redirect-Map, in der jede alte URL ein Ziel hat. Kein Sammel-Redirect auf die Startseite.
- Rankings ohne Vergleichswert. Der Ranking-Snapshot vor dem Launch macht aus einem Bauchgefühl nach dem Launch einen Abgleich mit Zahlen.
- Inhalte, die im Transport verschwinden. Das Content-Modell wird vor dem Import gegen das Inventar geprüft, Dokument für Dokument und Feld für Feld.
- Interaktionen, die es im neuen System nicht gibt. Bei Webflow ist das der Normalfall, weil der Export sie nicht mitliefert. Sie werden mit GSAP oder CSS nachgebaut und vor dem Launch abgenommen.
- Stille nach dem Go-Live. Einreichung in Search Console und Bing, IndexNow, dann zwei Wochen 404-Report und Ranking-Abgleich. Fehler, die in dieser Zeit auffallen, kosten fast nichts.
Was du dabei nicht brauchst, sind Prozentversprechen. Niemand kann dir vorab sagen, wie sich einzelne Positionen entwickeln. Kontrollierbar ist der handwerkliche Teil, und der ist es, der Rankings hält.
Was eine CMS-Migration kostet und wie lange sie dauert
Eine Migration läuft bei uns als Relaunch-Projekt, und diese Pakete beginnen bei 8.000 € netto. Der Preis hängt an der Zahl der Seitentypen, nicht an der Zahl der Seiten: Fünfzig Wissen-Artikel auf einem Template kosten weniger als fünf Sonderseiten mit je eigenem Aufbau.
Zeitlich planen wir für eine Marketing-Website mit 10-30 Seiten typischerweise 3-6 Wochen bis Go-Live, das Monitoring kommt obendrauf. Was die Dauer verlängert, ist fast nie die Technik, sondern offene Inhalte: Texte, die noch geschrieben werden, und Freigaben, die auf Termine warten. Wer das Content-Inventar früh füllt, verkürzt das Projekt spürbar.
Danach drehen sich die laufenden Kosten. Eine Astro- oder Next.js-Website mit Sanity Free läuft typischerweise mit 0-20 $ Hosting pro Monat, das sind nahezu keine laufenden Plattformgebühren. Sanity Free umfasst 20 Plätze, 10.000 Dokumente, 100 GB Assets und 100 GB Bandbreite pro Monat inklusive Presentation Mode; Vercel Pro kostet 20 $ pro Monat und Entwickler-Platz inklusive 20 $ Nutzungsguthaben, ohne Grundgebühr pro Projekt. Für jede weitere Sprache berechnen wir keine zusätzliche Plattformgebühr. Eine breitere Aufschlüsselung findest du unter Webentwicklung Kosten.
Zielsystem entscheiden: wann Webflow reicht, wann Sanity mit eigenem Frontend
Die Entscheidung fällt an zwei Zahlen und einer Frage: Wie viele Seiten, wie viele Sprachen, und sollen Seiten künftig aus Daten entstehen. Alles andere ist Geschmack. Diese neun Kriterien reichen für eine belastbare Antwort.
Zielsystem entscheiden: wann Webflow reicht, wann Sanity mit eigenem Frontend
| Kriterium | Webflow | Astro oder Next.js mit Sanity |
|---|---|---|
| Seitenzahl | Komfortabel bis etwa 30 Seiten | Auch dreistellige Seitenzahlen aus einem Modell |
| Sprachen | Lokalisierung als Add-on, 9 $ pro Sprache und Monat bis 3 Sprachen, 29 $ bis 10 | Keine Gebühr pro Sprache |
| Mengengrenzen | 20.000 CMS-Items, 40 Collections im Premium-Tarif | Sanity Free mit 10.000 Dokumenten, Growth mit 25.000 |
| Content-Modell | Collections mit festen Feldern, ein Template hängt an einer Collection | Frei modellierbar, Referenzen zwischen Dokumenten |
| Rendering | Von der Plattform vorgegeben | Pro Seite wählbar: statisch, serverseitig, Islands |
| Programmatische Seiten | An Collection-Limits und Template-Bindung gebunden | Aus der Datenbank erzeugt, Umfang von dir bestimmt |
| Laufende Kosten | Ab 25 $ pro Monat und Website plus Workspace ab 19 $ | Typischerweise 0-20 $ Hosting pro Monat |
| Redaktion | Editor direkt auf der Seite | Sanity Presentation Mode mit Vorschau im Tagesbetrieb |
| Späterer Wechsel | Export ohne CMS-Inhalte und ohne Interaktionen | Inhalte liegen in deiner eigenen Datenbank |
Ein Hinweis zu programmatischen Seiten, weil sie oft der Anlass für den Wechsel sind: Sie funktionieren nur mit echter Substanz pro Seite. Fehlt die, stuft Google sie als Doorway-Pages ein: Seiten, die es allein wegen eines Keywords gibt. Wir sind damit auf unserer eigenen alten Website selbst aufgelaufen.
Wähle Webflow, wenn
Webflow ist eine ehrlich starke Zwischenlösung, und wir betreuen als zertifizierter Webflow-Partner Bestandskunden darauf. Für viele Websites ist es die richtige Größe.
- Deine Website bleibt bei etwa 30 Seiten und einer oder zwei Sprachen.
- Marketing soll Seiten selbst bauen können, ohne für jede Änderung ein Deployment anzustoßen.
- Programmatische Seiten aus Daten stehen nicht auf dem Plan.
- Eine monatliche Plattformgebühr pro Website ist für dich unkritisch.
Wähle Astro oder Next.js mit Sanity, wenn
Wir bauen standardmäßig mit Astro und Sanity. Next.js kommt zum Zug, sobald Login, Anwendungslogik oder serverseitige Daten pro Anfrage gebraucht werden. Ohne Entwicklungsteam gehst du diesen Weg nicht.
- Du planst mehr als zwei Sprachen oder übersetzte URL-Segmente.
- Inhalte sollen als strukturierte Objekte mit Referenzen vorliegen und Seiten daraus entstehen.
- Rendering, Caching, Schema und Sitemap sollen auf Code-Ebene steuerbar sein, auch für KI-Agenten über Schnittstelle und MCP-Server, also einen standardisierten Zugang für KI-Werkzeuge.
- Die Website soll ohne Gebühr pro Sprache und ohne Mengenlimit der Plattform wachsen.
So machen wir es
Wir sind den Weg selbst gegangen. in-sync.io lief auf Wix und liegt seit 2026 auf Next.js, Sanity und Vercel: 49 Wissen-Artikel, 10 Service-Seiten und 17 Stadtseiten aus einer Datenbank, zweisprachig mit hreflang, also den Auszeichnungen, die Google sagen, welche Sprachfassung für wen gilt, dazu Server-Rendering, llms.txt, IndexNow und FAQPage-Schema. Offen gesagt: Die alte Wix-Website war bei Google kaum sichtbar, die neue steht seit Juni 2026 und baut ihre Positionen erst auf.
Bei LeanWave, RFID-Lösungen für Textilservice und Wäschereien, haben wir statisch mit Astro gebaut, dazu Sanity, Tailwind und Vercel. Zweisprachig mit Englisch auf der Wurzel und Deutsch unter /de, übersetzten URL-Segmenten wie /solutions zu /de/loesungen und wechselseitigem hreflang inklusive x-default. 64 Dokumente, 86 Bild-Assets, ein Webhook stößt bei jeder Änderung einen neuen Build an, also ein automatischer Aufruf, der die Seite neu erzeugt. Die Redaktion arbeitet im Presentation Mode und sieht Änderungen in der Vorschau.
Yarowa zeigt die andere Variante. Der internationale B2B-Kunde kam aus Webflow, wir haben den Export 1:1 nach Astro portiert und auf Vercel gehostet: 5 Sprachen, 21 Seiten-Templates, 163 Sections, Design unverändert. Der Umbau auf Sanity mit Presentation Mode ist geplant. Das ist der pragmatische Pfad, wenn das Design bleiben soll und zuerst die Auslieferung besser werden muss. Wie wir Projekte technisch aufsetzen, steht auf unserer Seite zur Webentwicklung, den kompletten Prozess inklusive Monitoring beschreiben wir unter Website-Relaunch.
Häufige Fragen
Eine CMS-Migration ist der Wechsel des Redaktionssystems hinter einer Website. Inhalte werden aus dem alten System geholt, in ein neues Content-Modell überführt und über neue Templates ausgeliefert. Dazu gehören immer neue URLs mit Weiterleitungen. Bei einer Marketing-Website mit 10-30 Seiten dauert das typischerweise 3-6 Wochen bis Go-Live.
Wir rechnen eine Migration als Relaunch-Projekt ab, unsere Relaunch-Pakete starten bei 8.000 € netto. Der Preis hängt an der Zahl der Seitentypen und Sprachen, nicht an der Zahl der Seiten. Danach läuft eine Astro- oder Next.js-Website mit Sanity Free typischerweise mit 0-20 $ Hosting pro Monat.
Nicht, wenn jede alte URL per 301 oder 308 auf ihr inhaltliches Gegenstück zeigt. Google wertet diese permanenten Weiterleitungen als Signal, dass das Ziel die kanonische URL sein soll. Wir erstellen dafür vor dem Launch einen Crawl und einen Ranking-Snapshot und prüfen zwei Wochen lang 404-Fehler und Positionen.
Für eine Marketing-Website mit 10-30 Seiten planen wir 3-6 Wochen bis Go-Live, das Monitoring kommt obendrauf. Verzögerungen entstehen fast immer durch offene Texte und Freigaben, nicht durch Technik. Wer das Content-Inventar früh füllt und Inhalte parallel finalisiert, bleibt im unteren Bereich dieser Spanne.
Ein Redesign reicht, wenn deine Inhalte bereits in sauberen Feldern liegen und nur das Aussehen stört. Ein Systemwechsel lohnt sich, sobald Felder fehlen, eine weitere Sprache ansteht, Mengengrenzen greifen oder der kostenlose Sicherheits-Support ausläuft, wie bei TYPO3 v11 im Oktober 2024 und v12 im April 2026.
Nein. Der Umbau auf headless kostet den vollen Relaunch-Aufwand und lässt die WordPress-Installation mit Updates, Plugin-Abhängigkeiten und Angriffsfläche trotzdem stehen, du betreibst danach zwei Systeme statt einem. Einzige Ausnahme ist Geschäftslogik wie WooCommerce oder eine ERP-Schnittstelle, dann als Übergangslösung mit Enddatum.
Nächster Schritt
Schick uns deine aktuelle URL und die Zahl deiner Sprachen, dann sagen wir dir, ob ein Redesign reicht oder ein Systemwechsel das Richtige ist.
