Basis
Updates & Security
- • TYPO3 Core Updates & Security Patches
- • Extension Updates (kompatibel geprüft)
- • Composer Dependencies / PHP-Kompatibilität
- • Basic Security Hardening
Wartung · SLA · Reaktionszeiten · Updates · Monitoring · Kosten
TYPO3 Wartungsvertrag:
SLA & Kosten realistisch planen
Ein Wartungsvertrag ist kein „Nice-to-have“ – er ist eine Risikoversicherung für Betrieb & Weiterentwicklung. Gute SLAs sorgen für planbare Updates, klare Reaktionszeiten und einen stabilen Systemzustand – statt Notfällen und hektischem Firefighting.
Für Unternehmen, Verbände & öffentliche Träger
Fokus: Security & Stabilität
Ohne Überraschungen im Budget
Praxis-Tipp: Wartung ist günstiger als Notfall – weil man die Fehler vor dem Crash findet.
Warum TYPO3 Wartung nicht optional ist
TYPO3 lebt von Updates: Security-Fixes, Bugfixes, PHP-Kompatibilität, Extension-Updates, Konfigurationsanpassungen. Ohne Wartung entstehen „unsichtbare Schulden“ – bis der Betrieb kippt.
- Security-Risiken: ungepatchte Lücken und veraltete Abhängigkeiten
- Upgrade-Stau: große Versionssprünge werden teuer und riskant
- Instabilität: kleine Fehler werden zu großen Ausfällen
- Unklares Ownership: niemand fühlt sich verantwortlich, bis es brennt
Ziel eines guten Vertrags ist: Regelbetrieb planbar halten und die „Schadenswahrscheinlichkeit“ dauerhaft reduzieren – technisch und organisatorisch.
Was ist in einem TYPO3 Wartungsvertrag enthalten?
Der größte Hebel ist eine klare Aufteilung: Stabilität (Wartung) vs. Feature-Arbeit (Weiterentwicklung). Gute Verträge beschreiben beides sauber – damit Budgets nicht verschwimmen.
Betrieb
Monitoring & Stabilität
- • Health Checks (HTTP, Jobs, Queue)
- • Error-Logs & Alerts (P1/P2)
- • Performance Checks (Caching, INP/LCP)
- • Regelmäßige Hygiene-Fixes
Service
SLA & Support
- • Reaktionszeiten (Mo–Fr oder 24/7)
- • Eskalationsweg & Kommunikationskanal
- • Bugfixing (kontingentiert)
- • Monatliche Reports & Prioritäten
Was in Wartung oft (nicht) enthalten ist
Feature-Entwicklung, große Relaunches, komplexe Integrationen oder Upgrade-Projekte gehören in separate Umsetzungsbudgets (oder in einen größeren Retainer). Ein guter Vertrag trennt das bewusst – sonst „frisst“ Wartung die Roadmap.
SLA-Modelle: von „Basis“ bis „kritisch“
SLA heißt nicht automatisch „24/7“. In vielen Fällen reicht ein klares Modell für Arbeitszeiten und eine definierte Regelung für echte P1-Fälle. Wichtig ist: Definitionen statt Bauchgefühl.
Basis SLA
Für kleinere Sites & mittlere Kritikalität.
- • Mo–Fr, definierte Reaktionszeit
- • Regelmäßige Updates
- • Bugfix-Kontingent
- • Monatlicher Kurzreport
Typisch: solide Wartung ohne Overkill.
Meist gebucht
Business SLA
Für Portale, Intranets & Systeme mit mehreren Stakeholdern.
- • Kürzere Reaktionszeiten (P1/P2)
- • Monitoring + Alerts
- • Regelmäßige Health-Checks
- • Priorisierte Abarbeitung im Retainer
- • Planbare „Wartungsfenster“
Ziel: Stabilität + Planbarkeit + schnelle Hilfe bei echten Problemen.
Critical SLA
Für transaktionskritische Systeme & hohe Ausfallkosten.
- • 24/7- oder erweiterte Bereitschaft
- • Striktes P1 Incident-Handling
- • Incident-Retrospektive (RCA)
- • Strong Monitoring + Runbooks
- • Restore-/Failover-Strategie
Nur sinnvoll, wenn Systemausfall sofort „Geld kostet“.
Wichtig: P1/P2 sauber definieren
Ein SLA scheitert selten an Technik, sondern an fehlenden Definitionen. Beispiel: „P1“ = kompletter Ausfall oder Security Incident. „P2“ = zentrale Funktion gestört, Workaround möglich. Alles andere ist planbares Ticketing – nicht Pager-Duty.
Kosten: Woraus sich ein Wartungsbudget wirklich zusammensetzt
Die Frage „Was kostet Wartung pro Monat?“ ist berechtigt – aber die richtige Gegenfrage lautet: Was kostet Nicht-Wartung? Die Kosten hängen vor allem von Komplexität und Reaktionszeiten ab.
Kostenblöcke im SLA
- Regelmäßige Updates (Core + Extensions)
- Test- und Staging-Aufwand (je sauberer, desto günstiger langfristig)
- Monitoring/Alerting & Log-Auswertung
- Bugfix-Kontingent & kleine Optimierungen
- Kommunikation/Reportings/Koordination
Was Kosten stark treibt
- Fehlende CI/CD & keine reproduzierbaren Deployments
- Viele Custom-Extensions ohne Tests
- Multi-Domain, Multi-Language, Enterprise-Integrationen
- Unklare Verantwortlichkeiten / viele Stakeholder
- Sehr kurze Reaktionszeiten / 24/7 Bereitschaft
Faustregel für Budgetplanung (ohne konkrete Zahlenspiele)
Je mehr euer System „Portal-Charakter“ hat (Suche, Integrationen, Rollenmodelle, Multi-Sites), desto eher lohnt ein Business SLA mit Monitoring und einem festen Kontingent. Das wirkt oft günstiger als sporadische „Notfall-Rechnungen“.
Wenn du willst, kann man das in 30 Minuten sauber einordnen: Systemtyp, Risiken, gewünschte Reaktionszeiten → passendes Modell.
Die häufigsten Fehler bei Wartungsverträgen
Viele Verträge scheitern nicht am Preis, sondern an unklaren Erwartungen. Diese Punkte solltest du vorher klären:
„Alles ist P1“
Wenn jede Kleinigkeit „Notfall“ ist, bricht jedes SLA. Definiere P1/P2/P3 sauber.
Keine Testumgebung
Updates ohne Staging sind Glücksspiel. Staging spart in Summe fast immer Geld und Risiko.
Wartung & Roadmap vermischt
Wartung ist Stabilität. Feature-Arbeit braucht eigene Prioritäten, Sprints und Budgets.
„Updates“ ohne Zielbild
Ohne Lifecycle-Plan sammeln sich Versionen an. Lieber kontinuierlich – statt Großupgrade.
Kein Monitoring
Ohne Signale kommt der Alarm erst, wenn Nutzer:innen es merken. Monitoring verkürzt Incidents massiv.
Fehlende Übergabe
Ownership unklar? Dann dauern Tickets länger. Ein kleines Runbook hilft enorm.
Wartung als „Sicherheitsgurt“ für Ihr TYPO3 System?
Wenn Sie Wartung planbar aufsetzen wollen (inkl. Reaktionszeiten, Monitoring und klaren Verantwortlichkeiten), dann schauen wir uns kurz Ihr Setup an und wählen ein SLA-Modell, das zu Ihrer Organisation passt.
Unverbindlich · vertraulich · Remote DACH · NDA/AVV möglich