Software Modernisierung: Fachwissen retten, bevor das Altsystem ausfällt

Stand: 13.08.2026

Die alte Datenbank läuft. Kunden werden gefunden, Leistungen erfasst, Zeiten ausgewertet und Daten nach Excel exportiert. Niemand möchte den Betrieb stören. Gleichzeitig kennt nur noch eine Person alle Sonderfälle. Eine Änderung dauert Wochen, eine neue Schnittstelle wirkt riskant und bei jeder Fehlermeldung hängt der Betrieb am gleichen Ansprechpartner.

Das ist der gefährliche Zwischenzustand vieler Legacy-Systeme: Die Software funktioniert noch, aber das Unternehmen kann sie nicht mehr selbstbestimmt weiterentwickeln.

Eine gute Software Modernisierung beginnt deshalb nicht mit der Frage nach Programmiersprache, Cloud oder neuer Oberfläche. Sie beginnt mit drei anderen Fragen:

1. Welche Fachlogik hält den Betrieb heute zusammen?
2. Welche Daten und Nachweise müssen erhalten bleiben?
3. Wie kann der Übergang geprüft werden, ohne alles auf einmal umzuschalten?

Dieser Beitrag zeigt einen schrittweisen Ansatz für wissensintensive Dienstleistungsbetriebe. Er verspricht weder eine risikofreie Migration noch eine universelle Zielarchitektur. Er hilft dir, das Vorhaben so vorzubereiten, dass Prozesswissen nicht versehentlich mit dem alten System abgeschaltet wird.

Wann alte Software zum Geschäftsrisiko wird

Das Alter einer Anwendung allein macht sie nicht schlecht. Ein zehn oder zwanzig Jahre altes System kann stabil laufen und die Prozesse eines Unternehmens sehr genau abbilden. Kritisch wird es, wenn technische und organisatorische Abhängigkeiten zusammenkommen.

Typische Warnsignale sind:

• Nur eine Person versteht Datenmodell, Quellcode und Sonderfälle.
• Änderungen sind kaum dokumentiert und lassen sich nicht reproduzierbar testen.
• Exporte ersetzen fehlende Schnittstellen.
• Fachliche Regeln stecken in Masken, Abfragen oder persönlichen Routinen.
• Betrieb, Sicherung und Wiederanlauf sind nicht praktisch erprobt.
• Neue Anforderungen werden mit weiteren Ausnahmen in das bestehende System eingebaut.
• Historische Daten sind vorhanden, aber ihre Bedeutung ist nicht eindeutig beschrieben.

Das Kernproblem lautet nicht: „Die Oberfläche sieht alt aus.“ Das Kernproblem lautet: Das Unternehmen kann wichtige Abläufe nicht mehr verlässlich erklären, ändern oder unabhängig betreiben.

NIST ordnet Notfallplanung ausdrücklich in den Zusammenhang von organisatorischer Resilienz und Systemlebenszyklus ein.[1] Das bedeutet nicht, dass jedes Altsystem akut ausfallgefährdet ist. Es bedeutet aber: Wer ein geschäftskritisches System betreibt, sollte Prioritäten, Abhängigkeiten und Wiederanlaufanforderungen kennen.

Das wertvollste Gut steckt nicht im Code

In gewachsener Individualsoftware sammeln sich über Jahre Entscheidungen an:

• Welche Leistung wird welchem Auftrag zugeordnet?
• Wie werden Plan- und Ist-Zeiten verglichen?
• Welche Statuswechsel sind erlaubt?
• Welche Daten müssen bei einem Export enthalten sein?
• Welche historischen Fassungen bleiben auffindbar?
• Welche Ausnahme gilt für einen bestimmten Projekttyp?
• Wann gilt ein Vorgang fachlich als abgeschlossen?

Diese Regeln stehen selten vollständig in einem Handbuch. Ein Teil steckt im Code, ein Teil in Datenbankabfragen, ein Teil in Excel-Dateien und ein Teil in den Köpfen der Mitarbeitenden.

Wer bei der Modernisierung nur Tabellen und Dateien kopiert, migriert deshalb noch keinen funktionierenden Prozess. Daten ohne Bedeutung sind unvollständig. Bedeutung ohne dokumentierte Regeln ist nicht prüfbar.

Vor der Migration: Fachlogik inventarisieren

Die Bestandsaufnahme sollte nicht mit einer Liste technischer Komponenten enden. Sie braucht eine fachliche Landkarte.

1. Kritische Abläufe erfassen

Beginne mit den Prozessen, deren Unterbrechung Kunden, Termine, Abrechnung oder Nachweise direkt betrifft. Beschreibe für jeden Ablauf:

