Notfallplan für kritische Altsoftware: Was tun wenn das System ausfällt?

Das Szenario kennen viele Entscheider im Mittelstand: Die interne Buchhaltungssoftware, das Warenwirtschaftssystem oder das Kundenportal läuft seit Jahren zuverlässig. Niemand schaut genau hin. Und dann fällt es aus.

Wer in diesem Moment keinen Notfallplan für seine Software hat, zahlt zweimal. Einmal mit Ausfallzeiten. Einmal mit hektischem, teurem Krisenmanagement.

Dieser Artikel zeigt, wie ein Notfallplan für kritische Altsoftware aussieht und warum er schon vor dem ersten Problem existieren muss.

Warum Altsoftware im Ausfall besonders riskant ist

Neue Software hat Dokumentation. Sie hat Support. Sie hat Entwickler, die sie kennen.

Legacy-Systeme, also ältere gewachsene Software, haben das oft nicht. Der Entwickler der das System gebaut hat, ist längst in Rente oder bei einem anderen Arbeitgeber. Die Dokumentation besteht aus einer vergilbten Textdatei und Kommentaren im Code, die niemand mehr lesen kann. Und der Server auf dem alles läuft, wurde zuletzt vor drei Jahren angefasst.

Wenn so ein System ausfällt, entsteht sofort ein Problem: Es gibt niemanden der sagt, was zu tun ist.

Das ist keine theoretische Gefahr. Ausfälle bei Altsystemen dauern im Schnitt deutlich länger als bei modernen Anwendungen. Der Grund: fehlende Dokumentation, unbekannte Abhängigkeiten und mangelnde Testbarkeit.

Besonders problematisch: Viele Altsysteme tragen technische Schulden mit sich, die im Normalbetrieb unsichtbar sind. Im Ausfall kommen sie alle gleichzeitig ans Licht.

Was ohne Notfallplan passiert

Stellen Sie sich vor: Es ist Montagmorgen. Ihr Warenwirtschaftssystem startet nicht. Keine Fehlermeldung, die jemand deuten kann. Kein Zugriff auf die Kundendaten.

Ohne Notfallplan beginnt jetzt eine hektische Suche. Wer hat das System zuletzt angefasst? Wo liegt die Backup-Datei? Gibt es überhaupt ein Backup? Welcher Dienstleister ist zuständig?

Diese Suche kostet Zeit. Jede Stunde Ausfall bedeutet: Mitarbeiter, die nicht arbeiten können. Kunden, die nicht bedient werden. Aufträge, die nicht bearbeitet werden.

Hinzu kommt: In der Panik werden Fehler gemacht. Systeme werden ohne Backup neu gestartet. Konfigurationen werden überschrieben. Was ein behebares Problem war, wird zu einem dauerhaften Datenverlust.

Was ein guter Notfallplan enthält

Ein Notfallplan für kritische Altsoftware ist kein 50-seitiges Dokument. Er muss schnell auffindbar sein und sofort handlungsweisend wirken.

1. Kontaktliste für den Ernstfall

Die erste Frage im Ausfall: Wen ruf ich an?

Die Kontaktliste enthält mindestens:

• Interne Ansprechpartner mit Erreichbarkeit auch außerhalb der Bürozeiten
• Externen Dienstleister für das spezifische System oder für Legacy-Software generell
• Hosting-Anbieter oder Rechenzentrumskontakt
• Datenbankadministrator, falls relevant

Die Liste muss gedruckt existieren. Im Ausfall kann der Zugang zu digitalen Systemen eingeschränkt sein. Ein Blatt Papier funktioniert immer.

2. Backup-Dokumentation

Im Notfall muss sofort klar sein:

• Wo liegen die aktuellsten Backups?
• Wie alt ist das jüngste Backup?
• Wie wird ein Backup eingespielt?
• Wurde das Backup zuletzt getestet?

Der letzte Punkt ist entscheidend. Viele Unternehmen haben technisch Backups, die aber nie wiederhergestellt wurden. Ein nicht getestetes Backup ist kein Backup. Es ist eine Hoffnung.

3. Systemdokumentation für den Ersteingriff

Auch ein externer Spezialist braucht Grundinformationen, um schnell zu helfen:

• Welches Betriebssystem und welche Version?
• Welche Datenbankversion?
• Welche Programmiersprache und welche Version?
• Wo liegt der Code (Server-Pfad, Versionsverwaltung)?
• Welche externen Dienste oder Schnittstellen werden genutzt?

