Software-Wartung

Software-Wartung für das System, das du schon betreibst.

Produktivsoftware bleibt nicht von allein gesund. Abhängigkeiten altern, Sicherheitspatches kommen, Fehler tauchen auf und kleine Wünsche stapeln sich. Wir vereinbaren, was wir warten, wie Anfragen bei uns ankommen und wie schnell wir reagieren. Dann erledigen wir die Arbeit und du kannst jede Änderung nachprüfen.

Wartungsvertrag abgrenzen →

KURZ ERKLÄRT

Software-Wartung ist die laufende Pflege von Produktivsoftware: Updates, Abhängigkeits- und Sicherheitspatches, Fehlerbehebung, kleine Erweiterungen und gepflegtes Monitoring. Umfang, Arbeitszeiten und Reaktionszeiten werden vertraglich vereinbart; 24/7-Abdeckung oder ein Uptime-SLA gehören nicht dazu.

Passt für

Ein Produktivsystem, das sich bauen und ausliefern lässt und eine verlässliche Wartung braucht
Teams, deren Entwickler an Neuem arbeiten und die Routinepflege abgeben wollen

Eine andere Leistung passt besser

Ein Anbieterwechsel, bei dem zuerst Zugänge und Wissen übernommen werden müssen
24/7-Rufbereitschaft oder eine vertragliche Verfügbarkeitsgarantie

Mit einem System starten, das sich warten lässt

Wartung setzt voraus, dass wir das System bauen, testen und ausliefern können. Sind Zugänge, Dokumentation oder der bisherige Anbieter das Problem, kommt zuerst die Software-Übernahme. Deren Angebote für Übergabe, Wiederherstellung und das Dependency-Upgrade behalten ihren eigenen Umfang und ihre Bedingungen. Zeigt der Onboarding-Check, dass sich das System nicht sicher ausliefern lässt, sagen wir das, bevor wir einen Wartungsumfang vereinbaren. Strukturelle Änderungen wie ein Framework-Wechsel oder die Aufteilung eines Monolithen sind Legacy-Modernisierung.

Was die laufende Pflege umfasst

Der Vertrag listet die betreuten Systeme und Umgebungen. Arbeit außerhalb dieser Liste wird vor Beginn angeboten.

Updates und Sicherheitspatches

Laufzeiten, Frameworks und Bibliotheken auf unterstützten Versionen halten. Sicherheitshinweise bewerten und in vereinbarter Priorität einspielen.

Fehlerbehebung

Fehler aus deinem Team oder aus Logs und Error-Tracking reproduzieren, beheben, testen und ausliefern.

Kleine Erweiterungen

Kleinere Änderungen innerhalb eines vereinbarten Monatsbudgets. Alles Größere wird vor Beginn separat angeboten.

Gepflegtes Monitoring

Error-Tracking, Logs, Zertifikate und Alerts nützlich halten. Alerts gehen innerhalb der vereinbarten Zeiten an eine benannte Person.

Reaktionszeiten werden vereinbart, nicht unterstellt

Der Vertrag nennt die betreuten Systeme, den Anfrageweg, die Arbeitszeiten, die Einstufung nach Dringlichkeit und die Reaktionsziele je Stufe. Diese Ziele gelten innerhalb der vereinbarten Arbeitszeiten. Wir bieten keine 24/7-Rufbereitschaft und kein Uptime-SLA, und ein Wartungsvertrag schafft auch keines. Die Härtung der laufenden Umgebung ist Cloud Security, Kontrollen im Build- und Release-Weg sind DevSecOps. Im Trust Center stehen unsere allgemeinen Support-Grenzen.

Illustratives Protokoll: ein Monat Wartung

Ein illustrativer Monatsbericht listet eingespielte und zurückgestellte Abhängigkeits-Updates (mit Begründung), geprüfte Sicherheitshinweise, behobene Fehler mit dem jeweiligen Release, kleine Änderungen gegen das vereinbarte Budget, offene Punkte und die Entscheidungen, die bei dir liegen. Das ist ein Beispielformat, kein Kundenresultat und keine Service-Level-Zusage.

Einarbeiten, warten, überprüfen

Der Onboarding-Check wird eigenständig abgegrenzt und angeboten. Der Wartungsvertrag folgt aus seinem Befund.

