Legacy-Software modernisieren — Geschäftslogik erhalten

Warum Legacy-Systeme nicht einfach ersetzt werden können

Wenn Sie mit Ihrer Software an einen Punkt kommen, an dem etwas geändert werden muss, liegt der erste Gedanke nahe: Wir bauen das Ganze einfach neu. Moderner, sauberer, zukunftssicher. Klingt vernünftig. In der Praxis scheitern solche Projekte aber erschreckend oft.

Der Grund ist simpel: Ihre bestehende Software weiß Dinge, die niemand sonst weiß. In ihr stecken Regeln, Ausnahmen, Sonderfälle und Berechnungen, die über Jahre hinweg entstanden sind. Vieles davon hat nie jemand aufgeschrieben. Es existiert nur im Code — und manchmal nicht einmal dort offensichtlich.

Ein Beispiel: Ein Handelsunternehmen hat eine Warenwirtschaft, die seit 15 Jahren läuft. Darin stecken Preisregeln für unterschiedliche Kundengruppen, Sonderkonditionen für bestimmte Bestellmengen, Rabattstaffeln, die sich nach Jahreszeit ändern. Der damalige Entwickler hat das alles eingebaut, weil die Fachabteilung es über die Jahre so angefordert hat. Dokumentiert ist davon vielleicht die Hälfte.

Wenn Sie jetzt ein neues System bauen lassen, muss der neue Entwickler all das erst wieder herausfinden. Er muss verstehen, warum bestimmte Berechnungen so laufen, wie sie laufen. Und er muss sicherstellen, dass im neuen System nichts fehlt. Das dauert Monate und kostet ein Vielfaches dessen, was eine gezielte Modernisierung kosten würde.

Das Risiko des Neuanfangs

Neuentwicklungen haben ein bekanntes Problem: Sie unterschätzen die Komplexität des Altsystems. Die erste Version sieht modern aus, kann aber weniger. Funktionen fehlen, Sonderfälle sind nicht abgebildet, und die Mitarbeiter kommen plötzlich nicht mehr durch ihren Arbeitsalltag.

Das heißt nicht, dass eine Neuentwicklung nie sinnvoll ist. Es heißt nur: Sie ist selten die erste Wahl. Und sie ist fast nie die schnellste Lösung — schon gar nicht, wenn gerade eine konkrete Frist läuft, etwa die Pflicht zur E-Rechnung oder das Ende eines Betriebssystem-Supports.

Deshalb lohnt es sich, zuerst zu prüfen, ob die bestehende Software modernisiert werden kann. Gezielt, mit klarem Scope, ohne alles auf den Kopf zu stellen.

Typische Auslöser für den Handlungsdruck

Die meisten Unternehmen kommen nicht von sich aus auf die Idee, ihre alte Software anzufassen. Es braucht einen konkreten Anlass. Hier sind die häufigsten:

• Schnittstellenänderung: Ein Zahlungsdienstleister, eine Bank oder ein Versandpartner stellt seine API um. Die alte Anbindung funktioniert ab einem Stichtag nicht mehr.
• Gesetzliche Anforderung: E-Rechnungspflicht, neue Datenschutzvorschriften, geänderte Meldepflichten — wenn die Software das nicht kann, haben Sie ein Problem.
• Betriebssystem-Ende: Windows Server 2012, alte Linux-Versionen, veraltete Datenbanken — irgendwann gibt es keine Sicherheitsupdates mehr.
• Neue Systeme anbinden: Ein neues ERP, ein CRM oder ein Online-Shop soll mit der bestehenden Software zusammenarbeiten.
• Entwickler nicht mehr erreichbar: Der ursprüngliche Entwickler ist in Rente, hat die Firma gewechselt oder existiert als Unternehmen nicht mehr.

Wenn einer dieser Punkte auf Sie zutrifft, sind Sie nicht allein. Und es gibt in den meisten Fällen einen Weg, der nicht „alles wegwerfen" heißt.

Geschäftslogik erhalten: Was in Jahren gewachsen ist

Der wichtigste Grund, bestehende Software nicht leichtfertig zu ersetzen, hat einen Namen: Geschäftslogik. Damit meinen wir alles, was Ihre Software über Ihr Geschäft weiß. Nicht die Oberfläche, nicht die Datenbank, nicht das Design — sondern die Regeln, nach denen Ihre Software arbeitet.

Geschäftslogik ist das, was passiert, wenn ein Kunde eine Bestellung aufgibt und das System automatisch den richtigen Preis berechnet, den Lagerbestand prüft, die Versandart wählt und die Rechnung erstellt. Es ist das, was passiert, wenn eine Sonderregel greift, die vor acht Jahren eingebaut wurde, weil ein Großkunde besondere Konditionen hat.