• Auslöser,
• benötigte Eingaben,
• fachliche Prüfungen,
• Status und Freigaben,
• Ergebnis oder Dokument,
• beteiligte Rollen,
• Folgeprozesse,
• bekannte Ausnahmen.

Ein Bildschirmfoto ersetzt diese Beschreibung nicht. Die gleiche Maske kann mehrere fachliche Regeln enthalten, die erst durch Gespräche und Beispieldaten sichtbar werden.

2. Datenobjekte und Beziehungen verstehen

Welche Objekte gibt es tatsächlich? Kunde, Standort, Auftrag, Leistung, Mitarbeiter, Zeitbuchung, Dokument und Regelwerksfassung sind nicht bloß Tabellen. Zwischen ihnen bestehen fachliche Beziehungen.

Für jedes wichtige Objekt solltest du klären:

• Wer legt es an?
• Welche Felder sind verpflichtend?
• Welche Werte werden berechnet?
• Woher stammen Referenzen und Schlüssel?
• Welche Historie wird benötigt?
• Welche Datensätze dürfen nicht zusammengeführt werden?
• Was bedeutet „gelöscht“, „inaktiv“ oder „archiviert“ im heutigen Prozess?

3. Sonderfälle sichtbar machen

Das Standardszenario ist meist schnell erklärt. Das Risiko steckt in den Ausnahmen: langfristige Projekte, rückwirkende Korrekturen, wechselnde Zuständigkeiten, alte Kundennummern oder historische Dokumentstände.

Sammle dafür reale, anonymisierte Beispiele. Frage nicht nur: „Wie sollte es funktionieren?“ Frage auch: „Welche Fälle repariert ihr heute manuell?“

Abhängigkeit von einer Person systematisch reduzieren

Eine einzelne erfahrene Entwicklerperson ist nicht automatisch ein Problem. Kritisch wird die Situation, wenn Wissen, Zugang und Entscheidungsfähigkeit ausschließlich bei ihr liegen.

Die Abhängigkeit lässt sich nicht durch einen weiteren Login lösen. Sie muss in überprüfbare Bausteine zerlegt werden:

• Zugänge: Wo liegen Quellcode, Datenbank, Sicherungen, Dokumentation und Betriebszugänge?
• Wissen: Welche Regeln versteht nur die bisherige Entwicklerperson?
• Betrieb: Wer kann eine Störung einordnen und einen Wiederanlauf begleiten?
• Änderungen: Wie werden Anforderungen, Tests und Auslieferungen dokumentiert?
• Entscheidungen: Wer darf fachliche Regeln freigeben?

Ein guter Wissenstransfer ist keine einmalige Übergabe von Dateien. Er verbindet Interviews, Systemanalyse, dokumentierte Beispiele und gemeinsame Tests. Das Ziel lautet nicht, jede technische Einzelheit in ein Handbuch zu schreiben. Das Ziel lautet, dass mehrere Personen den Betrieb nachvollziehen und Änderungen kontrolliert prüfen können.

Nicht alles neu bauen: Modernisierungswege unterscheiden

„Wir ersetzen das System komplett“ klingt eindeutig, ist aber nicht immer der sicherste Start. Je nach Zustand und Ziel kommen verschiedene Wege infrage:

Weiterbetreiben und absichern

Wenn das System stabil ist und kurzfristig keine Ablösung möglich ist, können zunächst Betrieb, Zugänge, Sicherungen, Monitoring und Dokumentation verbessert werden. Das schafft Zeit, löst aber nicht automatisch die langfristige Wartbarkeit.

Technisch erneuern

Beim Refactoring oder Replatforming bleibt ein großer Teil der fachlichen Funktion erhalten, während technische Komponenten überarbeitet werden. Das kann sinnvoll sein, wenn die Fachlogik belastbar ist und der Code noch ausreichend verstanden wird.

Funktionen schrittweise herauslösen

Bei einer inkrementellen Modernisierung werden einzelne Funktionen oder Prozessbereiche nach und nach ersetzt. Martin Fowler beschreibt dafür das Strangler-Fig-Muster; AWS betont, dass ein schrittweises Vorgehen Transformationsrisiken und Betriebsstörungen gegenüber einer Big-Bang-Migration reduzieren kann, ohne sie vollständig auszuschließen.[2][3]

Neu entwickeln und Daten übernehmen

Eine Neuentwicklung kann sinnvoll sein, wenn Technologie, Datenmodell und Bedienkonzept grundlegend nicht mehr tragfähig sind. Sie ist aber kein Freibrief, alle alten Regeln zu verwerfen. Auch hier müssen benötigte Fachlogik, Datenhistorie und Übergangsprozesse ausdrücklich entschieden werden.

