50% Wartungskosten gespart. Ziel erreicht? Nicht ganz.

50% Wartungskosten gespart. Ziel erreicht? Nicht ganz.

Warum Website-Konsolidierung mehr ist als ein technisches Projekt

Letzte Woche. Das Jahresendgespräch bei einem unserer größten Kunden aus dem Forschungssektor. Die Bilanz für 2025? Beeindruckend. Durch die Konsolidierung verschiedener Websites auf unterschiedlichen Servern in ein modernes, barrierefreies TYPO3 13-System konnte der Kunde bereits über 50% (> 100K €) der jährlichen Wartungskosten einsparen.

Mission accomplished? Noch nicht ganz.

Denn was in diesem Gespräch deutlich wurde: Nach der technischen Konsolidierung werden die organisatorischen Herausforderungen erst richtig sichtbar. Oder anders gesagt: Die Technik steht, aber die Prozesse müssen jetzt nachziehen.

Vorweg: Warum Website-Konsolidierung gerade jetzt Sinn macht

In Zeiten wirtschaftlicher Unsicherheit und stagnierendem Wachstum müssen Organisationen ihre IT-Budgets besonders sorgfältig einsetzen. Die Konsolidierung verteilter Website-Landschaften ist hier ein strategischer Hebel mit messbaren Einsparungen.

TYPO3 eignet sich für solche Konsolidierungsprojekte besonders gut – und das aus gutem Grund:

Mandantenfähigkeit: Mehrere Websites können auf einer TYPO3-Instanz betrieben werden, ohne dass sie sich gegenseitig beeinflussen. Jede Site behält ihre eigene Identität, teilt sich aber die technische Infrastruktur.

Multi-Site-Management: Zentrale Verwaltung aller Websites über ein Backend. Updates, Sicherheitspatches und neue Features werden einmal eingespielt und gelten für alle Sites – statt für jede einzeln.

Ausgeklügeltes Rechtesystem: Verschiedene Teams können an ihren jeweiligen Sites arbeiten, ohne dass sie Zugriff auf andere Bereiche benötigen. Globale Administratoren behalten den Überblick, lokale Redakteure bleiben in ihrem definierten Bereich.

Mehrsprachigkeit: Gerade für internationale Organisationen oder Institutionen mit mehrsprachigen Anforderungen bietet TYPO3 eine native Mehrsprachigkeits-Unterstützung, die über alle konsolidierten Sites hinweg konsistent funktioniert.

Die technischen Voraussetzungen für erfolgreiche Konsolidierung sind also gegeben. Aber wie unser Projekt zeigt: Die Technologie ist nur der Anfang.

Das Problem mit dem "einfachen" Feature-Request

Eine Mitarbeiterin aus einem Team hatte einen scheinbar simplen Wunsch geäußert: Die Teasertexte von Newsmeldungen sollen fett dargestellt werden. Breiter Konsens im Team, sieht gut aus, logische Anforderung, sollte schnell umgesetzt sein.

Wochen später: Immer noch nicht erledigt.

Warum? Weil bei schneller Umsetzung die Schrift unscharf im Browser dargestellt wird. Ursache: Ein fehlender Font-Schnitt, der erst lizenziert werden muss. Der Vorgang läuft über den Einkauf, muss dort genehmigt werden, und so weiter.

Das eigentliche Problem hier: Der fehlende Rückkanal in der Kommunikation. Die Anfragerin wusste nicht, warum ihr "einfacher" Wunsch sich so lange hinzieht. Aus ihrer Sicht wirkt es wie Untätigkeit oder mangelnde Priorisierung. Aus Sicht der IT ist es ein komplexer Beschaffungsvorgang mit rechtlichen und technischen Abhängigkeiten.

Unser Rat: Transparenz schafft Verständnis