Warum Dokumentation fast nie ausreicht

In einer idealen Welt wäre all das dokumentiert. In der Realität ist es das selten. Selbst wenn es ein Pflichtenheft aus der Anfangszeit gibt, bildet es nur den Stand von damals ab. Die vielen kleinen Änderungen, Erweiterungen und Anpassungen, die seither dazugekommen sind, stehen nirgends.

Das ist kein Vorwurf — das ist normal. Software wächst mit dem Unternehmen. Jede neue Anforderung wird eingebaut, manchmal sauber, manchmal als Schnelllösung. Nach zehn oder fünfzehn Jahren steckt in dieser Software mehr Wissen über Ihre Geschäftsprozesse als in den Köpfen Ihrer Mitarbeiter.

Genau deshalb ist gezieltes Modernisieren oft klüger als ein Neuanfang. Sie erhalten, was funktioniert, und erneuern nur das, was veraltet ist. Mehr dazu, wie wir Geschäftslogik in bestehendem Code identifizieren und sichern, erfahren Sie auf unserer Seite Geschäftslogik erhalten.

Was passiert, wenn Geschäftslogik verloren geht

Wir haben Fälle gesehen, in denen Unternehmen ihre Software komplett neu bauen ließen und danach monatelang Probleme hatten. Rechnungen stimmten nicht, Bestellprozesse liefen falsch, Kunden bekamen die falschen Preise. Nicht weil die neue Software schlecht programmiert war, sondern weil Regeln fehlten, die nur im alten Code standen.

Das kostet nicht nur Geld, sondern auch Vertrauen — bei Kunden, bei Mitarbeitern, bei Geschäftspartnern. Es lässt sich vermeiden, wenn man den bestehenden Code als das behandelt, was er ist: eine Wissensquelle. Keine Altlast.

Geschäftslogik sichtbar machen

Der erste Schritt bei jeder Modernisierung ist deshalb: verstehen, was da ist. Wir lesen uns in den bestehenden Code ein, identifizieren die Geschäftslogik und dokumentieren sie. Erst wenn klar ist, was die Software tut und warum, kann man sinnvoll entscheiden, was modernisiert wird und was bleiben kann.

Das klingt aufwendig, und das ist es auch. Aber es ist um ein Vielfaches günstiger, als dieselben Regeln erst nach dem Go-Live eines neuen Systems mühsam zu rekonstruieren — nämlich dann, wenn etwas schiefgeht.

Containerisierung: Alten Code sicher weiterbetreiben

Nicht jede Modernisierung bedeutet, den Code anzufassen. Manchmal ist der dringendste Handlungsbedarf gar nicht die Software selbst, sondern die Umgebung, in der sie läuft. Das Betriebssystem ist veraltet. Die Datenbank bekommt keine Updates mehr. Der Server steht unter einem Schreibtisch und niemand will sich vorstellen, was passiert, wenn die Festplatte ausfällt.

In solchen Fällen gibt es einen Ansatz, der enorm wirkungsvoll ist: Containerisierung. Die Idee dahinter ist einfach. Die bestehende Software wird in eine abgeschirmte, kontrollierte Umgebung verpackt — einen Container. Dieser Container enthält alles, was die Software zum Laufen braucht: das richtige Betriebssystem, die richtigen Bibliotheken, die richtige Datenbank-Version.

Was das konkret bedeutet

Stellen Sie sich vor, Ihre Software braucht Windows Server 2012 und eine bestimmte Version einer Datenbank, die seit Jahren nicht mehr unterstützt wird. Auf einem modernen Server können Sie das nicht einfach installieren. Aber in einem Container schon.

Der Container läuft auf einem modernen, aktuellen System. Dieses System bekommt Sicherheitsupdates. Es wird überwacht. Es kann gesichert werden. Aber innerhalb des Containers sieht die alte Software genau die Umgebung, die sie braucht. Sie merkt keinen Unterschied.

Für Sie als Unternehmer heißt das: Die Software läuft weiter, wie sie soll. Aber das Risiko sinkt drastisch. Sie haben wieder eine Infrastruktur, die sich pflegen und sichern lässt. Und Sie gewinnen Zeit — Zeit, um in Ruhe zu entscheiden, was der nächste Schritt ist.

Containerisierung ist kein Allheilmittel

