Delphi ist tot, das hört man seit Jahren. Und dennoch laufen in unzähligen deutschen Unternehmen täglich geschäftskritische Prozesse auf Software, die in Delphi oder Object Pascal geschrieben wurde. Lagerverwaltung, Kundendatenbanken, Abrechnungssysteme, Produktionssteuerung. Oft seit Jahrzehnten zuverlässig im Einsatz, oft schlecht dokumentiert, und fast immer nicht mehr wartbar durch die aktuelle IT-Generation.

Als jemand, der seit 2009 mit Delphi arbeitet und inzwischen über 17 Jahre Erfahrung mit genau diesen Systemen hat, erlebe ich regelmäßig, welche Entscheidungen Unternehmen vor dieser Frage treffen und welche sich langfristig als richtig erwiesen haben. Dieser Artikel fasst zusammen, woran Sie den Handlungsbedarf erkennen, welche Wege es bei einem Legacy-System gibt und woran eine Modernisierung in der Praxis am häufigsten scheitert.

Warum Delphi noch immer läuft

Delphi-Anwendungen sind in der Regel robust, schnell und präzise auf spezifische Geschäftsprozesse zugeschnitten. Sie laufen seit Jahren stabil, und genau das ist das Problem. Weil sie funktionieren, wird die Frage nach einer Modernisierung immer wieder aufgeschoben. Bis der Entwickler, der das System kennt, in Rente geht. Bis Windows eine inkompatible Version veröffentlicht. Bis eine kritische Sicherheitslücke auftaucht oder ein Kunde eine Schnittstelle verlangt, die das Altsystem nicht liefern kann.

Der Handlungsbedarf entsteht selten geplant. Er entsteht unter Druck, und dann fehlt die Zeit für eine saubere Entscheidung. Wer die Frage früher stellt, hat mehr Optionen und zahlt weniger.

Woran Sie erkennen, dass es eng wird

Es gibt einige Warnzeichen, die in der Praxis fast immer gemeinsam auftreten. Das erste ist personeller Natur: Wenn nur noch eine einzige Person die Codebasis versteht und diese Person das Unternehmen in absehbarer Zeit verlässt, ist das Risiko unabhängig vom technischen Zustand bereits hoch.

Das zweite Zeichen ist die verwendete Delphi-Version. Wer noch auf Delphi 7 oder einer anderen Fassung aus der Zeit vor der Unicode-Umstellung arbeitet, sitzt auf einer Codebasis, die sich nicht ohne Weiteres auf aktuelle RAD-Studio-Versionen heben lässt. Komponenten von Drittanbietern, die es längst nicht mehr gibt, verschärfen das. Jede Erweiterung wird dann teurer als die vorherige.

Das dritte Zeichen ist funktional. Sobald Anforderungen auftauchen, die das Altsystem grundsätzlich nicht erfüllen kann, etwa der Zugriff über den Browser, eine Anbindung an Cloud-Dienste oder mandantenfähige Strukturen, hilft auch die beste Pflege nicht weiter. Dann geht es nicht mehr um Wartung, sondern um Architektur.

Drei Szenarien, drei verschiedene Empfehlungen

Die Software funktioniert und soll erweitert werden

Wenn das bestehende System stabil läuft und lediglich neue Funktionen benötigt, ist die schrittweise Weiterentwicklung in Delphi oft die wirtschaftlichste Entscheidung. Voraussetzung ist, dass es einen Entwickler gibt, der das System kennt und die Codebasis beherrscht. Eine vollständige Neuentwicklung wäre in diesem Fall überdimensioniert und riskant, denn jahrelang angesammeltes Prozesswissen steckt in altem Code, der auf den ersten Blick unverständlich wirkt.

Sinnvoll ist in dieser Lage meist eine Umstellung auf eine aktuelle RAD-Studio-Version, verbunden mit der Unicode-Bereinigung und dem Ersatz nicht mehr gepflegter Komponenten. Das ist keine Modernisierung im großen Stil, verlängert die Lebensdauer des Systems aber oft um Jahre und schafft die Grundlage für alles Weitere.

Die Software soll in neue Systeme integriert werden

Wenn eine Delphi-Anwendung mit modernen Cloud-Diensten, REST-Schnittstellen oder anderen Systemen kommunizieren soll, ist die Erweiterung um Schnittstellen der pragmatische erste Schritt. Delphi kann REST-Schnittstellen ansprechen und selbst bereitstellen, das ermöglicht eine schrittweise Integration ohne vollständige Neuentwicklung. Ich habe diesen Ansatz mehrfach umgesetzt: Die Altanwendung bleibt das Herzstück, erhält aber moderne Anbindungen und wird damit wieder anschlussfähig.

Der Vorteil liegt im Risiko. Sie verändern den funktionierenden Kern nicht, sondern bauen daneben. Geht etwas schief, betrifft es die neue Schnittstelle und nicht die Abrechnung, die morgen früh laufen muss.

Die Software ist nicht mehr wartbar oder skalierbar