Richten Sie für Feature-Requests ein einfaches Tracking-System ein, bei dem der Status und die Gründe für Verzögerungen für alle Beteiligten sichtbar sind. Es muss kein komplexes Ticket-System sein – oft reicht ein gemeinsames Kanban-Board oder eine gesharte Excel-Liste mit Statusupdates. Die Investition in Kommunikation zahlt sich am Ende in Akzeptanz aus.

Globale Änderungen vs. lokale Bedürfnisse

Ein Team möchte, dass Überschriften in ihrem Projekt anders dargestellt werden – ästhetische Gründe, völlig nachvollziehbar. Das Problem: Bei konsolidierten Websites teilen sich alle Projekte ein gemeinsames CSS. Eine Änderung hier betrifft alle anderen Websites.

Was nach außen wie Sturheit aussieht ("Warum könnt ihr nicht einfach die H2 größer machen?"), ist in Wahrheit die Verantwortung, die Interessen aller Teams im Blick zu behalten.

Der Konflikt: Projektteams denken projektbezogen. Die IT muss systemübergreifend denken.

Unser Rat: Governance früh etablieren

Definieren Sie von Anfang an klare Governance-Regeln für konsolidierte Systeme:

  • Welche Änderungen sind projektspezifisch möglich?
  • Welche erfordern eine Abstimmung über alle Teams hinweg?
  • Wer trifft bei Uneinigkeit die finale Entscheidung?

Ein regelmäßiges Austauschformat (z.B. monatliches "Web-Governance-Meeting") kann hier Wunder wirken. Dort werden globale Änderungswünsche besprochen, priorisiert und konsentiert, bevor sie in die Umsetzung gehen.

Die versteckten Kosten neuer Features

Features werden beauftragt, entwickelt, abgenommen – fertig? Leider nein. Jedes neue Feature muss bei künftigen TYPO3-Updates getestet und gegebenenfalls angepasst werden.

Die initiale Entwicklung kostet vielleicht 5.000 Euro. Was aber oft übersehen wird: Bei jedem größeren Update fallen Folgekosten an – für Tests, Anpassungen, Dokumentation.

Unsere Erfahrung: Diese Folgekosten lassen sich nur schwer beziffern, liegen aber erfahrungsgemäß bei etwa 10% der initialen Entwicklungskosten pro Jahr. Nach drei Jahren bzw. einem "TYPO3-LTS-Doppelsprung" (z.B. von TYPO3 12 auf 14) bedeutet das: Aus 5.000 Euro werden effektiv 6.500 Euro über die Lebensdauer.

Unser Rat: Total Cost of Ownership kommunizieren

Machen Sie diese versteckten Kosten transparent, bevor Features beauftragt werden. Fragen Sie sich:

  • Ist dieses Feature wirklich notwendig oder gibt es eine standardisierte Alternative?
  • Können vorhandene TYPO3-Bordmittel genutzt werden statt Custom Development?
  • Rechtfertigt der Nutzen die langfristigen Wartungskosten?
  • Wie viele Sites haben einen echten Mehrwert dieses neuen Features?

Push vs. Pull: Wer muss wann informiert werden?

Eine scheinbar banale Frage sorgte für intensive Diskussionen: Wer muss bei welcher Änderung in welchem Umfang benachrichtigt werden?

Team A möchte bei jeder Änderung am System sofort informiert werden (Push-Prinzip). Team B findet das übertrieben und möchte sich Informationen bei Bedarf selbst abholen (Pull-Prinzip). Die Wahrheit liegt wie so oft in der Mitte.

Unser Rat: Differenzierte Kommunikationsregeln

Definieren Sie verschiedene Kategorien:

  • Breaking Changes: Müssen aktiv an alle kommuniziert werden (Push)
  • Neue Features: Ankündigung reicht, Details auf Abruf (Push + Pull)
  • Bugfixes/Wartung: Changelog pflegen, keine aktive Benachrichtigung (Pull)
  • Sicherheitsupdates: Sofortige Information an alle (Push)