Ehrlich gesagt: Nicht jede Software lässt sich ohne Weiteres containerisieren. Manche Programme sind so eng mit einer bestimmten Hardware verzahnt, dass es nicht einfach geht. Andere haben Lizenzmodelle, die eine Virtualisierung ausschließen. Das muss man vorher prüfen.

Aber wenn es funktioniert — und das tut es in vielen Fällen — ist Containerisierung einer der schnellsten Wege, eine akute Gefahr zu entschärfen. Kein Komplett-Umbau, keine monatelange Entwicklung, keine Unterbrechung des Betriebs. Mehr zu diesem Ansatz finden Sie auf unserer Seite Containerisierung: Alten Code sicher weiterbetreiben.

Was danach kommt

Containerisierung ist oft der erste Schritt, nicht der letzte. Sie verschafft Ihnen eine stabile Basis. Auf dieser Basis können Sie dann entscheiden: Welche Funktionen müssen ergänzt werden? Welche Schnittstellen brauchen ein Update? Muss perspektivisch doch etwas neu gebaut werden — und wenn ja, was genau?

Diese Entscheidungen lassen sich in Ruhe treffen, wenn die Grundlage sicher steht. Und genau dafür ist Containerisierung gedacht: als Sofortmaßnahme, die den Druck nimmt, ohne vorschnelle Entscheidungen zu erzwingen.

Funktionen gezielt ergänzen statt komplett umbauen

Der häufigste Auslöser für den Griff zum Telefon ist nicht, dass die gesamte Software veraltet ist. Es ist eine konkrete Anforderung. Die Buchhaltung braucht E-Rechnungen im ZUGFeRD-Format. Der Zahlungsdienstleister hat eine neue API. Der Steuerberater will einen automatischen Datenexport. Das ERP soll Bestelldaten direkt übernehmen.

In all diesen Fällen geht es nicht darum, die komplette Software umzuschreiben. Es geht darum, eine bestimmte Funktion hinzuzufügen oder eine bestehende Funktion zu aktualisieren. Gezielt, mit minimalem Eingriff, ohne den Rest des Systems zu gefährden.

Warum gezieltes Ergänzen oft der bessere Weg ist

Jede Änderung an einer gewachsenen Software birgt das Risiko, etwas anderes kaputt zu machen. Das wissen Sie — deshalb fasst ja auch niemand die Software an. Aber dieses Risiko lässt sich beherrschen, wenn man weiß, was man tut.

Der Schlüssel liegt darin, den bestehenden Code zu verstehen, bevor man ihn ändert. Wo sitzt die Geschäftslogik? Wie sind die Datenflüsse? Welche Teile hängen voneinander ab? Wenn das klar ist, lässt sich eine neue Funktion an der richtigen Stelle einbauen — dort, wo die relevanten Daten ohnehin verarbeitet werden.

Typische Ergänzungen, die wir umsetzen

• E-Rechnung: Bestehende Rechnungsstellung um ZUGFeRD/XRechnung erweitern, damit Sie die gesetzlichen Anforderungen erfüllen.
• Neue Schnittstellen: API-Anbindungen für Zahlungsdienstleister, Versandpartner, Buchhaltungssoftware oder ERP-Systeme.
• Datenexport und -import: Automatisierter Datenaustausch zwischen Ihrer Software und anderen Systemen.
• Sicherheits-Updates: Veraltete Verschlüsselungsmethoden, unsichere Authentifizierung oder offene Schwachstellen beheben.
• Benutzeroberfläche: Einzelne Bereiche der Oberfläche modernisieren, ohne die gesamte Software umzugestalten.

All das lässt sich in vielen Fällen direkt in der bestehenden Software umsetzen. Ohne Komplettumbau. Ohne ungewollte Seiteneffekte. Ohne monatelange Projekte.

Was dabei schiefgehen kann — und wie man es vermeidet

Das größte Risiko bei Ergänzungen in alter Software ist, dass man die Wechselwirkungen unterschätzt. Eine neue Funktion, die isoliert betrachtet simpel aussieht, kann in der Praxis Dutzende andere Stellen im Code berühren.

Deshalb ist die Analyse-Phase entscheidend. Bevor wir eine Zeile Code schreiben, verstehen wir, was die bestehende Software tut. Wir testen Änderungen in einer separaten Umgebung. Und wir liefern nicht einfach Code ab, sondern stellen sicher, dass im Tagesgeschäft alles weiterläuft wie gewohnt.

Manchmal stellen wir dabei fest, dass eine Ergänzung doch aufwendiger wäre als gedacht — etwa weil der bestehende Code an der betroffenen Stelle so verwoben ist, dass ein gezielter Eingriff nicht möglich ist. In solchen Fällen sagen wir das. Ehrlich. Und dann überlegen wir gemeinsam, welche Alternative es gibt.

