Wann ist es Zeit zu modernisieren? Warnsignale, dass Ihr Legacy-System Geld kostet

Legacy-Systeme fallen selten so aus, dass eine Entscheidung erzwungen wird. Meist laufen sie. Sie bedienen Kunden, erwirtschaften Umsatz und stehen jahrelang als Beleg dafür, dass das Unternehmen etwas Wertvolles gebaut hat. Genau deshalb lässt sich der Moment, in dem ein solches System vom Vermögenswert zur Belastung wird, so leicht übersehen. Es gibt keinen Ausfall, der zur Reaktion zwingt, sondern nur ein langsames Anwachsen der Kosten, verteilt über so viele Monate, dass niemand die Kurve sieht.

Die Frage, ob es Zeit zu modernisieren ist, wird deshalb typischerweise ein Jahr zu spät gestellt, nach einer Reihe von Signalen, die im jeweiligen Moment wie Einzelprobleme aussahen. Der folgende Beitrag beschreibt diese Signale: worauf konkret zu achten ist, wie sich natürliches Altern von einer echten Wachstumsbremse unterscheiden lässt und wie sich die Entscheidung auf Belege statt auf Bauchgefühl stützen lässt. Dazu ein Wort dazu, warum die Antwort fast nie in einer vollständigen Neuentwicklung liegt.

Signal eins: Die Kosten pro Funktion steigen, das Team schrumpft aber nicht

Das ist der verlässlichste Einzelindikator. Wenn eine Funktion, die vor drei Jahren zwei Wochen brauchte, heute sechs braucht und das Team gleich groß oder größer ist, erhebt das System eine Steuer auf jede Änderung. In einem von Altimi modernisierten System, einer Plattform für Qualitätsmanagement auf einem Stack aus dem Jahr 2016, waren die Kosten für die Auslieferung einer Funktion auf das Fünffache des Ausgangswerts gestiegen.

Dieses Signal ist tückisch, weil Organisationen es gern wegerklären. Das Produkt sei inzwischen reifer, die Anforderungen komplexer, Regressionen erforderten mehr Sorgfalt. All das kann zutreffen, und nichts davon erklärt einen Faktor von fünf. Es lohnt sich, direkt zu messen: die durchschnittliche Zeit von der Entscheidung für eine Funktion bis zu ihrer Produktivsetzung, im Jahresvergleich. Steigt die Kurve bei konstanter Teamgröße, ist das keine Frage der Produktreife, sondern der Architektur.

Signal zwei: Das Team meidet bestimmte Bereiche des Codes

Jedes Engineering-Team, das an einem älteren System arbeitet, führt eine Liste von Stellen, die niemand anfasst. Manchmal ist sie schriftlich festgehalten, häufiger überlebt sie als mündliche Überlieferung. Dieses Modul rührt man besser nicht an. Für jenen Bereich muss man eine bestimmte Person holen. Diese Integration funktioniert, und niemand weiß genau, warum.

Solange solche Bereiche wenige und randständig sind, ist das normal. Zum Problem wird es, wenn sie Funktionen erfassen, die für die Zukunft des Produkts zentral sind. Dann wird die Roadmap nicht mehr davon geprägt, was Kunden brauchen, sondern davon, was sich sicher anfassen lässt. Das ist einer der teuersten Mechanismen in Produktunternehmen, weil er lautlos wirkt: Niemand meldet, dass etwas unmöglich ist, diese Ideen erreichen einfach das Backlog nicht mehr.

Signal drei: Systemwissen liegt bei einer oder zwei Personen

Wenn jede Frage zu einem kritischen Modul stets zur selben Person führt, trägt das Unternehmen ein Kontinuitätsrisiko, das keine Codequalität ausgleicht. Dieses Risiko tritt selten allmählich ein. Es tritt an dem Tag ein, an dem diese Person kündigt oder längerfristig ausfällt.