Wenn die Codebasis so gewachsen ist, dass neue Entwickler sich nicht mehr zurechtfinden, wenn grundlegende Architekturentscheidungen jeder Weiterentwicklung im Weg stehen oder wenn die Plattformabhängigkeit zum Sicherheitsrisiko wird, ist die Ablösung durch eine Migration auf .NET und C# die richtige Entscheidung. Der Schlüssel liegt in einer sorgfältigen Anforderungsanalyse. Was tut das System wirklich? Nicht was die Dokumentation sagt, sondern was der Code tatsächlich macht.

Der Zwischenweg, den die meisten unterschätzen

In der Praxis ist die Entscheidung selten so eindeutig wie in den drei Szenarien oben. Der Weg, der bei größeren Systemen am zuverlässigsten funktioniert, ist die schrittweise Ablösung. Neue Funktionen entstehen dabei als eigenständige Module in einer modernen Technologie, während der Delphi-Kern unverändert weiterläuft. Über eine gemeinsame Datenbank oder definierte Schnittstellen arbeiten alte und neue Teile zusammen. Nach und nach wandert Verantwortung vom Altsystem in die neuen Module, bis der verbleibende Rest klein genug ist, um ihn gefahrlos abzuschalten.

Dieses Vorgehen ist in der Legacy-Modernisierung gut erprobt. Der Aufwand verteilt sich über einen längeren Zeitraum, das Unternehmen bleibt durchgehend arbeitsfähig, und jeder Schritt lässt sich einzeln bewerten. Vor allem aber vermeiden Sie den Zustand, den ich am häufigsten sehe: Zwei Systeme laufen parallel, das neue ist nie ganz fertig, das alte wird nie abgeschaltet, und die Kosten laufen doppelt.

Was eine Migration kostet und was sie bringt

Eine vollständige Migration ist kein Wochenendprojekt. Je nach Komplexität der Anwendung rechne ich mit mehreren Monaten bis zu einem Jahr Entwicklungszeit. Dafür erhält das Unternehmen eine Anwendung, die wartbar ist, die von jedem C#-Entwickler verstanden werden kann, die moderne Schnittstellen unterstützt und die langfristig auf einer gesicherten Plattform steht.

Zur ehrlichen Rechnung gehört aber auch die Gegenseite. Ein stabil laufendes Altsystem verursacht laufend geringe Kosten, eine Migration verursacht einmalig hohe. Wer nur die Entwicklungskosten betrachtet, kommt fast immer zu dem Schluss, dass sich das nicht lohnt. Sinnvoll wird die Rechnung erst, wenn Sie das Risiko mit einpreisen: Was kostet es, wenn das System zwei Tage stillsteht und niemand es reparieren kann? Was kostet der Auftrag, den Sie nicht annehmen können, weil eine Schnittstelle fehlt?

Die häufigsten Fehler

Der häufigste Fehler ist, eine Neuentwicklung zu beauftragen, ohne die Altanwendung wirklich verstanden zu haben. Das Ergebnis ist eine neue Oberfläche mit denselben logischen Fehlern darunter, dazu all die Sonderfälle, die im alten Code über Jahre eingebaut wurden und die niemand dokumentiert hat. Eine gründliche Analyse vor der Entwicklung ist keine Zusatzleistung, sie ist Voraussetzung für den Erfolg.

Der zweite Fehler ist die Annahme, eine Migration sei eine reine Übersetzungsaufgabe. Werkzeuge, die Delphi-Code automatisch nach C# überführen, erzeugen technisch lauffähigen, aber strukturell schlechten Code. Sie haben danach ein Altsystem in einer neuen Sprache und nichts gewonnen.

Der dritte Fehler betrifft die Reihenfolge. Wer zuerst die Oberfläche modernisiert, weil sie am sichtbarsten ist, verschiebt die eigentliche Arbeit nach hinten. Die Geschäftslogik ist der schwierige Teil, und sie sollte zuerst durchdrungen werden.

Was Sie vor der Entscheidung klären sollten

Bevor überhaupt über Technik gesprochen wird, sollten drei Dinge geklärt sein. Erstens: Wie lange soll das System noch laufen? Bei einer Restlaufzeit von drei Jahren ist eine Migration selten sinnvoll, bei fünfzehn Jahren fast immer. Zweitens: Wer wird es künftig warten, und mit welchen Technologien arbeitet diese Person? Drittens: Welche Anforderungen sind absehbar? Ein System, das in zwei Jahren ohnehin mandantenfähig werden muss, sollte nicht vorher noch aufwendig in seiner alten Architektur erweitert werden.

Diese drei Antworten entscheiden mehr über den richtigen Weg als jede technische Bewertung der Codebasis.

Meine Empfehlung

Wenn Sie eine Delphi-Anwendung betreiben und sich fragen, ob es Zeit für eine Modernisierung ist, dann lassen Sie zuerst eine ehrliche Bestandsaufnahme durchführen. Sie brauchen dafür keine wochenlange Analyse, aber Sie brauchen jemanden, der den Code lesen kann und kein Interesse daran hat, Ihnen das größtmögliche Projekt zu verkaufen.

Ich mache das seit über 17 Jahren und sage Ihnen, was das System wirklich braucht. Manchmal ist das eine Migration. Häufiger ist es eine Umstellung auf eine aktuelle Delphi-Version, ein paar saubere Schnittstellen und ein Plan für die nächsten Jahre.