Onboarding-Check
Wir bauen, testen und liefern das System einmal in einer vereinbarten Umgebung aus. Du erhältst ein Versionsinventar, bekannte Risiken und einen Vorschlag für den Wartungsumfang.
Laufende Wartung
Ein Monatsvertrag für die vereinbarten Systeme, Arbeitszeiten, den Anfrageweg und die vertraglich vereinbarten Reaktionsziele.
Regelmäßige Überprüfung
Was erledigt wurde, was gealtert ist und was immer wieder bricht. Ein wiederkehrendes strukturelles Problem wird zu einer eigenen Entscheidung über Modernisierung oder Sicherheit.

Zugänge, Versionsliste und die Leute mitbringen, die Probleme melden

Wir brauchen Zugang zu Repository, CI und Hosting, die aktuelle Versionsliste, bekannte Probleme, das Error-Tracking, die Personen, die Probleme melden, und jemanden, der Releases freigeben darf. Größere Features gehören zur Softwareentwicklung. Für die Budgetplanung erklärt der Leitfaden zu Wartungskosten typische Kostentreiber. Sein Modell ist weder Angebot noch Supportzusage.

// beweise

Laufende Pflege in bestehender Engineering-Arbeit

IKB: Wavect arbeitete innerhalb des Smart-City-Aufbaus von IKB an Infrastruktur und Geräten, übergab die Plattform vollständig an das interne IKB-Team und blieb als externe Unterstützung für neue Geräteintegrationen, den Grafana-Stack, Feldkonnektivität und Herstellerkontakte. MyMerch dokumentiert eine mehrjährige Zusammenarbeit, in der ein funktionierendes Shopify-Geschäft gezielt verbessert wurde, ohne Neubau. Polity dokumentiert langfristige QA-Verantwortung mit weniger instabilen Tests und Fehler-Triage über mehrere Services. Keiner dieser Fälle dokumentiert 24/7-Abdeckung oder eine Verfügbarkeitszusage.

Komplett Plattformübergabe

Smart-City-IoT für Innsbruck: LoRaWAN-Infrastruktur erweitert und skaliert, Multi-Vendor-Geräte evaluiert und integriert, die …

Kubernetes LoRaWAN Docker

~50% Effizienzgewinn für das MyMerch-Team

Das MyMerch-Team beziffert den Effizienzgewinn auf ~50%. Weniger Auslieferungsfehler, höhere Shopify-Conversion, ohne Rewrite.

Shopify Shopify Liquid JavaScript

7 Services Vereinheitlichtes Testen

1,5 Jahre QA-Eigentümerschaft über sieben Services und mehrere Vendoren. Qualität blieb durch jeden Refactor lieferbar.

React Java/Kotlin Go

Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 100+ Produkte ausgeliefert.

Fragen vor dem Start

Bietet ihr 24/7-Support oder ein Uptime-SLA?

Nein. Wir bieten keine 24/7-Rufbereitschaft und kein Uptime-SLA. Arbeitszeiten, Dringlichkeitsstufen und Reaktionsziele werden im Vertrag vereinbart und gelten innerhalb dieser Zeiten.

Welche Reaktionszeiten sagt ihr zu?

Die, die im Vertrag stehen. Die Zeiten hängen von der Dringlichkeitsstufe und den vereinbarten Arbeitszeiten ab. Wir legen sie nach dem Onboarding-Check fest, wenn wir das System kennen.

Könnt ihr Software warten, die jemand anderes gebaut hat?

Ja, wenn sie sich bauen und ausliefern lässt. Das zeigt der Onboarding-Check. Geht der bisherige Anbieter und müssen erst Zugänge oder Wissen übernommen werden, ist das eine Software-Übernahme.

Wo hört Wartung auf und wo fängt Neuentwicklung an?

Kleine Erweiterungen passen ins vereinbarte Monatsbudget. Größere Features werden separat angeboten oder als Softwareentwicklung beauftragt. So wird aus Routinepflege nicht unbemerkt ein offenes Bauprojekt.

Wie wird Wartung abgerechnet?

Als Monatsvertrag für den vereinbarten Umfang. Arbeit außerhalb davon wird vor Beginn angeboten. Vor dem Onboarding-Check nennen wir keinen Preis, weil die Kosten vom System abhängen.

Wartungsvertrag abgrenzen

Beschreibe das System, den Stack, wer es heute wartet und was immer wieder liegen bleibt. Zugangsdaten und vertrauliche Daten gehören nicht in die erste Anfrage.