Auch die Zwischenform dieses Signals verdient Beachtung: Die Einarbeitung neuer Entwickler dauert Monate statt Wochen. Braucht eine erfahrene Fachkraft ein Quartal, bis sie eigenständig Änderungen vornehmen kann, ist das keine Kompetenzfrage, sondern ein System, das sich ohne Führung nicht erschließt. Für Einstellungspläne bedeutet es, dass jede zusätzliche Stelle deutlich später Wert liefert als im Modell unterstellt.

Signal vier: Die Technologie nähert sich dem Supportende

Dieses Signal ist insofern einzigartig, als es ein Datum mitbringt. Eine Datenbank, ein Framework oder ein Betriebssystem, das aus dem Support fällt, verwandelt eine unbestimmte architektonische Sorge in eine harte Frist. Bei der genannten Qualitätsmanagement-Plattform war einer der Auslöser der Entscheidung das für 2027 geplante Supportende der eingesetzten Datenbankversion, was angesichts des Umfangs der Kundenmigration einen frühen Start der Arbeiten erforderte.

Supportende bedeutet keine Sicherheitsupdates, wachsende Schwierigkeiten bei der Personalsuche, Integrationsprobleme und zunehmend unangenehme Gespräche mit Konzernkunden, deren Sicherheitsabteilungen direkt nach Komponentenversionen fragen. Ein solches Datum behandelt man am besten als festen Punkt, von dem aus rückwärts geplant wird, und nicht als ferne Frist mit reichlich Zeit.

Signal fünf: Sicherheit und Compliance bremsen den Vertrieb

Sobald der Vertrieb Abschlüsse in der Phase des Sicherheitsfragebogens verliert, ist das ein eindeutiges Zeichen, dass technische Schulden keine interne Angelegenheit mehr sind. Dasselbe gilt für fehlende, von Kunden erwartete Zertifizierungen, Lücken in der Zugriffskontrolle, fehlende Nachvollziehbarkeit von Änderungen oder Schwierigkeiten beim Nachweis der DSGVO-Konformität.

Dieses Signal wirkt unmittelbar auf den Unternehmenswert und den adressierbaren Markt. Wenn die Architektur es unmöglich macht, jene Anforderungen zu erfüllen, die den Zugang zum wertvollsten Kundensegment bestimmen, ist Modernisierung kein technisches Projekt mehr, sondern eine Voraussetzung für den Vertriebsplan.

Signal sechs: Die Betriebskosten wachsen schneller als der Umsatz

Wenn die Infrastrukturrechnung proportional zur Kundenzahl oder schneller wächst, skaliert das Geschäftsmodell nicht so, wie der Plan unterstellt. Typische Ursachen sind fehlende elastische Skalierung, vorsorglich überdimensionierte Ressourcen, eine Architektur, die das Teilen von Kapazität zwischen Kunden verhindert, und Workarounds, die jahrelang bestehen bleiben, weil ihre Beseitigung eine zu große Änderung erfordert hätte.

Das lässt sich ausrechnen: Infrastruktur- und Wartungskosten als Anteil am Umsatz, im Zeitverlauf verfolgt. Ein steigender Anteil bei stabiler Produktmarge bedeutet, dass jede weitere Umsatzeinheit teurer zu bedienen ist als die vorherige.

Signal sieben: Neue technologische Möglichkeiten bleiben außer Reichweite

Das letzte Signal ist das jüngste und wird am häufigsten übersehen. Wenn ein Unternehmen künstliche Intelligenz im Produkt einsetzen möchte, die Daten aber über mehrere Speicher ohne einheitliches Modell verstreut sind, Pipelines fehlen und die Architektur neue Komponenten nicht ohne Eingriff in den Kern aufnimmt, ist das kein KI-Problem. Es ist ein Fundamentproblem.

Dieses Signal unterscheidet sich von den übrigen darin, dass es sich nicht in steigenden Kosten zeigt, sondern im Fehlen von Optionen. Das System arbeitet korrekt und nichts schmerzt, doch das Unternehmen kann nicht, was Wettbewerber bereits tun. In der Praxis heißt das: Modernisierung geht nicht mehr um Kostensenkung, sondern um den Erhalt der Marktposition.

