Ein Content-Management-System, das nach der Lancierung ignoriert wird, verfaellt in drei bis fuenf Jahren zu einem Sicherheitsrisiko mit wachsenden Reparaturkosten. Die technische Schuld summiert sich laufend, bis die Sanierung teurer wird als ein Neuanfang. Wer Pflege als laufende Investition plant, vermeidet den typischen Zyklus aus Panik-Updates, Notfall-Einsaetzen und letztlich kompletter Ersatzbeschaffung.
Was ein CMS im Betrieb wirklich leistet – und wo es versagt
Ein Content-Management-System ist keine fertige Software, die dauerhaft funktioniert. Es handelt sich um ein dynamisches System aus Kern-Software, Erweiterungen, Datenbank, Serverumgebung und Schnittstellen zu externen Diensten. Jede dieser Schichten aendert sich unabhaengig voneinander: Der Kern erhaelt Sicherheitspatches, der Hosting-Provider passt PHP-Versionen an, Browser verabschieden sich von alten Standards, APIs werden umgestellt.
Die Illusion der Fertigkeit entsteht, weil eine frisch installierte Website stabil laeuft. Doch der Betrieb ist vergleichbar mit einem Gewerbebetrieb: Die Maschinen laufen, aber sie brauchen Wartung, Ersatzteile und gelegentliche Anpassung an neue Rahmenbedingungen. Wer das ignoriert, betreibt irgendwann mit abgenutzten Werkzeugen – und merkt es erst, wenn etwas bricht.
Die drei Ebenen des Verfalls: Core, Erweiterungen, Inhalte
Der Verfall eines ungepflegten CMS laesst sich auf drei Ebenen beobachten, die sich gegenseitig beschleunigen.
Die Kern-Software verliert zunaechst den Anschluss an aktuelle Sicherheitsstandards. Bekannte Schwachstellen werden oeffentlich dokumentiert; wer nicht aktualisiert, faehrt mit bekannten Einfallstoren. Gleichzeitig steigt die Wahrscheinlichkeit, dass neuere Erweiterungen die alte Kernversion nicht mehr unterstuetzen.
Erweiterungen und Plugins sind der empfindlichste Punkt. Ein typisches WordPress-Projekt nutzt zwischen zehn und fuenfzig zusaetzliche Komponenten. Jede hat eigene Update-Zyklen, Abhaengigkeiten und Entwickler, die das Projekt einstellen koennen. Nach zwei Jahren ohne Pflege entsteht ein Puzzle aus veralteten, teilweise inkompatiblen Modulen, bei dem kein Entwickler mehr gerne anfasst.
Inhalte und Strukturen veralten ebenfalls, allerdings langsamer. Doch auch hier wirkt sich technischer Verfall aus: Wenn Editor-Oberflaechen nicht mehr funktionieren, koennen Redakteure keine Aenderungen mehr vornehmen. Die Website verharrt im Zustand der letzten funktionierenden Bearbeitung – oft mit veralteten Preisen, abgelaufenen Angeboten oder falscher Adresse.
Sicherheit: Warum veraltete Systeme zum Zeitfaktor werden
Sicherheitsluecken in verbreiteten CMS sind kein Geheimnis. Hersteller veroeffentlichen nach einem Patch detaillierte Beschreibungen der Schwachstelle – als Anleitung fuer Angreifer, die bei ungepatchten Systemen zuschlagen koennen. Das Risiko steigt also nicht kontinuierlich, sondern sprunghaft mit jeder veroeffentlichten, nicht eingespielten Korrektur.
Entscheidend ist die Kombination aus Bekanntheit und Angriffsflaeche. Ein veraltetes WordPress mit bekannten Luecken ist ein bequemeres Ziel als ein exotisches, ebenfalls veraltetes System – einfach weil automatisierte Angriffe auf Massen abzielen. Wer also ein gaengiges CMS ohne Pflege betreibt, gehoert zur groessten, am leichtesten zu identifizierenden Risikogruppe.
Das bedeutet nicht, dass jede ungepflegte Website automatisch gehackt wird. Es bedeutet, dass der Schadenseintritt bei erfolgreichem Angriff typischerweise massiv ist: Datenverlust, Website-Defacement, Einbettung von Schadcode, Versand von Spam aus dem eigenen Hosting-Vertrag, bis hin zur kompletten Uebernahme des Server-Zugangs. Die Folgekosten uebersteigen regelmaessig diejenigen einer durchgaengigen Pflege um ein Vielfaches.
Funktionalitaet: Wenn Updates ausbleiben, bricht nach und nach alles
Der sichtbare Verfall beginnt meist harmlos. Ein Kontaktformular sendet keine Mails mehr, weil der Hosting-Provider die Versandmethode geaendert hat. Die Bildergalerie zeigt keine Vorschaubilder, weil die verwendete Bibliothek mit der aktuellen PHP-Version nicht kompatibel ist. Der Shop-Import laeuft nicht mehr, weil die Schnittstelle des Lieferanten auf aktuelles TLS umgestellt hat.
Solche Stoerungen treten zunaechst sporadisch auf und werden mit Workarounds umgangen. Doch je mehr Provisorien sich stapeln, desto fragiler wird das System. Irgendwann erreicht man den Punkt, an dem ein scheinbar kleines Update kaskadenartig Folgefehler ausloest – weil Erweiterung A die neue Version von Erweiterung B nicht vertraegt, die wiederum die alte Kernversion bricht.
Die praktische Folge: Jede Aenderung, die frueher Stunden dauerte, wird zum mehrtaegigen Puzzle. Entwickler muessen zuerst den Ist-Zustand rekonstruieren, dann in einer veralteten Codebasis arbeiten. Die Kosten pro Stunde bleiben gleich, der Aufwand pro Aufgabe steigt exponentiell.
Die versteckten Kosten der spaeten Sanierung
Die wirtschaftliche Rechnung verschiebt sich dramatisch, wenn Pflege aufgeschoben wird. Ein typisches Muster laesst sich in drei Phasen beschreiben.
Jahre eins bis zwei: Keine Pflegekosten, aber erste Anzeichen von Verfall. Einzelne Funktionen stoeren, werden aber toleriert. Die Opportunitaetskosten bleiben unsichtbar.
Jahre drei bis vier: Erste Notfalleinsaetze. Ein Plugin verursacht einen kritischen Fehler, ein Sicherheitsupdate wird vom Hosting-Provider eingefordert. Die Rechnungen fuer diese Einsaetze uebersteigen bei Weitem die Kosten einer regelmaessigen Wartung, weil jeder Eingriff unter erhoehtem Zeitdruck und in verwilderter Umgebung erfolgt.
Ab Jahr fuenf: Die Sanierung wird zur Kernsanierung. Alle Erweiterungen muessen auf Kompatibilitaet geprueft, die Datenbank bereinigt, der Kern aktualisiert werden – bei laufendem Betrieb, ohne dass etwas kaputt geht. Der Aufwand naehert sich schnell der Neuentwicklung. Gleichzeitig hat das Unternehmen inzwischen Opportunitaetskosten getragen: verpasste Funktionen, gestoerte Prozesse, Zeitverlust durch Workarounds.
Wer die Kosten ueber fuenf Jahre summiert, stellt fest: Die vermeintliche Einsparung bei der Pflege wurde durch Notfall-Einsaetze und Produktivitaetsverluste mehr als aufgefressen. Der Unterschied liegt nicht im Betrag, sondern in der Verteilung – von planbaren, gleichmaessigen Ausgaben zu unvorhersehbaren Grossbeträgen.
Der Wendepunkt: Reparieren oder neu aufbauen?
Die Entscheidung zwischen Sanierung und Neuentwicklung laesst sich an konkreten Kriterien festmachen. Eine Neuentwicklung wird wirtschaftlich sinnvoll, wenn mehrere der folgenden Punkte zutreffen:
- Die Kernversion liegt mehr als drei Hauptversionen zurueck und hat keinen direkten Aktualisierungspfad.
- Mehr als ein Drittel der verwendeten Erweiterungen werden nicht mehr weiterentwickelt oder sind inkompatibel zu aktuellen Versionen.
- Die Datenbank enthaelt erheblichen Datenmuell durch jahrelange Plugin-Reste und Revisionsspeicher.
- Das Theme oder individuelle Templates basieren auf veralteten Techniken, die nicht mehr unterstuetzt werden.
- Die Wartungskosten fuer ein Jahr uebersteigen 40 bis 50 Prozent der geschaetzten Neuentwicklung.
Der entscheidende Faktor ist die kalkulatorische Restnutzungsdauer. Eine Sanierung, die 18 Monate funktionieren soll, bis doch alles neu gemacht werden muss, ist Geldverschwendung. Eine Neuentwicklung mit sauberer Basis und dokumentierter Pflegestrategie amortisiert sich typischerweise innerhalb von zwei bis drei Jahren gegenueber dem Weiterbetrieb einer veralteten Konstruktion.
Mindestpflege fuer WordPress: Was tatsaechlich noetig ist
Fuer das am weitesten verbreitete selbst gehostete WordPress laesst sich eine Mindestpflege definieren, die den Verfall signifikant verzoegert:
Woechentlich: Pruefung auf verfuegbare Updates fuer Kern, Themes und Plugins; Einspielung nach visueller Pruerfung in einer Testumgebung oder nach Backup. Ueberwachung der Kommentar- und Benutzerverwaltung auf Spam oder unautorisierte Zugänge.
Monatlich: Backup-Test – nicht nur Erstellung, sondern Rueckspielung auf ein separates System, um die Funktionsfaehigkeit zu verifizieren. Pruefung der Server-Logs auf auffaellige Zugriffsmuster. Bereinigung von Revisionen und transienten Datenbank-Eintraegen.
Vierteljaehrlich: Ueberpruefung aller Plugins auf Aktualitaet der Entwicklung; Deinstallation nicht mehr benoetigter Erweiterungen. Pruefung der PHP-Version gegen die Empfehlungen des Hosting-Providers. Test aller Formulare und Schnittstellen auf Funktionsfaehigkeit.
Jaehrlich: Strategische Ueberpruefung der gesamten Erweiterungslandschaft. Ersetzung von Plugins durch besser gewartete Alternativen, wo sinnvoll. Aktualisierung der Zugangsdaten und Pruefung der Benutzerrechte.
Wer diese Mindestpflege nicht leisten kann oder will, sollte die Hosting-Form ueberdenken – nicht als Nachlassigkeit, sondern als unternehmerische Ressourcenentscheidung.
Selbst gehostet, managed oder SaaS: Wo Pflege anfaellt und wo nicht
Die Intensitaet der erforderlichen Pflege haengt stark vom Hosting-Modell ab.
Selbst gehostet (zum Beispiel WordPress auf Standard-Hosting): Der Betreiber traegt die volle Verantwortung. Alle oben genannten Pflegeaufgaben fallen an. Die Freiheit bei der Gestaltung ist maximal, die Pflegepflicht ebenso. Dieses Modell eignet sich nur fuer Unternehmen mit interner technischer Kompetenz oder einem festen Wartungsvertrag mit einer Agentur.
Managed Hosting fuer spezifische CMS: Der Provider uebernimmt Teile der Pflege – typischerweise Server-Updates, Backups, Basis-Sicherheit und oft auch Kern-Updates des CMS. Die Verantwortung fuer Erweiterungen, Themes und Inhalte bleibt beim Betreiber. Die Pflegeintensitaet sinkt um etwa die Haelfte, die Kosten steigen entsprechend. Ein sinnvoller Kompromiss fuer die meisten mittleren Unternehmen.
SaaS-CMS (zum Beispiel Wix, Squarespace, Shopify): Die technische Pflege obliegt komplett dem Anbieter. Updates, Sicherheit, Skalierung werden transparent erledigt. Die Pflege beschraenkt sich auf Inhalte und Konfiguration. Der Preis ist die eingeschraenkte Flexibilitaet bei Design, Funktion und Datenportabilitaet. Fuer Standardanforderungen oft die wirtschaftlichste Lo sung, weil die versteckten Kosten des technischen Betriebs eliminiert werden.
Die Entscheidung zwischen diesen Modellen sollte nicht von der technischen Praeferenz, sondern von der verfuegbaren internen Kapazitaet geleitet werden. Ein selbst gehostetes WordPress ohne Wartungsbudget ist ein schlechteres Geschaeft als ein SaaS-System mit begrenzterem Funktionsumfang.
Pflege als unternehmerische Entscheidung, nicht als IT-Thema
Das zentrale Missverstaendnis liegt in der Einordnung. Pflege wird haefig als technische Detailfrage delegiert oder aufgeschoben. Tatsaechlich handelt es sich um eine Investitionsentscheidung mit klaren Renditeparametern.
Die richtige Fragestellung lautet nicht: "Was kostet mich die monatliche Wartung?" Sondern: "Was kostet mich der Verzicht in drei Jahren, wenn ich Notfall-Einsaetze bezahle, Funktionalitaet verliere und eventuell neu entwickeln muss?" Die Antwort faellt in den meisten Faellen klar zugunsten kontinuierlicher Pflege aus.
Wer diese Rechnung nicht selbst erstellen kann, sollte sie von einer neutralen Seite pruefen lassen. Die Beurteilung eines bestehenden Systems gegenueber einer Neuentwicklung, die Kalkulation der wahren Betriebskosten, die Auswahl des passenden Pflege-Modells – das sind Entscheidungen, die den Unternehmer ueber Jahre begleiten.
Fuer eine unverbindliche Einschaetzung des eigenen Systems, der Pflegeanforderungen und der wirtschaftlichen Alternativen steht die Beratung zur Verfuegung. Die Ausgangslage laesst sich in einem kurzen Gespraech strukturieren – ohne Vorabkosten und ohne Verpflichtung.
