Einen seriösen monatlichen Festpreis kann man erst nennen, wenn klar ist, wer welche Verantwortung übernimmt. Die Kosten hängen vom Zustand des Systems, der eingesetzten Technik, der Infrastruktur, den wichtigen Prozessen und Integrationen, dem benötigten Monitoring, den Backup- und Deployment-Abläufen, der Zahl der Anfragen und den vereinbarten Reaktionszeiten ab.
Für eine sinnvolle Kalkulation sollten vier Bereiche getrennt werden: Infrastruktur und externe Dienste, feste Bereitschaft, tatsächlich ausgeführte Arbeiten und größere Weiterentwicklungen. Erst danach lassen sich zwei Angebote wirklich vergleichen.
Hosting ist nur ein Teil der Kosten
Server, Domain und Zertifikat ermöglichen den Betrieb, übernehmen aber nicht die Wartung. Ein Hosting-Paket erkennt nicht automatisch, dass ein Rechnungsversand ausgefallen ist, eine Integration keine Bestellungen mehr abruft oder ein Datenbank-Backup nicht wiederhergestellt werden kann. Es aktualisiert auch keinen Anwendungscode und behebt keine Störung nach einer Änderung einer externen API, wenn das nicht ausdrücklich vereinbart wurde.
Auch bei Backups reicht die Information, dass eine Datei erstellt wurde, nicht aus. Es muss feststehen, welche Daten enthalten sind, wie oft die Sicherung erfolgt, wie lange sie aufbewahrt wird, wo sie liegt und wie eine Wiederherstellung getestet wird.
Aus welchen Bestandteilen entstehen die Wartungskosten?
| Kostenbereich | Möglicher Inhalt | Wofür das Unternehmen tatsächlich bezahlt |
|---|---|---|
| Infrastruktur und externe Dienste | Server oder Cloud, Domain, E-Mail, SMS, Zahlungen, Dateispeicher, Monitoring und externe APIs | Ressourcen und Zugang zu Diensten, die die Anwendung benötigt |
| Laufende Betreuung und Bereitschaft | Bearbeitung von Alarmen und Anfragen, Kontrolle der Backups, Planung von Updates und Verantwortung innerhalb vereinbarter Zeiten | Verfügbarkeit einer Person, die den vereinbarten Umfang kennt und die Bearbeitung beginnen kann |
| Arbeiten im System | Diagnose, Fehlerbehebung, Updates, Deployments, Konfiguration und kleinere Änderungen | konkrete Arbeiten im Rahmen einer Pauschale, eines Limits oder eines Einzelauftrags |
| Größere Weiterentwicklung | neue Module, Migrationen, Modernisierung, Umbau der Infrastruktur oder Wiederherstellung nach einem schweren Vorfall | ein eigenes Projekt, das nicht hinter dem allgemeinen Begriff "Wartung" versteckt werden sollte |
Ein Angebot kann nur Serverbetrieb und Reaktion auf Meldungen enthalten. Ein anderes umfasst zusätzlich die Überwachung wichtiger Abläufe, Backup-Kontrollen, regelmäßige Updates und ein festgelegtes Arbeitskontingent. Ein Vergleich nur nach Monatspreis führt deshalb leicht zu falschen Schlüssen.
Was beeinflusst die Kalkulation besonders stark?
Bedeutung des Systems für das Unternehmen
Eine Informationsseite hat andere Anforderungen als ein System, das Bestellungen, Buchungen oder täglich benötigte Mitarbeiterdaten verarbeitet. Je größer die Folgen eines Stillstands, desto wichtiger werden Monitoring, ein klarer Meldeweg und ein vorher vereinbartes Vorgehen.
Zustand von Code und Technik
Der Aufwand steigt, wenn nicht mehr unterstützte Versionen von PHP, Framework oder Bibliotheken eingesetzt werden, Tests fehlen oder Deployments nur manuell und ohne sicheren Rückweg möglich sind. PHP veröffentlicht Supportzeiträume für seine Versionszweige, Laravel hat eine eigene Richtlinie für Fehler- und Sicherheitskorrekturen. Die eingesetzten Versionen müssen daher während der gesamten Laufzeit kontrolliert werden.
Prozesse und Integrationen
Ein Aufruf der Startseite erkennt nicht jeden Fehler. Warteschlangen, geplante Aufgaben, Zahlungen, Nachrichtenversand, Importe, Exporte und Verbindungen zu anderen Systemen können jeweils eine eigene Überwachung benötigen. Jeder zusätzliche Ablauf bringt eigene Fehlersituationen und Abhängigkeiten von externen Anbietern mit.
Dokumentation und Zugänge
Repository, Infrastrukturbeschreibung, Diensteliste, Deployment-Ablauf und Informationen zu Backups beschleunigen die Analyse. Fehlen diese Unterlagen nach einem Anbieterwechsel, kann der erste Schritt darin bestehen, Zugänge zu ordnen und den Systemzustand zu prüfen. Die Checkliste zur Anwendungsübergabe hilft bei der Vorbereitung, ersetzt aber keine Prüfung von Code und Server.
Gewünschte Servicezeiten und Reaktionszeit
Bereitschaft kostet auch in einem Monat ohne Störung. Eine kurze erste Reaktionszeit setzt reservierte Kapazität und Kenntnisse des konkreten Systems voraus. Außerdem muss zwischen dem Beginn der Bearbeitung und der vollständigen Behebung unterschieden werden. Ein Lösungstermin lässt sich häufig erst nach der Diagnose nennen.
Wann reicht ein Einzelauftrag?
Nicht jede Anwendung benötigt eine monatliche Betreuung. Ein Einzelauftrag kann genügen, wenn das System keinen kritischen Prozess trägt, ein geplanter Termin akzeptabel ist und ein bestimmtes Update, eine Konfiguration oder eine Reparatur gebraucht wird. Monitoring, Backups und die Kommunikation mit dem Hoster müssen dann einer anderen verantwortlichen Stelle zugeordnet sein.
Eine laufende Betreuung ist sinnvoller, wenn die Anwendung täglich genutzt wird, regelmäßig verändert wird, Integrationen besitzt oder Hintergrundaufgaben ausführt. Sie ist auch hilfreich, wenn eine Partei die Verantwortung für Alarme, Backup-Prüfungen, Update-Planung und kontrollierte Deployments übernehmen soll.
Bei Domin Software können wir Einzelarbeiten, regelmäßige Betreuung oder eine separat kalkulierte Variante mit Reaktionszeit vereinbaren. Das passende Modell hängt vom System und den Folgen eines Ausfalls ab.
Warum beeinflusst ein SLA die Kosten?
Ein SLA darf keine vage Zusage schneller Hilfe sein. Es sollte Anwendungen und Umgebungen, Servicezeiten, Meldewege, Prioritäten, die erste Reaktionszeit und die Pflichten beider Seiten genau benennen.
Domin Software veröffentlicht kein einheitliches SLA für alle Kunden und verspricht keinen 24/7-Support. Unser reguläres Servicefenster ist Sonntag bis Freitag von 08:00 bis 17:00 Uhr in der Zeitzone Europe/Warsaw. Samstags bieten wir keinen Support. An polnischen gesetzlichen Feiertagen können wir nur auf vorher vereinbarte kritische Ereignisse reagieren. Verbindlich werden die Bedingungen erst, wenn sie im Angebot oder Vertrag festgehalten sind.
Ein rund um die Uhr aktives Monitoring bedeutet nicht automatisch eine menschliche Reaktion rund um die Uhr. Es kann eine Störung erkennen und protokollieren, die Bearbeitung richtet sich aber nach dem vereinbarten Servicefenster.
Wie lassen sich zwei Wartungsangebote vergleichen?
| Frage | Was klar beschrieben sein sollte |
|---|---|
| Was ist abgedeckt? | Anwendungen, Umgebungen, Server, Integrationen und wichtige Prozesse |
| Was wird überwacht? | konkrete Endpunkte, Aufgaben, Warteschlangen, Integrationen und Empfänger von Alarmen |
| Wie werden Backups geprüft? | Umfang, Häufigkeit, Aufbewahrung, Speicherort und Wiederherstellungstests |
| Wann werden Meldungen bearbeitet? | Tage, Stunden, Zeitzone, Kanäle und Eskalationsregeln |
| Was bedeutet Reaktionszeit? | Bestätigung, erste Einschätzung und Beginn der Bearbeitung, nicht automatisch die fertige Reparatur |
| Wie werden Änderungen durchgeführt? | Tests, Freigabe, Deployment und Rückkehr zur vorherigen Version |
| Was ist in der festen Gebühr enthalten? | Bereitschaft, benannte Pflichten und ein mögliches Arbeitskontingent |
| Was wird separat berechnet? | größere Weiterentwicklung, Migrationen, Audits, Wiederherstellung nach Angriffen und Arbeiten außerhalb des Umfangs |
| Wem gehören die Konten? | der Kunde sollte Kontrolle über Hosting, Domain, Daten und Abrechnung behalten |
Fehlen diese Angaben, sollte der Umfang vor dem Preisvergleich ergänzt werden. Der niedrigste Preis kann einfach die geringste Verantwortung bedeuten. Ein höherer Preis beweist umgekehrt nicht automatisch einen besseren Schutz. Entscheidend sind der schriftlich vereinbarte Umfang und die Möglichkeit, die Leistung zu überprüfen.
Welche Angaben werden für ein Angebot benötigt?
Am Anfang genügt eine Beschreibung des Einsatzzwecks und der wichtigsten Abläufe. Hilfreich sind außerdem:
- Technik und Versionen, soweit bekannt;
- Umgebungen, Integrationen, Hintergrundaufgaben und externe Dienste;
- Angaben zu Repository, Dokumentation, Tests und Deployment;
- aktueller Umfang von Monitoring und Backups;
- Folgen eines Ausfalls und akzeptable Servicezeiten;
- typische Anfragen und erwartete kleinere Änderungen;
- Eigentümer der Konten und Freigabeprozess für Deployments.
Über das Kontaktformular sollten keine Passwörter, Schlüssel, Datenbanken oder Kundendaten gesendet werden. Für den ersten Schritt benötigen wir eine Beschreibung, keinen Produktionszugang.
Der Planer für die Anwendungswartung sammelt diese Angaben und erstellt eine Arbeitszusammenfassung. Das Ergebnis ist weder ein automatisches Angebot noch ein SLA-Vertrag.
Was zeigen unsere bisherigen Projekte?
Die Entwicklung des 44Islands-Systems endete nicht mit dem ersten Deployment. In weiteren Etappen wurden Buchungsverwaltung, Benutzerrollen und Direktverkauf erweitert. Das zeigt, dass die Betreuung einer laufenden Anwendung sowohl den bestehenden Umfang als auch separat vereinbarte Weiterentwicklung umfassen kann.
Die historische Betreuung von drei PrestaShop-1.6-Shops umfasste unter anderem VPS- und Umgebungskonfiguration, Domains, Apache und PHP, Modulinstallation sowie Leistungs- und Template-Verbesserungen. Sie dauerte ungefähr ein Jahr. Die Shops sind heute nicht mehr produktiv. Das Beispiel belegt daher die Art der ausgeführten Arbeiten, nicht den aktuellen Zustand oder den Preis einer neuen Dienstleistung.
In beiden Fällen richtete sich der Umfang nach dem konkreten System. Frühere Projekte sind keine fertige Preisliste für den nächsten Kunden.
Häufige Fragen
Ist die Wartung einer Anwendung im Hosting enthalten?
Nein, sofern das Angebot nicht beide Leistungen ausdrücklich verbindet und die Verantwortung beschreibt. Hosting stellt Ressourcen bereit. Wartung kann dagegen Prozessüberwachung, Backups, Updates, Diagnose, Deployment und die Bearbeitung von Meldungen umfassen.
Enthält eine laufende Betreuung immer eine feste Zahl an Entwicklerstunden?
Nicht zwingend. Eine Gebühr kann Bereitschaft und benannte Pflichten abdecken und zusätzlich ein Arbeitskontingent enthalten. Die Vereinbarung sollte erklären, was nach Verbrauch des Kontingents geschieht und welche Aufgaben als eigenes Projekt gelten.
Reicht die Erstellung eines Backups zur Absicherung aus?
Nein. Es muss bekannt sein, welche Daten enthalten sind, wo und wie lange sie gespeichert werden und ob daraus ein funktionsfähiges System wiederhergestellt werden kann. Für Wiederherstellungstests sollten Umfang und Häufigkeit vereinbart werden.
Kann der Preis ohne Zugriff auf den Code bestimmt werden?
Ein erstes Zusammenarbeitsmodell und die erforderlichen Informationen lassen sich ohne Zugriff festlegen. Die genaue Übernahme von Verantwortung für ein bestehendes System kann jedoch eine bezahlte Analyse von Code, Infrastruktur, Versionen und Deployment erfordern.
Bedeutet Monitoring eine Reaktion rund um die Uhr?
Nein. Monitoring kann ständig laufen, die Bearbeitung erfolgt aber zu den vereinbarten Zeiten. Ein Bereitschaftsdienst außerhalb der regulären Zeiten muss separat vereinbart werden.
Gehört die Entwicklung neuer Funktionen zur Wartung?
Kleinere Änderungen können in ein vereinbartes Kontingent passen. Größere Module, Migrationen und Modernisierung benötigen einen eigenen Umfang, Abnahmekriterien und eine eigene Kalkulation.
Der nächste Schritt
Wenn der Bedarf zuerst geordnet werden soll, nutzen Sie den Planer für die Anwendungswartung. Er sammelt Angaben zu System, Backups, Monitoring, Meldungen und gewünschtem Zusammenarbeitsmodell, versendet aber keine Daten automatisch und erstellt kein Angebot.
Wenn der Umfang bereits klar ist, sehen Sie sich unsere Betreuung von Anwendungen und Onlineshops an. Beschreiben Sie den Einsatzzweck, die wichtigsten Prozesse, die Folgen eines Ausfalls und die gewünschten Servicezeiten. Auf dieser Grundlage klären wir, ob ein Einzelauftrag, eine regelmäßige Betreuung oder eine separat vereinbarte SLA-Variante passt.
Quellen
- PHP Supported Versions, abgerufen am 28.10.2026.
- Laravel Release Notes and Support Policy, abgerufen am 28.10.2026.
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning, abgerufen am 28.10.2026.
- OWASP A06:2021, Vulnerable and Outdated Components, abgerufen am 28.10.2026.