Natürliches Altern von einer echten Bremse unterscheiden

Nicht jedes dieser Signale rechtfertigt ein Modernisierungsprogramm. Der praktische Maßstab lautet, ob das Problem etwas blockiert, das das Unternehmen in den nächsten zwei Jahren tatsächlich vorhat. Ein System mit unvollkommener Architektur, das einen unveränderten Prozess zuverlässig bedient, kann weiterlaufen. Dasselbe System wird zum Problem an dem Tag, an dem der Plan einen neuen Markt, Partnerintegrationen oder Kunden mit höheren Sicherheitsanforderungen vorsieht.

Hilfreich ist außerdem die Unterscheidung zwischen laufenden Kosten und Optionskosten. Steigende Lieferkosten und steigende Infrastrukturrechnungen sind laufende Kosten und in den Zahlen sichtbar. Entgangene Möglichkeiten, verlorene Abschlüsse und Ideen, die nie ins Backlog gelangten, sind Optionskosten, die in keinem Bericht auftauchen. Letztere sind oft größer, müssen aber bewusst gesucht werden.

Schließlich lohnt es sich, die Kosten des Aufschubs zu beziffern. Eine um ein Jahr verschobene Modernisierung kostet ein Jahr später selten dasselbe, weil in der Zwischenzeit weiterer Code auf den alten Annahmen entsteht und sich das Fenster vor dem Supportende der Komponenten verengt. Diese Frage wird in Führungsgremien am seltensten gestellt und ist häufig die wichtigste.

Warum die Antwort fast nie eine vollständige Neuentwicklung ist

Häufen sich die Signale, ist der erste Impuls, das System neu zu schreiben. Dieser Impuls ist nachvollziehbar und in den meisten Fällen falsch. Eine Neuentwicklung unterstellt, dass das Team das bestehende System gut genug versteht, um es nachzubilden, dass die Anforderungen über viele Quartale des Umbaus stillhalten und dass sich im verworfenen Code nichts Wichtiges verbirgt. In der Praxis kodiert das alte System jahrelange Sonderfälle, und die Neuentwicklung entdeckt sie mühsam erneut, ohne in dieser Zeit neuen Wert zu liefern.

Weit häufiger bewährt sich die schrittweise Modernisierung: beginnend bei den Modulen mit dem höchsten Risiko, mit Validierung der Annahmen am echten Code und Auslieferung in Phasen, sodass das Team durchgehend weiter ausliefert. Künstliche Intelligenz hat diese Rechnung zusätzlich verschoben, denn sie verkürzt genau jene Arbeit am stärksten, die schrittweise Modernisierung mühsam machte: Code-Verständnis, Abhängigkeitskartierung, Testerzeugung und wiederholbare Transformationen. Bei passend gewählten Aufgaben können KI-Werkzeuge den Engineering-Aufwand um 50 bis 80 Prozent senken, während ein Teil der Arbeit weiterhin das Urteil erfahrener Ingenieure verlangt, und diese Grenze muss für die konkrete Codebasis bestimmt und nicht vorab angenommen werden.

Die Entscheidung auf Belege stützen

Warnsignale sagen, dass ein genauerer Blick lohnt. Sie sagen nicht, was zu modernisieren ist, in welcher Reihenfolge oder zu welchen Kosten. Diese Antworten erfordern eine strukturierte Bewertung am echten Code und keinen Workshop am Whiteboard.

Das AI Refactoring Assessment von Altimi ist genau für diese Lage konzipiert und dauert vier Wochen. Es besteht aus zwei verbundenen Arbeitssträngen. Der erste ist die Bewertung von Architektur und technischen Schulden: die Feststellung, welche Teile des Systems Wachstum und Skalierbarkeit blockieren, mit quantifizierten Schulden, einer Bewertung der KI-Reife und einer Prüfung der Infrastrukturrisiken. Der zweite ist ein Technical Spike, eine praktische Validierung des risikoreichsten Teils der Codebasis am echten Produktionscode, die belastbare Daten zum Migrationsrisiko und zur tatsächlichen Wirkung von KI-Werkzeugen liefert, bevor Budget gebunden wird.

