Ihr Legacy-System ist Ihr Wettbewerbsvorteil

Die Entscheidung, vor der jede IT-Führungskraft steht

Irgendwann erreicht jedes große Unternehmen denselben Punkt: Ein zentrales System, das seit Jahrzehnten zuverlässig die Geschäftsprozesse trägt, hält mit den Anforderungen nicht mehr Schritt. Der Betrieb wird teurer, Änderungen dauern länger, und die Lücke zwischen dem, was das System kann, und dem, was das Unternehmen braucht, wächst stetig. Die Frage ist nicht ob gehandelt werden muss – sondern wie.

Zwei Wege dominieren die Diskussion. Erstens: die eigene IT-Abteilung entwickelt neu – ein neues Team, ein sauberer Schnitt, diesmal richtig gemacht. Zweitens: ein Standardprodukt einführen – eine bewährte Plattform, konfiguriert nach den eigenen Bedürfnissen, damit der Fokus wieder auf das Kerngeschäft gelegt werden kann. Beide Wege sind vertraut. Beide werden intensiv vermarktet. Und beide scheitern in der Praxis weit häufiger, als ihre Befürworter zugeben.

Es gibt einen dritten Weg. Er beginnt mit einer Erkenntnis, die zunächst kontraintuitiv wirkt: Das System, das ersetzt werden soll, ist nicht das Problem. Es ist eines der wertvollsten Assets des Unternehmens.

Zwei bekannte Fallen

Eigenentwicklung: Die Komplexitätsillusion

Für die Eigenentwicklung spricht zunächst einiges. Das eigene Team kennt das Geschäft, die Kontrolle bleibt im Haus, Abhängigkeiten von Drittanbietern lassen sich vermeiden. Was dabei regelmäßig unterschätzt wird, ist die Komplexität, die im vorhandenen System bereits steckt.

Ein Kernbankensystem, eine Versicherungsplattform oder ein Manufacturing Execution System, das seit 20 oder 30 Jahren produktiv ist, verarbeitet nicht einfach Transaktionen. Es verkörpert tausende Sonderfälle, regulatorische Anpassungen, durch harte Erfahrung verfeinerte Geschäftsregeln und Prozesslogik, die in keinem Anforderungsdokument steht – weil sie nie aufgeschrieben wurde. Sie entstand im Betrieb, wurde an der Realität gemessen und über Jahrzehnte korrigiert.

Teams, die eine Eigenentwicklung angehen, stoßen regelmäßig sechs bis zwölf Monate nach Projektstart auf diese Komplexität – dann nämlich, wenn die Lücke zwischen dem, was spezifiziert wurde, und dem, was das alte System tatsächlich leistet, nicht mehr zu ignorieren ist. Aus zwei Jahren werden fünf. Budgets verdoppeln sich. Und das resultierende System, entwickelt von einem Team ohne die nötige Tiefe, das Vorgängersystem wirklich zu verstehen, erreicht selten dessen Qualität oder Vollständigkeit.

Standardprodukt: Die Anpassungsfalle

Das Standardprodukt verspricht Geschwindigkeit, Verlässlichkeit und eingespielte Best Practices. Für wirklich generische Prozesse – Gehaltsabrechnung, Spesenverwaltung, einfache HR-Funktionen – hält es dieses Versprechen oft. Doch bei den Systemen, die definieren, wie ein Unternehmen am Markt agiert, stoßen Standardprodukte schnell an ihre Grenzen.

Kein Versicherungsprodukt steuert Risiken genau so wie das eigene. Keine Bankplattform bildet die spezifische Kundensegmentierung, Preislogik oder regulatorische Ablaufsteuerung eines Instituts vollständig ab. Kein Fertigungssystem kennt die eigenen Qualitätsprotokolle und Lieferantenbeziehungen. Genau die Geschäftsprozesse, die am Markt differenzieren, sind per Definition nicht standard.

