Legacy-Software modernisieren: Weiterbetreiben, umbauen oder ersetzen?

Eine zwölf Jahre alte Anwendung kann zuverlässig Aufträge abwickeln. Eine zwei Jahre alte Anwendung kann bereits schwer veränderbar sein. Das Alter allein rechtfertigt deshalb keine Neuentwicklung. Relevant wird Modernisierung, wenn das Unternehmen einen konkreten Nachteil hat: Änderungen blockieren neue Angebote, die Plattform verliert Unterstützung oder zentrale Abläufe hängen vom Wissen einer einzigen Person ab.

Gleichzeitig steckt in gewachsener Software oft viel betriebliche Erfahrung. Sonderpreise, Korrekturbuchungen und seltene Ausnahmen sind möglicherweise nur im Programm dokumentiert. Wer ausschließlich Oberfläche und Standardabläufe nachbaut, kann diese Regeln verlieren. Ein gutes Modernisierungsprojekt macht daher zuerst sichtbar, was erhalten bleiben muss und welches Problem die Investition tatsächlich beseitigen soll.

Eine Bestandsaufnahme mit Folgen statt einer Liste alter Technologien

Für jede wichtige Anwendung werden Prozess, Nutzer, Daten, Integrationen und Verantwortliche erfasst. Ergänzt werden konkrete Beobachtungen: Wie lange dauerte die letzte Änderung? Welche manuellen Übertragungen treten jede Woche auf? Welche Versionen sind noch unterstützt? Gibt es einen getesteten Wiederherstellungsweg? Aussagen wie „schwer wartbar“ werden erst brauchbar, wenn Aufwand, Häufigkeit und geschäftliche Folge dahinterstehen.

Ein mögliches Ergebnis lautet: Der Monatsimport benötigt zwei Tage Nacharbeit, weil Kundennummern aus drei Systemen nicht übereinstimmen. Dafür kann eine saubere Schnittstelle ausreichend sein. Ein anderes Ergebnis ist ein nicht mehr unterstütztes Betriebssystem, auf dem nur eine notwendige Altanwendung läuft. Hier sind Plattformwechsel, ein Produktwechsel oder eine befristete Übergangslösung zu prüfen. Das sind unterschiedliche Projekte und sollten keine identische Standardantwort erhalten.

Welche Modernisierungsstrategie löst welches Problem?

Auch Microsoft unterscheidet in seiner Migrationsplanung zwischen Strategien und bewertet Arbeitslasten mit ihren Abhängigkeiten. Ein Umzug in die Cloud ist damit eine mögliche Infrastrukturentscheidung, kein automatischer Nachweis einer modernisierten Anwendung. Ob eigener Server oder Dienstleister sinnvoller ist, behandelt Server kaufen, mieten oder Cloud nutzen.

Schrittweise ablösen – mit einer klaren Grenze für den Parallelbetrieb

Beim Strangler-Fig-Muster übernehmen neue Komponenten nach und nach abgegrenzte Aufgaben. Eine vorgeschaltete Schnittstelle führt Anfragen an die jeweils zuständige Anwendung. Microsoft weist dabei auf zusätzliche Übergangskosten, gemeinsame Daten und die mögliche Engstelle dieser Vermittlung hin. Das Muster passt außerdem nicht zu jedem kleinen oder kurzfristig komplett abzulösenden System. Diese Grenzen beschreibt die offizielle Strangler-Fig-Dokumentation.

Ein Beispiel wäre eine gewachsene Auftragsverwaltung, aus der zuerst die Kundenansicht herausgelöst wird. Angebote und Rechnungen bleiben zunächst im bestehenden System. Vor dem Pilot wird festgelegt, welches System Kundenadressen ändern darf und wie Änderungen übertragen werden. Zwei unkoordinierte Schreibwege führen schnell zu widersprüchlichen Daten. Die neue Oberfläche allein ist deshalb kein sinnvoller Meilenstein; ein vollständig nachvollziehbarer Datenfluss ist es.

Jede Übergangsbrücke braucht zudem ein Abschaltkriterium. Wenn alte und neue Systeme dauerhaft dieselbe Aufgabe erfüllen, zahlt das Unternehmen für zwei Plattformen und die Verbindung dazwischen. Für den Pilot könnte das Ziel lauten: Alle aktiven Kunden sind abgeglichen, die Fachabteilung nutzt die neue Ansicht und kein produktiver Leser benötigt mehr die bisherige Schnittstelle. Erst dann kann deren Betrieb tatsächlich entfallen.

Der Business Case braucht Entwicklung, Übergang und Betrieb

Verglichen werden mindestens zwei Szenarien über denselben Zeitraum: stabilisierter Weiterbetrieb und die vorgeschlagene Modernisierung. Beide enthalten Hosting, Lizenzen, Betreuung und erwarteten Änderungsaufwand. Bei der Migration kommen Analyse, Datenbereinigung, Parallelbetrieb, Schulung und Stilllegung hinzu. Ungewisse Einsparungen sollten als Bandbreite erscheinen, nicht als bereits sicherer Ertrag.

Ein reines Rechenbeispiel: Wenn eine Schnittstelle monatlich zehn Stunden Nacharbeit tatsächlich einspart und intern 70 Euro je Stunde angesetzt werden, beträgt die rechnerische jährliche Entlastung 8.400 Euro. Zusätzliche Betriebs- und Wartungskosten werden davon abgezogen. Ob die Zeit als Kostensenkung oder als freie Kapazität nutzbar wird, hängt vom Betrieb ab. Eine angenommene Ausfallvermeidung darf nicht ohne Begründung als garantierte zusätzliche Ersparnis eingerechnet werden.

Ein Datenimport ist erst nach dem fachlichen Abgleich fertig

Gleiche Datensatzanzahlen beweisen keine korrekte Migration. Kundennummern, Summen, Beziehungen, Zeichensätze, Zeitzonen und historische Sonderfälle benötigen eigene Prüfungen. Die Fachabteilung sollte vor dem Umbau repräsentative Fälle zusammenstellen: etwa einen normalen Auftrag, eine Teilstornierung, eine Gutschrift und einen nachträglich geänderten Ansprechpartner. Diese Fälle werden in beiden Systemen mit erwarteten Ergebnissen geprüft; Abweichungen erhalten eine fachliche Entscheidung.

Ebenso muss klar sein, wie neue Änderungen während der Umschaltung behandelt werden. Nach produktiven Schreibzugriffen auf dem neuen System reicht es häufig nicht, den alten Server einfach wieder einzuschalten. Der Rückweg braucht Datenabgleich, ein vereinbartes Zeitfenster oder eine vorab definierte Vorwärtskorrektur. Der folgende Praxisteil zeigt, wie sich diese Fragen in überprüfbare Projektetappen übersetzen lassen.

Unsere IT-Beratung unterstützt die Bestandsaufnahme; API-Entwicklung hilft bei abgegrenzten Übergängen. Für ein wartbares Zielbild lohnt ergänzend die Entscheidungshilfe zu IT-Architekturen. Modernisierung ist erfolgreich, wenn eine konkrete Einschränkung verschwindet und der verbleibende Betrieb für das Team beherrschbar bleibt.