Die richtige Wahl ergibt sich nicht aus einem Modebegriff. Sie hängt von Systemzugang, Codequalität, Datenlage, Veränderungsdruck, Betriebskritikalität und verfügbarer Testbarkeit ab.

Datenmigration ist eine fachliche Prüfung

Bei einer Datenbankmigration wird nicht nur Inhalt von A nach B bewegt. Jeder Datentyp braucht eine Regel:

• unverändert übernehmen,
• bereinigen,
• zusammenführen,
• neu zuordnen,
• nur lesbar archivieren,
• bewusst nicht migrieren.

Besonders wichtig sind Schlüssel und Beziehungen. Wenn ein Dokument zu einem Auftrag gehört, der wiederum einem Kunden und Standort zugeordnet ist, muss diese Kette nach der Migration weiterhin stimmen. Die reine Anzahl der Datensätze reicht als Qualitätsnachweis nicht aus.

Eine belastbare Migration arbeitet deshalb mit Abgleichsregeln:

• Anzahl je Objektart,
• Summen und Zeitwerte,
• Pflichtfelder,
• eindeutige Schlüssel,
• Stichproben kritischer Vorgänge,
• Verknüpfungen zwischen Objekten,
• historische Stände,
• fachliche Ergebnisvergleiche.

Wenn das Altsystem Daten nach Excel exportiert, kann dieser Export während der Übergangsphase als zusätzlicher Kontrollpunkt dienen. Er ist aber nur dann nützlich, wenn Spalten, Berechnungen und Bedeutungen dokumentiert sind.

Parallelbetrieb: Sicherheit durch Vergleich, nicht durch Dauerzustand

Ein zeitlich begrenzter Parallelbetrieb kann helfen, Ergebnisse aus Alt- und Neusystem zu vergleichen. Er ist jedoch kein Selbstzweck. Zwei Systeme bedeuten auch doppelte Pflege, widersprüchliche Stände und zusätzliche Fehlerquellen.

Definiere deshalb vorab:

1. Welche Vorgänge laufen parallel?
2. Welches System ist für welche Daten führend?
3. Welche Ergebnisse werden verglichen?
4. Wer bewertet Abweichungen?
5. Welche Grenzwerte oder Fehler blockieren die Umschaltung?
6. Wann endet der Parallelbetrieb?
7. Wie wird das Altsystem anschließend archiviert oder stillgelegt?

Ein Parallelbetrieb ohne Endkriterium schafft zwei Wahrheiten. Ein kontrollierter Parallelbetrieb schafft Belege für die Umschaltentscheidung.

Sieben Phasen für eine kontrollierte Software Modernisierung

Phase 1: Betriebsrisiko und Ziel klären

Formuliere, warum modernisiert wird. Geht es um Wartbarkeit, fehlende Schnittstellen, personelle Abhängigkeit, Datenqualität oder neue Prozesse? Ohne Priorität wird aus der Modernisierung eine Wunschliste.

Phase 2: System und Prozesswissen inventarisieren

Erfasse Abläufe, Datenobjekte, Rollen, Exporte, Dokumente, Ausnahmen und Betriebsabhängigkeiten. Ordne jedem Punkt eine fachlich verantwortliche Person zu.

Phase 3: Zielbild und Systemgrenzen festlegen

Entscheide, welche Funktionen in das neue System gehören, welche angebunden werden und welche entfallen dürfen. Lege das führende System je Datenbereich fest.

Phase 4: Migrations- und Testregeln definieren

Beschreibe Transformationen, Stichproben, Summenabgleiche und Akzeptanzkriterien, bevor Daten produktiv umgezogen werden.

Phase 5: Kleinen, wertvollen Bereich umsetzen

Wähle einen Prozessabschnitt, der echten Nutzen liefert, aber begrenzte Abhängigkeiten hat. Ein erfolgreicher Pilot muss nicht klein aussehen; er muss fachlich klar prüfbar sein.

Phase 6: Parallel validieren und Abweichungen bearbeiten

Vergleiche Ergebnisse, dokumentiere Ursachen und entscheide bewusst, ob das alte oder neue Verhalten fachlich korrekt ist. Nicht jede Abweichung ist ein Fehler im Neusystem; manche machen alte Inkonsistenzen sichtbar.

Phase 7: Umschalten, archivieren und Verantwortung übergeben

Die Ablösung ist erst abgeschlossen, wenn Betrieb, Dokumentation, Zuständigkeiten, Wiederanlauf und Weiterentwicklung geklärt sind. Das alte System darf nicht versehentlich als Schattenlösung weiterlaufen.

Was in ein Modernisierungs-Backlog gehört

