Der Go-live ist ein Grund zum Feiern. Für die Software beginnt an diesem Tag allerdings erst der längste Abschnitt ihres Lebens. Entwickelt wird eine Anwendung in Monaten, betrieben wird sie über Jahre. Ob diese Jahre ruhig verlaufen, entscheidet sich oft in wenigen Wochen rund um die Übergabe.
Damit geschäftskritische Individualsoftware nach der Übergabe stabil läuft, müssen vor dem Wechsel in den Betrieb sieben Punkte verbindlich geklärt sein: Architektur und Abhängigkeiten, Betriebsdokumentation, Deployment-Prozess, Monitoring, Zugänge, Backup und Wiederherstellung sowie Zuständigkeiten mit klaren Service Levels. Fehlt einer davon, zahlt das Unternehmen später drauf, meist in Form von Ausfällen, langen Fehlersuchen oder Abhängigkeit von einzelnen Personen. Dieser Beitrag zeigt, worauf es bei der Übergabe ankommt, wie der Übergang selbst gelingt und wie DevOps-Prinzipien auch dann funktionieren, wenn Entwicklung und Betrieb bei unterschiedlichen Partnern liegen.
Warum das Thema gerade jetzt so viele Unternehmen beschäftigt
Immer mehr Unternehmen geben den Betrieb ihrer Anwendungen an spezialisierte Dienstleister ab. Eine Studie des Analysehauses Lünendonk unter Führungskräften großer Unternehmen im deutschsprachigen Raum zeigt deutlich, was dahintersteckt:
- Fachkräfte fehlen: Zwischen 72 und 80 Prozent der befragten Unternehmen finden nur schwer rechtzeitig qualifiziertes Personal. Für den Betrieb einer geschäftskritischen Anwendung braucht es aber Menschen, die Datenbanken, Middleware, Cloud-Plattformen und Sicherheit beherrschen. Und zwar so viele, dass auch Urlaub, Krankheit und Bereitschaftsdienste abgedeckt sind.
- Sicherheit und Regulierung ziehen an: Steigende Anforderungen an Cybersecurity und Compliance gehören zu den stärksten Treibern. Regelwerke wie NIS-2 oder DORA verlangen nachweisbar geregelte Prozesse für Betrieb, Störungsbehandlung und Wiederherstellung.
- Teams sollen Wert schaffen: 57 Prozent der Befragten geben an, dass sich ihre Mitarbeitenden zu stark mit Tätigkeiten ohne Mehrwert beschäftigen. Patches einspielen, Logs durchsuchen, nachts Störungen beheben: Das bindet genau die Leute, die eigentlich die Digitalisierung vorantreiben sollten.
- Betrieb und Weiterentwicklung gehören zusammen: 58 Prozent bevorzugen Dienstleister, die beides verantworten. Gesucht ist also ein Partner, der die Anwendung gemeinsam mit dem Unternehmen weiterbringt.
All diese Treiber haben eines gemeinsam: Sie verschärfen die Folgen einer schlechten Übergabe. Wer kaum Personal hat, kann fehlendes Wissen nicht nachträglich aufbauen. Wer Audits bestehen muss, braucht Dokumentation ab dem ersten Tag.
Warum die Übergabe bei Individualsoftware besonders heikel ist
Bei Standardsoftware gibt es einen Hersteller. Der liefert Handbücher, Updates und im Zweifel eine Support-Hotline. Bei Individualsoftware gibt es all das nur, wenn es jemand geschaffen hat.
Das Wissen über eine individuell entwickelte Anwendung steckt häufig in wenigen Köpfen und im Quellcode. Warum ein bestimmter Dienst nachts neu gestartet wird, welche Schnittstelle bei Lastspitzen empfindlich reagiert oder welcher Konfigurationswert keinesfalls geändert werden darf: Solche Dinge stehen selten in einem Dokument. Sie werden erzählt, und zwar meistens erst dann, wenn etwas schiefgeht.
Hinzu kommt, dass Entwicklungsteams und Betriebsteams unterschiedliche Fragen stellen. Entwickler fragen: Funktioniert das Feature? Betreiber fragen: Was passiert, wenn um drei Uhr morgens der Speicher voll ist? Eine gute Übergabe bringt beide Perspektiven rechtzeitig zusammen.
Was vor der Übergabe geklärt sein muss
Architektur und Abhängigkeiten
Welche Komponenten gehören zur Anwendung, wie hängen sie zusammen und welche externen Systeme werden angesprochen? Ein aktuelles Architekturbild mit allen Schnittstellen, Datenflüssen und Fremdkomponenten ist die Grundlage für alles Weitere. Dazu gehört auch eine Liste der eingesetzten Frameworks und Bibliotheken samt Versionen, denn jede davon braucht irgendwann Sicherheitsupdates.
Prüffrage: Könnte ein erfahrener Betreiber, der die Anwendung nie gesehen hat, anhand der Unterlagen erklären, was bei einem Ausfall der Datenbank passiert?
Betriebsdokumentation und Runbooks
Ein Betriebshandbuch beschreibt Start, Stopp, Wartung und Wiederanlauf. Runbooks gehen eine Ebene tiefer: Sie sind Schritt-für-Schritt-Anleitungen für wiederkehrende Aufgaben und bekannte Störungen. Gerade die bekannten Eigenheiten einer Anwendung gehören hier hinein, auch wenn sie dem Entwicklungsteam peinlich sind.
Prüffrage: Gibt es für die fünf häufigsten Störungen eine schriftliche Anleitung?
Deployment- und Release-Prozess
Wie kommt eine neue Version in Produktion? Im besten Fall über eine automatisierte Pipeline, die Tests ausführt und Deployments reproduzierbar macht. Im schlechtesten Fall über eine Abfolge manueller Schritte, die nur eine Person kennt. Ebenso wichtig ist die Rückfallebene: Wie wird eine fehlerhafte Version zurückgerollt und wie lange dauert das?
Prüffrage: Lässt sich ein Rollback innerhalb des vereinbarten Zeitrahmens durchführen, ohne dass das Entwicklungsteam eingreifen muss?
Monitoring, Logging und Alarmierung
Ein Betreiber kann nur reagieren, wenn er sieht, was passiert. Neben technischen Werten wie CPU-Last und Antwortzeiten zählen fachliche Kennzahlen: Laufen Bestellungen durch, werden Batch-Jobs pünktlich fertig? Logs sollten zentral gesammelt und durchsuchbar sein. Für jeden Alarm sollte feststehen, wer reagiert und was zu tun ist.
Prüffrage: Merkt der Betrieb einen Fehler, bevor ihn ein Anwender meldet?
Zugänge, Berechtigungen und Secrets
Passwörter, API-Schlüssel und Zertifikate werden bei Übergaben gern per E-Mail verschickt oder in einer Tabelle gesammelt. Sicherer ist ein zentraler Secret-Store mit klar geregelten Rechten. Bei der Übergabe sollte zudem geprüft werden, welche Zugänge das Entwicklungsteam noch hat und welche davon künftig gebraucht werden. Ablaufende Zertifikate verdienen einen eigenen Eintrag im Kalender, denn sie gehören zu den häufigsten Ursachen für vermeidbare Ausfälle.
Prüffrage: Ist bekannt, wann welches Zertifikat abläuft und wer es erneuert?
Backup und Wiederherstellung
Ein Backup ist erst dann etwas wert, wenn die Wiederherstellung getestet wurde. Für geschäftskritische Anwendungen sollten zwei Werte vereinbart sein: wie viel Datenverlust höchstens tolerierbar ist (Recovery Point Objective) und wie schnell die Anwendung wieder laufen muss (Recovery Time Objective). Beides hat direkte Folgen für Technik und Kosten.
Prüffrage: Wann wurde die Wiederherstellung zuletzt vollständig durchgespielt?
Zuständigkeiten, Eskalation und SLAs
Wer macht was? Diese Frage klingt banal und ist doch der häufigste Grund für Reibung nach der Übergabe. Eine Verantwortungsmatrix klärt, wer für Infrastruktur, Plattform, Anwendung und Fachlogik zuständig ist. Besonders wichtig ist die Grenze zwischen Betrieb und Entwicklung: Der Betreiber verantwortet den laufenden Betrieb der Anwendung und der Systeme darunter. Fehlerbehebung im Code und Weiterentwicklung bleiben beim Entwicklungsteam. Service Level Agreements legen Verfügbarkeit, Reaktionszeiten und Servicezeiten fest. Und ein Eskalationsweg regelt, wann das Entwicklungsteam hinzugezogen wird.
Prüffrage: Weiß bei einer Störung am Samstagabend jeder Beteiligte, wer zuständig ist?
Der Übergang selbst: Lieber Staffelstab als Sprung ins kalte Wasser
Eine Übergabe ist kein einzelner Termin, an dem ein Ordner den Besitzer wechselt. Bewährt hat sich ein gestufter Ablauf:
- Vorbereitung: Das Betriebsteam arbeitet sich in Architektur und Dokumentation ein und prüft, was fehlt. Lücken werden jetzt geschlossen, solange das Entwicklungsteam noch voll verfügbar ist.
- Parallelbetrieb: Der Betreiber übernimmt Schritt für Schritt Aufgaben, während das Entwicklungsteam noch mit im Boot sitzt. Ein Deployment unter Aufsicht oder eine simulierte Störung zeigt schnell, wo die Unterlagen noch nicht reichen.
- Hypercare: Nach dem formalen Wechsel steht das Entwicklungsteam für einige Wochen mit kurzen Reaktionszeiten bereit, falls unerwartete Probleme auftauchen.
Klare Abnahmekriterien legen fest, wann die Übergabe als abgeschlossen gilt, etwa eine bestimmte Zeit ohne kritische Störung oder ein erfolgreich durchgeführtes Release.
DevOps und ausgelagerter Betrieb: Ein Widerspruch?
Wer sich mit DevOps beschäftigt, stolpert an dieser Stelle über eine berechtigte Frage. DevOps will die Trennung zwischen Entwicklung und Betrieb ja gerade überwinden. Passt eine Übergabe an einen externen Betreiber da überhaupt ins Bild?
Sie passt, wenn man die Übergabe anders versteht: als Startpunkt einer dauerhaften Zusammenarbeit, nach dem eben nicht jede Seite ihr eigenes Ding macht. Die Grundideen von DevOps lassen sich gut auf Konstellationen mit mehreren Partnern übertragen:
- Gemeinsame Pipeline: Entwicklung und Betrieb nutzen dieselbe automatisierte Strecke vom Code bis zur Produktion. Betriebsanforderungen fließen als Tests und Prüfungen direkt in diese Pipeline ein.
- Gemeinsame Sicht: Beide Seiten greifen auf dasselbe Monitoring und dieselben Logs zu. Diskussionen darüber, wessen Fehler es war, werden damit deutlich kürzer.
- Gemeinsames Lernen: Nach größeren Störungen analysieren beide Teams gemeinsam, was passiert ist, ohne Schuldzuweisung. Die Ergebnisse landen in Code, Runbooks oder Monitoring.
- Betrieb von Anfang an mitdenken: Bei neuen Features ist der Betreiber früh eingebunden. Fragen zu Skalierung, Logging oder Wiederanlauf werden geklärt, bevor sie in Produktion zum Problem werden.
So wird aus der einmaligen Übergabe eine laufende, gut gepflegte Schnittstelle. Für Unternehmen, die Betrieb und Weiterentwicklung eng verzahnt haben möchten, ist genau das der entscheidende Punkt.
Checkliste: Woran man einen guten Betriebspartner erkennt
Bei geschäftskritischen Anwendungen ist der Betreiber ein Partner, dem man ein zentrales Stück des eigenen Geschäfts anvertraut. Diese Fragen helfen bei der Auswahl:
Betrieb fremder Software: Betreibt der Dienstleister auch Anwendungen, die er nicht selbst entwickelt hat?
Klare Abgrenzung: Ist eindeutig festgelegt, wo seine Verantwortung endet und wo die Zuständigkeit Ihres Entwicklungsteams beginnt?
Aktive Rolle: Fordert er Dokumentation und Informationen ein, statt einfach zu übernehmen, was geliefert wird?
Feste Ansprechpartner: Gibt es technische Ansprechpartner, die die Anwendung kennen?
Realistische SLAs: Sind Service Levels, Bereitschaft und Eskalation klar geregelt und bei Bedarf rund um die Uhr abgedeckt?
Nachweisbare Sicherheit: Kann er Sicherheit und Prozessqualität belegen, etwa durch Zertifizierungen und Prüfberichte?
Zusammenarbeit: Ist er bereit, mit Ihrem Entwicklungsteam oder Ihrer Agentur auf Augenhöhe zusammenzuarbeiten?
Ein Partner, der vor der Übergabe viele unbequeme Fragen stellt, ist übrigens meist ein gutes Zeichen.
Häufige Fragen zur Übergabe von Software in den Betrieb
Das hängt von Komplexität und Dokumentationsstand ab. Für eine mittelgroße geschäftskritische Anwendung sind einige Wochen bis wenige Monate realistisch, inklusive Parallelbetrieb und Hypercare.
Ja, im Applikationsbetrieb ist das üblich. Der Betreiber verantwortet dabei den laufenden Betrieb der Anwendung und der darunterliegenden Systeme, also etwa Monitoring, Deployments, Patches, Backups und Störungsbehandlung. Der Quellcode bleibt in der Verantwortung des Entwicklungsteams. Voraussetzung ist eine sorgfältige Übergabe mit vollständiger Betriebsdokumentation.
Der Betrieb der Anwendung kann weiterlaufen, ein Betreiber ersetzt aber kein Entwicklungsteam. Fehler im Code oder notwendige Anpassungen braucht weiterhin jemand, der die Software kennt und weiterentwickelt. Unternehmen sollten deshalb rechtzeitig klären, wer diese Rolle künftig übernimmt, etwa ein neuer Entwicklungspartner.
Ein festgelegter Zeitraum nach dem Wechsel in den Betrieb, in dem das Entwicklungsteam mit verkürzten Reaktionszeiten unterstützt. So lassen sich Anlaufprobleme schnell beheben.
Fazit
Eine gute Übergabe macht aus einer funktionierenden Anwendung eine betreibbare Anwendung. Dokumentation, automatisierte Deployments, aussagekräftiges Monitoring, getestete Wiederherstellung und klare Zuständigkeiten sind dafür die Bausteine. Fachkräftemangel und steigende regulatorische Anforderungen machen diese Bausteine wichtiger denn je. Wer die Übergabe zudem als Beginn einer engen Zusammenarbeit zwischen Entwicklung und Betrieb versteht, holt das Beste aus beiden Welten heraus.
Klingt spannend? Reden wir darüber
Geschäftskritische Anwendungen verdienen einen Betrieb, auf den Sie sich verlassen können. Das gilt ganz besonders für individuell entwickelte Software, für die es keinen Hersteller-Support gibt.
Bei ONTEC betreiben wir individuelle Anwendungen und die Systeme darunter, auch wenn wir sie nicht selbst entwickelt haben. Bei der Übergabe und im laufenden Betrieb arbeiten wir eng mit Ihrem Entwicklungsteam oder Ihrer Agentur zusammen. Der Code bleibt dort, wo er hingehört: in deren Händen. Wir sorgen mit klar definierten SLAs, direkten technischen Ansprechpartnern und auf Wunsch 24/7-Betrieb für Stabilität. Außerdem sind wir nach ISO 27001 zertifiziert und verfügen über einen Kontrollbericht nach ISAE 3402.
Steht bei Ihnen eine Übergabe in den Betrieb an oder läuft Ihre Anwendung bereits und braucht ein neues Zuhause? Lassen Sie uns unverbindlich darüber sprechen.
Hannes Gruber
ONTEC AG
Kundenorientierung bedeutet für mich sich in die Lage des Kunden versetzen zu können. Genaues Zuhören, verstehen und ein fachlich top aufgestelltes Team sind hierbei entscheidend, um den Kunden die optimale Lösung anzubieten.