Was folgt, ist vorhersehbar: Ein Anpassungsprojekt, das 18 Monate dauern sollte, zieht sich über vier Jahre hin, kostet das Drei- bis Fünffache des ursprünglichen Budgets und produziert am Ende ein System, das so stark verändert wurde, dass jedes Upgrade einen neuen Anpassungszyklus auslöst. Die Produkt-Roadmap des Herstellers wird zur eigenen Beschränkung. Die Wettbewerbsdifferenzierung des Unternehmens wird schrittweise auf den kleinsten gemeinsamen Nenner des Anbieters eingeebnet.

Der dritte Weg: Software Transformation durch Experten

Software Transformation – so wie itestra sie über mehr als 20 Jahre hinweg bei über 90 Unternehmenskunden praktiziert hat – ist keiner der beiden beschriebenen Wege. Es ist kein Rewrite, das das Bestehende verwirft, und kein Produktprojekt, das das Unternehmen in eine fremde Schablone presst. Es ist ein methodischer, von Experten geführter Prozess: das Vorhandene verstehen, eine bessere Architektur dafür entwerfen und es in ein modernes, wartbares, leistungsfähiges Individualsystem re-engineeren – eines, das die gewachsene Geschäftslogik erhält und weiterentwickelt.

Dieser Ansatz beruht auf vier Fähigkeiten, die zusammenwirken müssen. Einzeln sind sie wertvoll. Kombiniert bilden sie den Unterschied zwischen einer erfolgreichen Transformation und einem weiteren gescheiterten Modernisierungsprogramm.

Das gesamte System verstehen – in jeder Größenordnung

Die erste und am meisten unterschätzte Fähigkeit ist das vollständige Verstehen von Code. Nicht Stichproben. Nicht ein High-Level-Architekturreview. Sondern ein echtes, von Grund auf erarbeitetes Verständnis dessen, was jede wesentliche Komponente eines Systems tatsächlich tut.

Das ist entscheidend, weil die Lücke zwischen Dokumentation und Realität in langjährig gewachsenen Unternehmenssystemen enorm ist. Die Dokumentation beschreibt das System, wie es entworfen wurde. Der Code zeigt, wie es sich entwickelt hat – durch jahrelange Incident-Fixes, regulatorische Anpassungen, Performance-Patches und Sonderlösungen für wichtige Kunden. Diese beiden Perspektiven stimmen selten überein.

itestras Teams sind darauf ausgelegt, auf dieser Ebene zu arbeiten. Systeme mit Millionen von COBOL-Zeilen, jahrzehntelang gewachsenen Batch-Job-Abhängigkeiten und undokumentierten Datenflüssen zwischen Systemen sind kein Sonderfall – sie sind das typische Projektprofil. Die Werkzeuge haben sich erheblich weiterentwickelt: Agentische KI unterstützt heute die Code-Analyse und die Dokumentationsgenerierung und komprimiert, was früher Monate dauerte, auf Wochen. Die nötige analytische Disziplin – also zu wissen, welche Fragen zu stellen sind, welche Muster zu suchen sind und welche vermeintlich kleinen Details systemisches Risiko bergen – entsteht aus der Erfahrung von mehr als 200.000 Personentagen in der Praxis.

Ohne dieses Fundament ist alles Folgende auf Spekulation gebaut. Entscheidungen zur Architektur, die ohne vollständiges Verständnis des bestehenden Verhaltens getroffen werden, reproduzieren alte Probleme in neuem Code.

Eine Architektur entwerfen, die trägt

Das Verstehen eines Systems ist notwendig, aber nicht hinreichend. Die zweite Fähigkeit besteht darin, dieses Verständnis in eine Architektur zu übersetzen, die wirklich trägt – nicht nur eine modern aussehende Variante der alten Struktur.

Hier machen viele Transformationsprojekte einen typischen Fehler: Sie migrieren die Technologie – von COBOL nach Java, vom Mainframe in die Cloud – ohne die Architektur grundlegend zu überdenken. Das Ergebnis ist ein moderner Technologie-Stack, der alte Architekturlogik ausführt: dieselben engen Kopplungen, dieselben Datenmodellkompromisse und dieselben Batch-Ära-Annahmen, verpackt in einem Microservices-Wrapper.