Code verstehen und portieren mit KI-Unterstützung

Einer der schwierigsten Teile bei der Arbeit mit Legacy-Software ist das Einlesen in fremden Code. Software, die vor 10 oder 15 Jahren geschrieben wurde, folgt anderen Konventionen. Manchmal gibt es keine Kommentare, keine Dokumentation, keine Ansprechpartner. Der Code ist die einzige Wahrheit — und er spricht nicht immer eine klare Sprache.

Das ist unsere Kernkompetenz: Wir arbeiten uns in fremden Code ein. Wir verstehen die Architektur, identifizieren die Geschäftslogik und finden heraus, welche Teile kritisch sind und welche nicht. Darauf aufbauend können wir gezielt portieren — also Code in eine neuere Sprache oder Umgebung überführen, ohne die Funktionalität zu verlieren.

Wie KI dabei hilft — und wo nicht

Moderne KI-Werkzeuge haben die Arbeit mit Legacy-Code grundlegend verändert. Sie können große Mengen Code analysieren, Zusammenhänge erkennen und sogar Übersetzungen von einer Programmiersprache in eine andere vorschlagen. Was früher Wochen gedauert hat, geht heute in Tagen.

Aber — und das ist wichtig — KI allein reicht nicht. Ein KI-Werkzeug kann Code übersetzen, aber es versteht nicht, warum eine bestimmte Berechnung so läuft, wie sie läuft. Es erkennt nicht, dass eine scheinbar überflüssige Zeile einen Sonderfall abfängt, der nur einmal im Jahr auftritt. Es weiß nicht, dass eine bestimmte Reihenfolge in der Verarbeitung aus einem guten Grund existiert.

Deshalb arbeiten wir mit KI als Werkzeug, nicht als Ersatz. Die KI beschleunigt die Analyse und die Übersetzung. Aber jede Zeile wird von einem Menschen geprüft, der versteht, was die Software im Geschäftskontext tun soll. Mehr über diesen Ansatz erfahren Sie auf unserer Seite Code verstehen und portieren.

Portierung: Wann und warum

Portierung bedeutet, bestehenden Code in eine andere technische Umgebung zu übertragen. Das kann nötig sein, wenn die Programmiersprache veraltet ist, wenn keine Entwickler mehr dafür zu finden sind, oder wenn die Zielplattform gewechselt werden soll.

Ein typisches Beispiel: Eine Software ist in Visual Basic 6 geschrieben. Diese Sprache wird seit über 20 Jahren nicht mehr weiterentwickelt. Entwickler, die VB6 noch beherrschen, werden immer seltener. Gleichzeitig funktioniert die Software einwandfrei — die Geschäftslogik stimmt, die Prozesse laufen.

In so einem Fall kann eine Portierung nach C# oder eine andere moderne Sprache sinnvoll sein. Die Geschäftslogik wird übernommen, die technische Basis wird erneuert. Das Ergebnis ist eine Software, die genauso funktioniert wie vorher, aber auf einer Plattform läuft, die gepflegt werden kann.

Auch hier gibt es Grenzen. Manche Software ist so eng mit einer bestimmten Laufzeitumgebung verzahnt, dass eine Portierung aufwendiger wäre als eine kontrollierte Neuentwicklung auf Basis der dokumentierten Geschäftslogik. Das prüfen wir im Vorfeld und sagen Ihnen offen, welcher Weg für Ihre Situation der richtige ist.

Wie wir KI grundsätzlich bei bestehenden Projekten einsetzen und welche Fehler dabei typisch sind, beschreiben wir im Bereich Vibe-Coding — KI-gestützte Entwicklung.

Wann Modernisierung sinnvoller ist als Neuentwicklung

Nicht jede alte Software lässt sich modernisieren. Und nicht jede Neuentwicklung ist falsch. Die Kunst liegt darin, die richtige Entscheidung für die konkrete Situation zu treffen. Dafür braucht es keine Bauchgefühle, sondern eine gründliche Analyse.

Hier sind die Kriterien, an denen wir uns orientieren:

Entscheidungsbaum: Modernisieren oder neu bauen?

Frage 1: Funktioniert die Software grundsätzlich?

Wenn die Software das tut, was sie soll — wenn die Geschäftsprozesse abgebildet sind, die Berechnungen stimmen, die Daten korrekt sind — dann ist die Basis da. Das spricht für Modernisierung.