Diese Informationen müssen nicht vollständig sein. Aber sie geben einem Spezialisten einen Startpunkt.

4. Priorisierung nach Kritikalität

Nicht jede Funktion eines Systems ist gleich wichtig.

Im Ausfall muss klar sein: Was muss als erstes wieder laufen? Was kann einen Tag warten?

Ein Webshop als Beispiel: Der Checkout muss sofort laufen. Das Reporting kann warten. Diese Priorisierung hilft, im Stress die richtigen Entscheidungen zu treffen.

5. Kommunikationsplan

Wer informiert Kunden, Lieferanten oder Mitarbeiter wenn das System ausfällt?

Ein schlichter Prozess reicht: Wer entscheidet ob und wann kommuniziert wird? Wer schreibt die Nachricht? Über welche Kanäle geht sie raus?

Das klingt banal. Im Stress vergessen es trotzdem viele.

Wann der Notfallplan nicht reicht

Ein Notfallplan hilft im Ernstfall. Er ersetzt aber keine strukturelle Software-Wartung.

Wer eine veraltete Anwendung ohne Dokumentation, ohne Monitoring und ohne Versionsverwaltung betreibt, hat ein langfristiges Risikoproblem. Ein Notfallplan reduziert den Schaden im Ausfall. Er verhindert den Ausfall nicht.

Die sinnvolle Reihenfolge: Notfallplan erstellen, gleichzeitig mit der strukturellen Verbesserung beginnen. Beides zusammen ist nachhaltiger als nur eines von beiden.

Disaster Recovery: Was der Begriff bedeutet

Im Zusammenhang mit Notfallplänen fällt oft der Begriff Disaster Recovery (auf Deutsch: Notfallwiederherstellung). Er beschreibt den strukturierten Prozess, ein IT-System nach einem schwerwiegenden Ausfall wiederherzustellen.

Für Legacy-Systeme ist Disaster Recovery oft das schwächste Glied. Moderne Cloud-Systeme haben Disaster Recovery eingebaut. Ältere Anwendungen auf eigenen Servern haben das nicht automatisch.

Ein einfacher Disaster-Recovery-Plan für Altsoftware beantwortet drei Fragen:

Wie lange darf das System maximal ausfallen? Das nennt man Recovery Time Objective (RTO). Für ein Kundenportal könnte das vier Stunden sein. Für interne Verwaltungssoftware vielleicht zwei Tage.

Wie viele Daten darf die Wiederherstellung maximal verlieren? Das nennt man Recovery Point Objective (RPO). Wenn das letzte Backup 24 Stunden alt ist, können im schlimmsten Fall 24 Stunden Daten verloren gehen.

Wie wird das System im Ernstfall wiederhergestellt? Schritt für Schritt, mit konkreten Befehlen und Zugangsdaten, die sicher verwahrt sind.

Wer diese drei Fragen beantwortet hat, hat den Kern eines Notfallplans für sein Legacy-System.

Der erste Schritt: Bestandsaufnahme in zwei Stunden

Viele Unternehmen wissen nicht, wo sie anfangen sollen. Der Einstieg ist einfacher als gedacht.

Reservieren Sie zwei Stunden. Beantworten Sie diese Fragen schriftlich:

1. Welche Systeme sind geschäftskritisch?
2. Wer wäre im Ernstfall erreichbar, auch abends und am Wochenende?
3. Wo liegen Backups? Wurden sie je getestet?
4. Was ist die PHP-, Java- oder Datenbankversion des Systems?
5. Welcher externe Dienstleister könnte im Notfall helfen?

Das Ergebnis ist kein vollständiger Notfallplan. Aber es ist ein ehrliches Bild der aktuellen Situation. Und oft erschreckend aufschlussreich.

Die meisten Unternehmen stellen bei dieser Übung fest: Der Notfallplan für ihre Software ist nicht vorhanden. Niemand weiß, wer im Ernstfall was tut.

Das ist der Moment, um zu handeln. Nicht wenn das System ausfällt.

Fazit: Vorbereitung kostet wenig, Unvorbereitung kostet viel

Ein Notfallplan für kritische Altsoftware kostet wenige Stunden Arbeit. Ein ungeplanter Ausfall ohne Plan kostet Tage, manchmal Wochen.

Die gute Nachricht: Sie müssen diesen Plan nicht alleine erstellen. Wir helfen Ihnen, den Zustand Ihrer Altsoftware einzuschätzen und gemeinsam einen Notfallplan zu erarbeiten, der wirklich funktioniert, wenn es darauf ankommt.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos.