Wie lange dauert eine CMS-Migration wirklich?

Eine veraltete Website lässt sich nicht einfach über ein Wochenende in ein neues CMS verschieben. Wer fragt: „Wie lange dauert CMS Migration?“, braucht deshalb keine pauschale Zahl, sondern eine belastbare Einschätzung für das eigene Projekt. Denn zwischen einer kleinen Unternehmenswebsite und einer mehrsprachigen Plattform mit Schnittstellen, Redaktionsworkflows und mehreren tausend Inhalten liegen Wochen oder Monate.

Für viele mittelständische Websites liegt ein realistischer Rahmen bei drei bis sechs Monaten. Überschaubare Projekte können schneller umgesetzt werden. Komplexe Migrationen, etwa auf ein aktuelles TYPO3-System, benötigen häufig sechs bis zwölf Monate oder mehr. Entscheidend ist nicht allein die Anzahl der Seiten. Datenqualität, technische Abhängigkeiten und der Anspruch an Design, Barrierefreiheit, Performance und SEO bestimmen den tatsächlichen Aufwand.

Wie lange dauert eine CMS-Migration im Durchschnitt?

Eine CMS-Migration besteht aus mehreren Phasen, die sich nicht beliebig verkürzen lassen. Die technische Übertragung von Daten ist dabei oft nur ein Teil der Arbeit. Vorher muss geklärt werden, welche Inhalte, Funktionen und Prozesse überhaupt in die neue Plattform gehören.

Bei einer kleineren Website mit klarer Struktur, wenigen Inhaltstypen und ohne externe Schnittstellen kann die Umsetzung in acht bis zwölf Wochen möglich sein. Voraussetzung ist, dass Inhalte bereitstehen, Entscheidungen zügig getroffen werden und das Zielsystem weitgehend auf bewährten Komponenten aufbaut.

Für eine typische Unternehmenswebsite mit individuellem Design, mehreren Sprachen, umfangreichen Inhaltsbereichen und SEO-relevanten Weiterleitungen sind drei bis sechs Monate realistischer. Geht es um Portale mit geschützten Bereichen, Produktdaten, CRM- oder ERP-Anbindungen, individuellen Anwendungen oder komplizierten Freigabeprozessen, sollte der Zeitplan deutlich großzügiger sein.

Eine seriöse Planung benennt daher keine feste Dauer, bevor Bestand, Ziele und Risiken geprüft wurden. Wer nach zwei Stunden Analyse einen verbindlichen Endtermin für ein komplexes Projekt verspricht, plant meist mit Annahmen statt mit Fakten.

Die Phasen einer Migration und ihr Zeitbedarf

Bestandsaufnahme und Zielbild

Am Anfang steht die Analyse des bestehenden Systems. Welche Seiten, Medien und Dokumente existieren? Welche Funktionen werden tatsächlich genutzt? Gibt es individuelle Erweiterungen, Formulare, Schnittstellen oder Berechtigungsmodelle? Ebenso wichtig: Welche Bereiche sind veraltet, doppelt oder fachlich nicht mehr relevant?

Diese Phase dauert bei kleineren Websites oft ein bis zwei Wochen, bei gewachsenen Plattformen mehrere Wochen. Sie spart später Zeit, weil sie verhindert, dass unnötige Altlasten übernommen werden. Eine Migration ist ein guter Anlass, Inhalte zu bereinigen und die Informationsarchitektur neu zu ordnen - nicht nur, Daten unverändert umzuziehen.

Konzeption, Design und technische Planung

Auf Basis der Analyse entstehen Inhaltsmodelle, Seitenstrukturen, Rollen und Workflows. Bei einem Relaunch kommen UX-Konzept und Design hinzu. Auch technische Entscheidungen gehören in diese Phase: Welche Erweiterungen werden eingesetzt? Welche Daten werden automatisiert importiert? Wie werden Mehrsprachigkeit, Suche, Formulare oder Login-Bereiche abgebildet?

Je nach Umfang beansprucht diese Arbeit zwei bis sechs Wochen. Projekte werden unnötig langsam, wenn zentrale Fragen erst während der Entwicklung entschieden werden. Ein abgestimmtes Zielbild schafft dagegen Verlässlichkeit bei Budget, Prioritäten und Terminen.

Entwicklung und Datenmigration

Danach wird das neue CMS eingerichtet, konfiguriert und individuell erweitert. Templates, Komponenten und Funktionen werden entwickelt. Parallel werden Inhalte aufbereitet und in das neue Datenmodell überführt. Manchmal ist ein automatisierter Import sinnvoll, manchmal eine redaktionelle Übernahme. Oft ist eine Kombination aus beidem die bessere Lösung.

Für die Entwicklung und Übertragung sollten meist vier bis zwölf Wochen eingeplant werden. Automatisierung beschleunigt große Datenmengen, löst aber keine inhaltlichen Probleme. Wenn Überschriften, Bildrechte, Dokumente oder Metadaten im Altsystem uneinheitlich gepflegt sind, muss diese Qualität vor oder nach dem Import bearbeitet werden.

Qualitätssicherung, SEO und Abnahme

Vor dem Go-live wird geprüft, ob Funktionen, Formulare, Berechtigungen und Darstellungen auf relevanten Geräten korrekt arbeiten. Bei professionellen Projekten gehören Performance, Sicherheitskonfiguration und Barrierefreiheit nach BITV beziehungsweise WCAG ebenfalls in die Qualitätssicherung.