Ein brauchbares Backlog enthält nicht nur Funktionen. Es verbindet Fachlichkeit, Daten und Betrieb:

• Prozessbeschreibung und Akzeptanzkriterien,
• Datenobjekte und Migrationsregeln,
• Rollen und Freigaben,
• Schnittstellen und Exporte,
• Nachvollziehbarkeit relevanter Änderungen,
• Sicherungs- und Wiederanlaufanforderungen,
• Testfälle mit anonymisierten Beispieldaten,
• Dokumentation und Wissenstransfer,
• Abschalt- und Archivierungskriterien.

Das BSI beschreibt sein IT-Grundschutz-Kompendium als Werkzeug, das mögliche Gefährdungen und Sicherheitsanforderungen thematisch strukturiert.[4] Für dein Projekt folgt daraus kein fertiger Migrationsplan. Es unterstreicht aber, dass Sicherheitsanforderungen nicht erst nach der technischen Umsetzung ergänzt werden sollten.

Fünf Fragen an einen Umsetzungspartner

Bevor du eine Software Modernisierung beauftragst, solltest du konkrete Antworten auf diese Fragen erhalten:

1. Wie wird vorhandene Fachlogik erhoben und bestätigt?
2. Wie werden Datenmigration und Beziehungen fachlich geprüft?
3. Wie bleibt der Betrieb während der Umstellung handlungsfähig?
4. Welche Dokumentation und Zugänge liegen anschließend beim Unternehmen?
5. Wie werden Abweichungen, Rückfalloptionen und Abschaltung entschieden?

Eine überzeugende Antwort besteht nicht nur aus Technologiebegriffen. Sie nennt Verantwortliche, Prüfpunkte und konkrete Ergebnisse.

Wenn dein Altsystem heute stark von Word-, Excel- oder manuellen Übergaben abhängt, zeigen die EverHype-Beiträge zur SiFa Software ohne Word-Vorlagen und zur digitalen Begehungsdokumentation, wie Medienbrüche im operativen Alltag entstehen. Die Modernisierungsperspektive dieses Beitrags setzt eine Ebene früher an: beim System, das diese Abläufe, Daten und Regeln langfristig tragen soll.

Fazit

Legacy Software zu modernisieren heißt nicht, Vergangenheit wegzuwerfen. Es heißt, den fachlichen Wert eines gewachsenen Systems von seinen riskanten Abhängigkeiten zu trennen.

Der wichtigste erste Schritt ist keine neue Oberfläche. Es ist eine belastbare Inventur: Prozesse, Daten, Ausnahmen, Zuständigkeiten und Betriebswissen. Darauf aufbauend lässt sich entscheiden, welche Teile abgesichert, technisch erneuert, schrittweise ersetzt oder neu entwickelt werden.

Eine gute Migration ist dann erfolgreich, wenn nicht nur das neue System startet. Sie ist erfolgreich, wenn das Unternehmen seine Abläufe erklären, Daten prüfen, Änderungen kontrollieren und den Betrieb mit mehr als einer einzelnen Wissensperson verantworten kann.

Redaktionsquellen

1. NIST — Contingency Planning Guide for Federal Information Systems, SP 800-34 Rev. 1 — https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final — abgerufen am 13.08.2026 — Zusammenhang von Notfallplanung, organisatorischer Resilienz und Systemlebenszyklus
2. Martin Fowler — Strangler Fig — https://martinfowler.com/bliki/StranglerFigApplication.html — abgerufen am 13.08.2026 — schrittweise Ablösung von Legacy-Anwendungen
3. AWS Prescriptive Guidance — Strangler fig pattern — https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/strangler-fig.html — abgerufen am 13.08.2026 — inkrementelle Migration und Grenzen gegenüber Big-Bang-Ablösungen
4. Bundesamt für Sicherheit in der Informationstechnik — IT-Grundschutz-Kompendium — https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/IT-Grundschutz-Kompendium/it-grundschutz-kompendium_node.html — abgerufen am 13.08.2026 — strukturierte Gefährdungen, Anforderungen und Umsetzungshinweise
5. EverHype — SiFa Software — https://everhype.de/blog/sifa-software-schluss-mit-word-vorlagen-die-deinen-halben-tag-fressen — abgerufen am 13.08.2026 — bestehender Beitrag zu Medienbrüchen in der Dokumentenerstellung
6. EverHype — Digitale Begehungsdokumentation — https://everhype.de/blog/digitale-begehungsdokumentation-der-prozess-der-arbeitssicherheitsfirmen-32-stunden-pro-monat-zuruckgibt — abgerufen am 13.08.2026 — bestehender Beitrag zu operativen Übergaben zwischen Erfassung und Bericht