itestra entwirft Architekturen, die wartbar, leistungsfähig und strategisch erweiterbar sind. Das heißt: Module klar trennen, Verantwortlichkeiten für Daten regeln, eindeutige API-Grenzen definieren und das Deployment-Layout so wählen, dass sich das System sauber skalieren lässt. All das geschieht mit Blick auf die technischen Gegebenheiten des bestehenden Systems und darauf, wohin sich das Unternehmen strategisch entwickeln will. Wer die Architektur so durchdenkt, senkt künftige Änderungskosten, kann neue Funktionen schneller liefern und legt das Fundament, auf dem das System in den nächsten zehn Jahren weitergebaut werden kann.

Der Maßstab ist nicht „besser als bisher”. Der Maßstab ist State-of-the-Art für das jeweilige Problemfeld: die Architektur, die ein erstklassiges Ingenieurteam entwerfen würde, wenn es tiefes Wissen über das bestehende System mit der Freiheit kombiniert, das neue System konsequent richtig zu gestalten.

Das Geschäft verstehen – und mitdenken

Technische Exzellenz allein genügt nicht. Die dritte Fähigkeit, die itestra auszeichnet, ist die Kompetenz, auf Produkt- und Serviceebene mitzudenken – getragen von tiefem Branchenwissen.

In Transformationsprojekten taucht regelmäßig eine strategische Frage auf, die die interne IT nicht allein beantworten kann: Was soll dieses System in fünf Jahren leisten, wenn wir die Branchenentwicklung bedenken? Welche Funktionen werden uns differenzieren? Welche Prozesse sollen wir automatisieren, welche soll die Fachabteilung selbst konfigurieren können, und wo brauchen wir bewusst Spielraum?

Das sind keine reinen IT-Fragen. Nur wer technische Tiefe und Branchenkenntnis verbindet, kann sie gut beantworten. itestras Senior-Berater bringen beides mit. Sie haben über 20 Jahre lang Projekte in der Versicherungsbranche begleitet, Banken und Finanzdienstleister beraten, Fertigungsunternehmen unterstützt sowie Energie- und Wasserversorger und Behörden bei der Transformation ihrer Systeme begleitet. Dadurch können sie auf Augenhöhe mit Leitern der Schadenbearbeitung, Chief Actuaries oder Leitern des Firmenkundengeschäfts sprechen – nicht als reiner Technologiedienstleister, der eine Spezifikation umsetzt, sondern als strategischer Partner, der hilft, die richtige Spezifikation zu formen.

Das hat Gewicht, denn Transformationsprojekte sind seltene Chancen. Unternehmen ersetzen ein Kernsystem im Schnitt alle 15 bis 20 Jahre. Die Architekturentscheidungen, die dabei fallen, werden alles Weitere ermöglichen oder einschränken. Die Strategie richtig zu bestimmen – abgestimmt auf die Entwicklung von Unternehmen und Branche – ist ebenso wichtig wie die technische Umsetzung.

Re-Engineering statt Neuerfindung

Die vierte Fähigkeit ist vielleicht die praktischste: strukturiertes Reverse Engineering bestehender Funktionalität, kombiniert mit einer hocheffizienten Erhebung neuer Anforderungen.

Der konventionelle Ansatz für ein Transformationsprojekt beginnt mit einer Anforderungsphase: Die Fachabteilung dokumentiert, was das bestehende System leistet, Stakeholder nehmen ab, und das Entwicklungsteam baut nach Spezifikation. Dieser Weg ist langsam, teuer und fehleranfällig. Fachabteilungen können selten die vollständige Komplexität eines Systems beschreiben – nicht weil ihnen die Kompetenz fehlt, sondern weil viel dieser Komplexität implizit ist und in Abläufen sowie Sonderfallbehandlungen steckt, über die seit Jahren niemand mehr bewusst nachgedacht hat.

itestra kehrt diesen Ansatz um. Das bestehende System dient als primäre Quelle für Anforderungen. itestras Teams holen die funktionale Spezifikation direkt aus dem Code – sie analysieren, welche Daten verarbeitet werden, welche Regeln greifen und welche Ausgaben unter welchen Bedingungen entstehen. Das ist keine rein automatische Analyse. Es braucht Analysten, die sowohl die technische Struktur des Codes als auch die Geschäftsdomäne verstehen: Menschen, die einen COBOL-Batchjob lesen und erkennen, dass eine bestimmte Berechnung eine regulatorische Risikokorrektur ist, die die Fachabteilung längst vergessen hat.