Besondere Aufmerksamkeit verdient die Suchmaschinenoptimierung. Relevante URLs benötigen saubere Weiterleitungen, wichtige Meta-Daten müssen erhalten bleiben und die Indexierung der neuen Website wird kontrolliert. Diese Arbeiten dauern häufig zwei bis vier Wochen, bei komplexen Seitenstrukturen länger. Sie erst kurz vor der Veröffentlichung einzuplanen, erhöht das Risiko für Sichtbarkeitsverluste.

Go-live und Stabilisierung

Der eigentliche Launch ist ein Termin, nicht das Ende des Projekts. Nach der Veröffentlichung werden Monitoring, Fehlerprotokolle, Weiterleitungen und Nutzerfeedback kontrolliert. Häufig werden dabei kleinere Anpassungen sichtbar, die im Testsystem nicht auffallen konnten.

Für diese Stabilisierungsphase sind ein bis zwei Wochen mit klaren Zuständigkeiten sinnvoll. Bei geschäftskritischen Plattformen kann ein abgestimmter Support-Zeitraum darüber hinaus notwendig sein.

Was eine CMS-Migration verzögert

Nicht jedes Risiko lässt sich vermeiden. Viele Verzögerungen lassen sich jedoch früh erkennen und einplanen. Besonders häufig bremsen vier Faktoren den Fortschritt:

• Unklare Anforderungen: Wenn erst während der Umsetzung entschieden wird, welche Funktionen, Inhalte oder Integrationen benötigt werden, entstehen Nacharbeiten.
• Schwache Datenqualität: Dubletten, unvollständige Medieninformationen, alte Dokumente und uneinheitliche Formate machen jeden Import aufwendiger.
• Abhängigkeiten von Drittsystemen: Schnittstellen zu CRM, ERP, PIM, Newsletter-Software oder Single Sign-on benötigen Abstimmung, Tests und oft externe Ansprechpartner.
• Langsame Freigaben: Fehlende Ansprechpartner oder umfangreiche Abstimmungsrunden bei Inhalten und Design verschieben Termine stärker als die eigentliche Programmierung.

Auch der Umfang der redaktionellen Mitarbeit wird regelmäßig unterschätzt. Ein neues CMS verbessert die Pflege, ersetzt aber nicht die fachliche Prüfung von Texten, Bildern, Downloads und Ansprechpartnern. Unternehmen sollten dafür intern feste Verantwortlichkeiten und realistische Zeitfenster vorsehen.

Schnell migrieren oder gründlich modernisieren?

Eine schnelle technische Migration kann sinnvoll sein, wenn ein System aus dem Support läuft oder ein Sicherheitsrisiko besteht. Dann steht im Vordergrund, den Betrieb zeitnah auf eine unterstützte Version zu bringen. Design und größere strukturelle Veränderungen können anschließend schrittweise folgen.

Ein umfassender Relaunch bietet dagegen die Chance, technische Schulden abzubauen, Inhalte neu zu bewerten und die Nutzerführung zu verbessern. Er dauert länger und verlangt mehr Entscheidungen, liefert aber häufig ein besser wartbares Ergebnis. Gerade bei TYPO3-Projekten ist es oft sinnvoll, die Migration mit einer klaren Komponentenstrategie und zeitgemäßen Redaktionsprozessen zu verbinden, statt alte Sonderlösungen eins zu eins nachzubauen.

Der richtige Weg hängt von Risiko, Budget und Geschäftszielen ab. Ein Unternehmen mit akutem Update-Bedarf hat andere Prioritäten als eine Organisation, die ihre digitale Plattform für mehrere Jahre strategisch neu aufstellen möchte.

So entsteht ein realistischer Zeitplan

Ein tragfähiger Projektplan beginnt mit einer strukturierten Voranalyse. Dabei werden Seitenumfang, Inhaltstypen, technische Erweiterungen, Schnittstellen, Rollen und rechtliche Anforderungen erfasst. Daraus lassen sich Arbeitspakete, Verantwortlichkeiten und Abhängigkeiten ableiten.

Wichtig sind feste Entscheidungswege auf Kundenseite. Wer Design, Inhalte oder Fachanforderungen freigibt, sollte von Beginn an benannt sein. Ebenso hilfreich sind Prioritäten: Welche Bereiche müssen zum Start verfügbar sein, welche können in eine zweite Ausbaustufe? Ein gestaffelter Go-live reduziert das Projektrisiko, wenn nicht alle Funktionen gleichzeitig geschäftskritisch sind.

Puffer gehören ebenfalls in jeden Zeitplan. Sie sind kein Zeichen schlechter Planung, sondern berücksichtigen Realität: Rückfragen zu Schnittstellen, zusätzliche Datenbereinigung oder Korrekturen nach Tests treten auch in gut vorbereiteten Projekten auf.

Eine CMS-Migration ist dann planbar, wenn Technik, Inhalte und interne Entscheidungen als zusammenhängende Aufgabe behandelt werden. Wer vor dem Start sauber analysiert und auf nachhaltige Entwicklung setzt, verkürzt nicht zwangsläufig jede Phase - vermeidet aber teure Umwege und schafft eine Plattform, die nach dem Go-live langfristig zuverlässig weiterentwickelt werden kann.