Frage 2: Lässt sich der Code lesen und verstehen?

Auch wenn es dauert: Wenn der Code grundsätzlich verständlich ist, kann man damit arbeiten. Wenn er so obfuskiert oder fragmentiert ist, dass selbst nach intensiver Analyse niemand mehr durchblickt, wird es schwierig.

Frage 3: Gibt es einen konkreten Anlass oder soll alles anders werden?

Wenn es um eine konkrete Anforderung geht — eine Schnittstelle, ein Exportformat, eine gesetzliche Pflicht — ist gezielte Modernisierung fast immer der schnellere und günstigere Weg. Wenn das gesamte Geschäftsmodell sich geändert hat und die Software grundsätzlich nicht mehr passt, kann ein Neuanfang sinnvoll sein.

Frage 4: Wie groß ist der Zeitdruck?

Neuentwicklung braucht Monate, manchmal Jahre. Wenn Sie in sechs Wochen eine E-Rechnung senden müssen, ist Modernisierung die einzige realistische Option.

Frage 5: Wie hoch ist das Budget?

Eine Neuentwicklung kostet ein Vielfaches einer gezielten Modernisierung. Nicht weil die neue Software teurer programmiert wird, sondern weil sie alles von Grund auf neu aufbauen muss — einschließlich der gesamten Geschäftslogik, die in der alten Software schon existiert.

Typische Legacy-Szenarien und Lösungswege

Damit das Ganze greifbar wird, hier einige Szenarien, wie wir sie regelmäßig sehen:

1. Szenario: Server-Betriebssystem am Ende. Die Software läuft auf Windows Server 2012 R2. Support ist ausgelaufen. Lösung: Containerisierung. Die Software läuft im Container auf einem modernen Host-System weiter. Zeitaufwand: Tage bis wenige Wochen.
2. Szenario: Zahlungsdienstleister stellt API um. Die bestehende Schnittstelle funktioniert ab dem Stichtag nicht mehr. Lösung: Neue API-Anbindung direkt in der bestehenden Software implementieren. Zeitaufwand: abhängig von der Komplexität, typisch zwei bis sechs Wochen.
3. Szenario: E-Rechnungspflicht. Die Software erzeugt Rechnungen als PDF, aber kein strukturiertes Format. Lösung: ZUGFeRD-/XRechnungs-Export in die bestehende Rechnungsstellung einbauen. Zeitaufwand: drei bis acht Wochen.
4. Szenario: ERP-Anbindung. Ein neues ERP soll Daten aus der alten Software beziehen. Lösung: Schnittstelle (REST-API oder Datenexport) in der bestehenden Software ergänzen. Zeitaufwand: vier bis zehn Wochen.
5. Szenario: Programmiersprache veraltet. Die Software ist in einer Sprache geschrieben, für die es keine Entwickler mehr gibt. Lösung: Geschäftslogik analysieren, dokumentieren und in eine moderne Sprache portieren. Zeitaufwand: abhängig vom Umfang, typisch mehrere Monate.

Wann wir von Modernisierung abraten

Wir sagen es direkt: Es gibt Fälle, in denen Modernisierung keinen Sinn ergibt. Wenn die Software auf einer Technologie basiert, für die es keine Laufzeitumgebung mehr gibt. Wenn der Code so verändert wurde, dass die Architektur nicht mehr nachvollziehbar ist. Oder wenn die Geschäftsprozesse sich so grundlegend gewandelt haben, dass die alte Software einfach nicht mehr passt.

In solchen Fällen sagen wir das. Und wenn eine Neuentwicklung der bessere Weg ist, dann helfen wir dabei, die Geschäftslogik aus dem alten System zu extrahieren, damit der Neuanfang auf einer soliden Basis steht — nicht auf Vermutungen.

Denn selbst wenn am Ende ein neues System entsteht: Das Wissen aus der alten Software ist zu wertvoll, um es zu ignorieren.

Die größte Gefahr: Nichts tun

In unserer Erfahrung ist die größte Gefahr nicht die falsche Entscheidung zwischen Modernisieren und Neubauen. Die größte Gefahr ist, gar nicht zu entscheiden. Abzuwarten, bis der Zahlungsdienstleister die alte Schnittstelle abschaltet. Bis das Betriebssystem so veraltet ist, dass es ein Sicherheitsrisiko wird. Bis ein Mitarbeiter in Rente geht, der als Einziger noch weiß, wie man die Software bedient.

Je länger Sie warten, desto weniger Optionen haben Sie. Eine kontrollierte Modernisierung heute gibt Ihnen Handlungsspielraum für morgen.