Das Ergebnis ist ein Entscheidungspaket für die Führungsebene: Executive Summary, Risikokarte, KI-gestützte Modernisierungs-Roadmap, priorisiertes Backlog der technischen Schulden, Erkenntnisse aus dem Spike und Hinweise zur AI-Governance, übergeben in einem abschließenden Readout-Workshop. Der Ablauf ist klar gegliedert: Woche eins Kick-off und Intake, Woche zwei die vertiefte Bewertung von Architektur und Abhängigkeiten, Woche drei der Technical Spike am Modul mit dem höchsten Risiko, Woche vier Synthese, Roadmap und Workshop.

Die Belastung des Kundenteams bleibt dabei gering, da die Arbeit im Lesezugriff auf die Repositories erfolgt, mit zwei bis drei strukturierten Sessions pro Woche mit Architekten oder Tech Leads. Ein Einfrieren der Roadmap ist nicht erforderlich, was ins Gewicht fällt, denn die erste Sorge der meisten Teams lautet genau, dass eine Bewertung die Auslieferung stoppt.

Der Wert einer solchen Bewertung hängt nicht davon ab, dass die Modernisierungsentscheidung bereits gefallen ist. Im Gegenteil, das ist der häufigste Ausgangspunkt: Eine Organisation sieht wachsende Schulden und versucht zu klären, ob, wann und in welchem Umfang investiert werden soll. Das Ergebnis beantwortet auch, was geschieht, wenn die Entscheidung aufgeschoben wird.

Der europäische Kontext

Für Unternehmen in Deutschland, Österreich und der Schweiz sowie in Mittel- und Osteuropa beschleunigt die regulatorische Dimension den Entscheidungszeitpunkt häufig. Die Einhaltung der DSGVO, Anforderungen aus Rahmenwerken wie ISO 27001 und die Erwartungen von Konzernkunden an Sicherheit und Nachvollziehbarkeit bestimmen faktisch den Zugang zu den wertvollsten Marktsegmenten. Ein System, das diese Anforderungen ohne tiefgreifenden Umbau nicht erfüllen kann, begrenzt den Vertrieb unabhängig von der Qualität des Produkts selbst.

Ebenso zählt, wo der Quellcode während einer KI-gestützten Bewertung verarbeitet wird. Die Zusammenarbeit mit einem in der EU ansässigen, nach ISO 27001 zertifizierten Partner hält sensiblen Code innerhalb des europäischen Datenschutzraums und dokumentiert den Einsatz von KI, was in Audits und Gesprächen mit Konzernkunden ebenso wiegen kann wie das technische Ergebnis.

Wann ist es Zeit zu modernisieren? Fazit

Ein Legacy-System sendet selten ein klares Signal. Es sendet mehrere schwache zugleich: steigende Kosten pro Funktion, Codebereiche, die das Team meidet, auf eine Person konzentriertes Wissen, das nahende Supportende von Komponenten, verlorene Sicherheitsfragebögen, Betriebskosten, die schneller wachsen als der Umsatz, und die Unfähigkeit, nach neuen Technologien zu greifen. Einzeln lässt sich jedes wegerklären. Zusammen bedeuten sie, dass das System den Unternehmensplan nicht mehr stützt, sondern begrenzt.

Die richtige Reaktion besteht weder darin, die Signale zu ignorieren, noch darin, sofort alles neu zu schreiben, sondern in einer strukturierten Bewertung, die sie in eine konkrete Antwort überführt: was zu modernisieren ist, in welcher Reihenfolge, zu welchen Kosten und was geschieht, wenn die Entscheidung wartet.

Wenn Ihnen mehrere dieser Signale bekannt vorkommen und Sie klären möchten, was daraus für Ihr System folgt, ist ein kurzes Gespräch darüber, was die Auslieferung derzeit blockiert, der schnellste Einstieg.