Diese Extraktionsarbeit verbinden wir mit einer gezielten, hocheffizienten Erhebung neuer Anforderungen. itestras Generalisten – Ingenieure mit tiefem Domänenwissen – stellen statt monatelanger Workshops schnell die richtigen Fragen, weil sie die Rahmenbedingungen und Möglichkeiten bereits kennen. Sie erkennen, welche Änderungen technisch unkompliziert sind und welche versteckte Komplexität bergen. Sie präsentieren Optionen mit ehrlichen Abwägungen, anstatt darauf zu warten, dass die Fachabteilung etwas spezifiziert, das sich später als technisch nicht tragfähig erweist.

Das Ergebnis: Transformationsprojekte starten schneller, verlaufen verlässlicher und liefern Systeme, die wirklich vollständig sind – ohne dass die Fachabteilung zuerst Expertin für die eigene Systemlogik werden muss.

Agentische KI: Schneller, aber nicht grundlegend anders

Jede Phase dieser Methode profitiert heute vom Einsatz agentischer KI. Code-Analysen, für die früher Wochen manueller Arbeit nötig waren, lassen sich nun durch KI-Agenten unterstützen, die Programmverhalten zusammenfassen, Datenflüsse kartieren und strukturelle Anomalien im großen Maßstab erkennen. Dokumentationserstellung, Testabdeckungsanalyse und Architekturvisualisierung sind erheblich schneller geworden.

itestra nutzt diese Möglichkeiten aktiv. Die Folge sind kürzere Projektlaufzeiten, frühere Erkenntnisse über Systemkomplexität und schnellere Rückkopplungsschleifen zwischen Analyse und Entwurf.

Was agentische KI nicht verändert, ist die Notwendigkeit der Methode selbst. Ein KI-Agent kann zusammenfassen, was ein COBOL-Programm tut. Er kann nicht beurteilen, ob dieses Verhalten eine regulatorische Vorgabe erfüllt, einen Wettbewerbsvorteil darstellt oder eine 15 Jahre alte Übergangslösung ist, die längst eliminiert werden sollte. Er kann keine Architektur entwerfen, die technische Realitäten und Unternehmensstrategie gleichermaßen berücksichtigt. Und er kann nicht das Gespräch mit einem Chief Actuary führen und aus vagen strategischen Vorgaben eine baubare Systemspezifikation ableiten. Dafür bleiben die Methode – und die Menschen, die sie tragen – der unverzichtbare Kern.

Der richtige Einstieg

Der richtige Ausgangspunkt für eine Software Transformation ist kein Projektplan – es ist Klarheit. Klarheit darüber, was im bestehenden System wirklich steckt, wie eine zukunftsfähige Architektur aussehen könnte und welcher Transformationspfad angesichts der unternehmerischen Rahmenbedingungen realistisch ist.

itestras Software Transformation Health Check liefert genau das – in ein bis zwei Wochen. Automatisierte Code-Analyse und Experten-Review ergeben ein konkretes Bild der Komplexität des bestehenden Systems, eine erste Architekturempfehlung und eine ehrliche Einschätzung der Transformationsoptionen – inklusive Zeitrahmen und Kostenspannen für jeden Pfad.

Es ist ein klar abgegrenztes Engagement mit festem Scope, das die Grundlage für alle weiteren Entscheidungen schafft. Für Unternehmen, die seit Jahren zwischen Eigenentwicklung und Produktkauf abwägen, ohne zu einem tragfähigen Ergebnis zu kommen, verändert es die Diskussion nachhaltig.

Mit mehr als 20 Jahren Erfahrung, über 90 Unternehmenskunden und mehr als 200.000 Personentagen in der Software Transformation bringt itestra die Tiefe mit, um diese Diskussion produktiv zu gestalten – und die Erfolgsbilanz, um es zu belegen.