Wichtig ist, dass diese Regeln dokumentiert und allen Beteiligten bekannt sind. Ein gut gepflegtes Changelog und regelmäßige (z.B. quartalsweise) Update-Meetings schaffen hier Klarheit.

Fazit: Technologie ist der einfache Teil

Die Konsolidierung von Websites in ein modernes TYPO3-System bringt massive Kostenvorteile – 50% Ersparnis bei den Wartungskosten sind keine Seltenheit. Die Performance steigt, die Barrierefreiheit verbessert sich, Updates werden einfacher.

Aber: Die eigentliche Herausforderung beginnt nach dem Go-Live. Es geht dann darum, Prozesse zu etablieren, die der neuen, konsolidierten Struktur gerecht werden:

  1. Transparenz in der Kommunikation: Feature-Requests brauchen nachvollziehbare Status-Updates
  2. Klare Governance: Wer entscheidet was auf globaler vs. lokaler Ebene?
  3. Realistische Kostenrechnung: Total Cost of Ownership statt nur initiale Entwicklungskosten
  4. Differenzierte Information: Push und Pull intelligent kombinieren

Die gute Nachricht: Diese Herausforderungen sind lösbar. Es braucht nur die Bereitschaft, sie frühzeitig zu adressieren statt sie als "weiche Faktoren" beiseite zu schieben.

Haben Sie Fragen zu Website Konsolidierung mit TYPO3? Ich helfe gerne weiter.

Sandra Pohl

Ich berate Sie gerne

Hallo, mein Name ist Sandra Pohl und ich helfe Ihnen gerne - schnell und unkompliziert. Rufen Sie mich an oder hinterlassen Sie mir im Kontaktformular Ihre Nummer.

Sandra Pohl  |  Product Owner & Project Manager

KI in TYPO3 – von der Spielerei zur echten Arbeitserleichterung

Warum in2code bereits sechs KI-Integrationen für TYPO3 anbietet – und was Redakteure und Marketingverantwortliche davon haben.

Zum Beitrag
AI in TYPO3

TYPO3 und Schnittstellen – Wenn Drittsysteme plötzlich kommunizieren

CRM, ERP, Bewerbermanagement, Personen- und Satzungsdatenbank – die Liste der Systeme, die mit TYPO3 sprechen müssen, wird immer länger. Wie gelingt die Integration reibungslos? Ein Praxis-Leitfaden...

Zum Beitrag
Interface use in TYPO3

Redaktionelle Schulden im CMS – das versteckte Problem bei TYPO3-Relaunches

Technische Schulden kennt jeder Entwickler. Aber was passiert, wenn Redakteure gezwungen sind, das CMS auszutricksen? Wir beleuchten ein unterschätztes Problem, das bei Relaunches zur Kostenfalle...

Zum Beitrag
Chaos im CMS

TYPO3 Backend UX – Wenn Redakteure plötzlich produktiv werden

Warum dauert die Einarbeitung neuer Redakteure ins CMS Wochen? Und warum kommen ständig die gleichen Support-Anfragen? Bei einem TYPO3-Relaunch wird das Backend von uns komplett auf User Experience...

Zum Beitrag
UX im TYPO3 Backend

Kein Chaos mehr bei vollem Büro - so organisieren wir unsere Teamwochen

Mittlerweile arbeitet ein Großteil unseres Teams ortsunabhängig und wir sind stolz, dass diese Arbeitsweise bei in2code so gut klappt. Trotzdem ist es wichtig, die Kollegen und Mitarbeiter auch...

Zum Beitrag

Hinter den Kulissen: Ein Gespräch mit Peter, Teamlead des TYPO3 Localization Teams

Das TYPO3 Localization Team sorgt dafür, dass TYPO3 weltweit verständlich und zugänglich ist – aber nicht auf die Weise, wie viele denken. Wir haben mit Peter gesprochen, Teamlead des Localization...

Zum Beitrag