Die meisten Relaunch-Projekte starten mit Design-Mockups und Feature-Wunschlisten. Was danach passiert, bestimmt, ob das neue System nach sechs Monaten lauft oder lahmt. Die kritischen Fehler entstehen nicht beim Layout, sondern bei Datenmigrationen, internen Abläufen und der Annahme, das alte System sei nur alt, nicht auch komplex. Wer das unterschätzt, zahlt später für Wartungsstunden, die keiner eingeplant hat.
Datenmigration: Der unsichtbare Aufwand, der Budgets sprengt
Der Umzug von Inhalten in ein neues CMS ist selten ein reines Kopieren. Typischerweise unterschätzt werden drei Bereiche: die Masse der Seiten, die Qualität der vorhandenen Daten und die Verknüpfungen zwischen ihnen.
Eine Website mit 500 öffentlichen Seiten kann im Redaktionssystem gut 3.000 bis 5.000 Datensätze umfassen – entworfene Seiten, archivierte Versionen, Medien mit Varianten, Meta-Daten, die nie gepflegt wurden. Niemand zählt sie vor dem Relaunch. Die Schätzung "ein paar Tage Migration" entsteht aus der Sicht der Startseite, nicht aus der Datenbank.
Hinzu kommt: Inhalte, die im alten System funktionierten, passen strukturell nicht ins Neue. Ein Textfeld wird zu einem strukturierten Block. Eine Galerie, die per Shortcode eingebunden war, braucht nun ein eigenes Format. Jede dieser Umstellungen erfordert manuelle Nacharbeit oder individuelle Skripte – beides kostet Zeit, die im Angebot selten steht.
Besonders brisant: Medien-Dateien mit unklaren Urheberrechten, veraltete Einbettungen externer Karten oder verwaiste Formulare. Wer sie migriert, übernimmt Probleme. Wer sie auslässt, verliert Inhalte, auf die interne Verlinkungen zeigen. Die Entscheidung fällt meist unter Zeitdruck und wird später bereut.
Redaktions-Workflows: Wer nach dem Relaunch arbeitet, wird vorher nicht gefragt
Ein neues CMS verändert den Alltag derjenigen, die damit arbeiten. Wenn diese Personen nicht vorher einbezogen werden, entsteht ein System für theoretische Nutzer – mit Rechten, die niemand braucht, und Freigabeschritten, die niemand durchlaufen will.
Typisches Szenario: Im alten System hat eine Person alle Inhalte gepflegt. Im neuen soll ein mehrschichtiger Freigabeprozess abgebildet werden, den die Geschäftsführung wünscht. Nach drei Monaten wird er umgangen oder ignoriert, weil er das Publizieren um Tage verzögert. Das System gewinnt, die Praxis verliert.
Vor dem Relaunch sollte geklärt sein: Wer legt Inhalte an? Wer prüft? Wer darf veröffentlichen? Wer ändert Menüs oder Strukturelemente? Wer ist für die technische Pflege zuständig? Wenn diese Rollen unklar sind, wird das CMS mit einem hypothetischen Rechtekonzept betrieben, das nach der Einführung mühsam korrigiert werden muss.
Technische Altlasten: Was im alten System versteckt war, kommt im neuen doppelt
Alte CMS-Installationen sammeln Überbleibsel: Plugins, die einmal für eine Kampagne installiert wurden und nie deinstalliert. Individuelle Anpassungen, deren Zweck niemand mehr kennt. Datenbank-Einträge, die von externen Systemen geschrieben wurden, die lange abgeschaltet sind.
Diese Altlasten verbergen sich in drei Ebenen. Die erste ist sichtbar: überflüssige Plugins, veraltete Themes. Die zweite ist technisch: angepasste Core-Dateien, versteckte Cron-Jobs, manuell eingetragene Server-Konfigurationen. Die dritte ist organisatorisch: Prozesse, die um Fehler im alten System herum gewachsen sind.
Ein Beispiel für die dritte Ebene: Eine Redaktion erstellt keine Beiträge im CMS, sondern in Textdateien, weil das alte Backend zu langsam war. Das neue System ist schnell – aber der Prozess bleibt, weil niemand danach gefragt hat. Die technische Schuld wird zur organisatorischen.
Wer beim Relaunch nicht analysiert, was wirklich genutzt wird und warum, überträgt Arbeitsweisen in ein System, das sie nicht mehr erzwingt. Das Ergebnis ist ein modernes CMS mit altem Betriebsmodus – und neuen Problemen, weil die alten Umgehungslösungen nicht mehr passen.
URL-Struktur und Weiterleitungen: Die vermeintliche Kleinigkeit mit größerer Nachwirkung
Die Adressen einer Website sind kein Nebenprodukt, sondern Bestandteil ihrer ökonomischen Substanz. Externe Verlinkungen, Lesezeichen, Suchmaschineneinträge, interne Dokumentation – alles zeigt auf bestimmte URLs. Wer sie ändert, ohne die Folgen zu steuern, verwirft diesen Wert.
Die häufigste Fehleinschätzung: Ein automatisches Redirect-Regelwerk aus dem CMS reicht. Das stimmt nur für Standardfälle. Wenn sich die Struktur ändert – aus /produkt-kategorie/name wird /angebote/name/ –, greifen einfache Regeln nicht mehr. Jede alte URL muss auf ihre neue Entsprechung abgebildet werden, manuell oder mit aufwändigen Mustererkennungen.
Besonders kritisch: URLs, die in gedruckten Materialien, E-Mail-Signaturen oder externen Systemen stehen. Sie werden nicht von Suchmaschinen erfasst und tauchen erst als Fehler auf, wenn Kunden sie aufrufen. Eine vollständige Weiterleitungsstrategie erfordert die Analyse aller Eingangspunkte, nicht nur der organischen Suche.
Wer hier spart, zahlt später in verlorenem Traffic, verwirrten Nutzern und dem Aufwand, tote Links nachzubearbeiten. Die Preistransparenz bei Website-Projekten hängt maßgeblich davon ab, ob solche Punkte in der Anforderungsklärung stehen oder nachträglich hinzugefügt werden müssen.
Zugriffsrechte und Rollen: Wenn aus fünf Redakteuren plötzlich zwanzig werden
Ein Relaunch ist oft der Moment, in dem versteckte Nutzer sichtbar werden. Das alte System hatte einen Admin-Zugang, den fünf Personen kannten. Tatsächlich nutzten zwölf verschiedene Mitarbeiter denselben Login, weil niemand weitere angelegt hatte. Das neue System erzwingt individuelle Konten – und plötzlich ist die Lizenzierung teurer als erwartet.
Das Problem ist nicht die Zahl der Nutzer allein, sondern ihre Verteilung auf Rollen. Ein CMS mit granularen Rechten verführt dazu, ein komplexes Rollenkonzept zu entwerfen: Redakteur, Chefredakteur, Prüfer, Veröffentlicher, Administrator, Entwickler. Jede Rolle muss gepflegt, dokumentiert und bei Personalaustritten angepasst werden.
Die pragmatischere Frage lautet: Was ist das Minimum an Rollen, das den Betrieb erlaubt? Wenn eine Person beide Aufgaben übernehmen kann, sollte das System das nicht verbieten. Komplexe Rechtestrukturen entstehen oft aus der Angst vor Fehlern, nicht aus tatsächlichem Missbrauch. Sie kosten aber laufend Verwaltungsaufwand.
Integrationen und Schnittstellen: Der externe Dienst, den niemand mehr kennt
Fast jede Website, die länger als drei Jahre läuft, hat Verbindungen zu externen Systemen, die in keiner aktuellen Dokumentation stehen. Eine Newsletter-Anmeldung, die über einen speziellen Endpunkt läuft. Ein Bewertungs-Widget, das monatlich Daten abruft. Eine Anbindung an ein Warenwirtschaftssystem, die einmalig eingerichtet und nie wieder angefasst wurde.
Diese Schnittstellen funktionieren, solange sich nichts ändert. Beim Relaunch ändert sich alles. Die neue URL-Struktur bricht die Callback-Adresse. Das andere Theme lädt die JavaScript-Datei nicht mehr an der erwarteten Stelle. Die API-Anfragen kommen von einer anderen IP, die nicht freigeschaltet ist.
Die Herausforderung ist nicht technisch, sondern organisatorisch: Niemand weiß mehr, welche Integrationen existieren. Die Person, die sie eingerichtet hat, ist nicht mehr da. Der Dienstleister wurde gewechselt. Die Dokumentation existiert nicht. Der Relaunch deckt diese Lücken auf, indem er sie bricht.
Vor dem Umzug sollte ein Inventar erstellt werden: Welche externen Systeme rufen diese Website auf? Welche ruft sie auf? Welche Daten fließen in welche Richtung? Das ist mühsam, aber weniger aufwändig als die Fehlersuche nach dem Go-live.
Langzeitkosten: Was das neue CMS nach drei Jahren wirklich kostet
Die Entscheidung für ein CMS basiert oft auf dem Angebotspreis und den versprochenen Features. Die laufenden Kosten bleiben im Hintergrund. Sie entstehen aus vier Quellen: Lizenzgebühren, Wartungsverträge, notwendige Anpassungen und der interne Aufwand für Bedienung und Pflege.
Lizenzmodelle variieren stark. Ein Open-Source-System ohne Kaufpreis kann teurer sein als ein kostenpflichtiges, wenn es für jede Erweiterung individuelle Entwicklung braucht. Ein SaaS-CMS mit monatlicher Gebühr schafft Planungssicherheit, aber auch Abhängigkeit. Der Wechsel ist später schwierig, weil die Daten in einer proprietären Struktur liegen.
Wartungskosten sind der unterschätzte Posten. Ein CMS ohne regelmäßige Pflege wird zur Sicherheitslücke und zur Altlast. Wer das nicht einkalkuliert, findet sich in der Situation wieder, die billige WordPress-Wartung beschreibt: vermeintlich günstige Angebote, die bei genauerem Hinsehen Lücken offenbaren oder durch Zusatzleistungen teuer werden.
Der interne Aufwand ist die versteckteste Kostenart. Ein System, das täglich mühsam bedient werden muss, bindet Arbeitszeit, die nicht als CMS-Kosten erscheint. Nach drei Jahren summiert sich das über die Lohnkosten eines halben Stellenanteils – mehr als jede Lizenzgebühr.
Der Moment danach: Warum der Go-live erst der Anfang ist
Der Tag der Live-Schaltung wird als Ziel gefeiert, obwohl er der Übergang zu einer neuen Phase ist. Die ersten Wochen nach dem Relaunch zeigen, was vorher nicht getestet wurde: Lastspitzen bei echtem Traffic, unerwartete Nutzerverhalten, Inhalte, die unter Druck nicht funktionieren.
Typische Nachwirkungen: Die Weiterleitungen greifen nicht für alle URLs. Die Suchmaschinen haben die neue Struktur noch nicht indexiert, der Traffic bricht kurzzeitig ein. Ein Redakteur findet den neuen Workflow unpraktisch und arbeitet um das System herum. Eine Schnittstelle meldet Fehler, die im Test nicht auftraten, weil dort keine echten Daten liefen.
Diese Phase erfordert Ressourcen, die selten eingeplant sind: technische Unterstützung für schnelle Korrekturen, Kommunikation mit Nutzern, die Probleme melden, und die Bereitschaft, Entscheidungen zu revidieren, die unter Zeitdruck getroffen wurden.
Der Relaunch als Betriebsprojekt endet nicht mit der Schaltung, sondern mit der Stabilisierung des neuen Zustands. Das kann Wochen oder Monate dauern. Wer das Team vorher aufgelöst oder das Budget verbraucht hat, steht ohne Rückhalt da.
Relaunch oder schrittweise Modernisierung?
Die Entscheidung zwischen komplettem Neubau und evolutionärer Weiterentwicklung hängt von drei Faktoren ab: der technischen Tragfähigkeit des Altsystems, der organisatorischen Bereitschaft für Veränderung und der verfügbaren Konzentration.
Ein Relaunch ist die bessere Wahl, wenn das alte System technisch nicht mehr wartbar ist – ausgediente PHP-Versionen, nicht mehr unterstützte Datenbanken, Core-Änderungen, die Updates verhindern. Auch wenn sich die Anforderungen fundamental geändert haben, lohnt der Sprung: aus Präsentationswebsite wird E-Commerce, aus Einzelmandant wird Multisite.
Die schrittweise Modernisierung ist vorzuziehen, wenn das bestehende System technisch intakt ist, aber inhaltlich oder gestalterisch veraltet. Sie erlaubt es, Veränderungen zu testen, zu messen und anzupassen, statt alles auf einmal umzustellen. Der Nachteil: Sie erfordert Disziplin, Zwischenzustände zu akzeptieren, und eine Organisation, die kontinuierlich Ressourcen bereitstellt.
Viele Unternehmen wählen den Relaunch, weil er ein Ende setzt und einen Neuanfang verspricht. Das ist psychologisch verständlich, ökonomisch riskant. Der scheinbar saubere Schnitt verdeckt, dass Komplexität nicht verschwindet, sondern nur an einen anderen Ort verschoben wird – in die Migration, die Einarbeitung, die Nachbesserung.
---
Wer einen Relaunch plant, sollte den Fokus von "Wie soll es aussehen?" verschieben auf "Wie wird es betrieben?". Die Antwort darauf bestimmt, ob das neue System nach einem Jahr noch genutzt wird – oder ob es zur nächsten Altlast wird, die irgendwann den nächsten Relaunch erzwingt.
Wenn Sie bei der Planung Unterstützung brauchen oder prüfen möchten, ob ein Angebot die richtigen Fragen beantwortet, können Sie uns kontaktieren. Wir schauen uns das aus Sicht des späteren Betriebs an.
