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 gibt, eine Delphi-Anwendung zu modernisieren, und woran solche Vorhaben in der Praxis am häufigsten scheitern. Weiter unten beantworte ich häufige Fragen, etwa ob Delphi überhaupt noch weiterentwickelt wird.

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.

Ein Teil dieses Drucks kommt derzeit von außen. Die E-Rechnungspflicht verlangt strukturierte Rechnungsdaten, während viele gewachsene Systeme Rechnungen nur als Druck oder PDF ausgeben. Und wer seine Software als Produkt am Markt anbietet, muss nach dem Cyber Resilience Act aktiv ausgenutzte Schwachstellen melden und künftig auch Sicherheitslücken per Update beheben können. Mit Komponenten, für die es keine Updates mehr gibt, gelingt das kaum.

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.

Unabhängig davon gibt es ein weiteres Zeichen, das den Datenschutz betrifft. Kann die Software personenbezogene Daten nicht fristgerecht löschen, etwa weil das Datenmodell gar kein Löschen vorsieht oder Kundendaten fest mit alten Belegen verknüpft sind, lassen sich Löschpflichten nur mit Handarbeit in der Datenbank oder gar nicht erfüllen. Wie Löschregeln in einer Anwendung aussehen können, beschreibe ich im Abschnitt zum Löschkonzept meines Beitrags über Datenschutz in der Softwareentwicklung.

Drei Szenarien für die Modernisierung einer Delphi-Anwendung

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.

Umstieg von Delphi 7 auf Delphi 13: Wo bei der Migration die Arbeit steckt

Wer eine alte Anwendung auf eine aktuelle Delphi-Version hebt, hat selten mit der Syntax zu kämpfen, denn Object Pascal ist nach meiner Erfahrung über die Jahre stabil geblieben. Die Arbeit steckt vor allem in vier Bereichen, und wie viel davon auf Sie zukommt, lässt sich vor dem Start eingrenzen.

Unicode-Umstellung

Mit Delphi 2009 hat sich die Bedeutung der Grundtypen für Zeichen und Zeichenketten geändert. Seitdem steht der Typ String für einen UnicodeString, vorher entsprach er einem AnsiString. Char wurde dabei zum zwei Byte breiten WideChar, PChar entsprechend zum PWideChar. Ein Whitepaper von Cary Jensen, das Embarcadero zur Unicode-Migration veröffentlicht hat, nennt als typische Stolperstellen unter anderem Zeigeroperationen auf Puffern, das Lesen und Schreiben externer Daten, externe Bibliotheken und Datenbankzugriffe. In meinen Projekten übersteht Oberflächencode die Umstellung oft ohne Änderung, Code rund um Dateiformate, DLL-Aufrufe und eigene Protokolle dagegen selten. Für eine erste Abschätzung bietet Embarcadero im Migration Center ein Werkzeug an, das im Quelltext unter anderem die Vorkommen von String, SizeOf, Read und Write zählt.

BDE durch FireDAC ersetzen

Wer noch über die Borland Database Engine (BDE) auf seine Daten zugreift, etwa auf Paradox- oder dBASE-Tabellen, sollte den Datenzugriff umstellen. Laut dem Migration Center von Embarcadero gilt die BDE seit 2002 als abgekündigt, fehlt seit Delphi XE8 im Installationsprogramm und unterstützt kein 64 Bit. Als Ersatz ist FireDAC vorgesehen. Bis zu 80 Prozent der Arbeit lassen sich nach Angabe des Herstellers mit dem Werkzeug reFind per Suchen und Ersetzen im Quelltext und in den Formulardateien erledigen. Selbst geschriebenes SQL und datenbankspezifische Funktionen können sich danach anders verhalten. Embarcadero rät, sie zu prüfen und die Anwendung unter realistischer Last auf Geschwindigkeit und gleichzeitige Zugriffe zu testen.

Umstieg auf 64 Bit

Seit Delphi XE2 lassen sich aus derselben Codebasis 32- und 64-Bit-Programme erzeugen. Unter 64 Bit sind Zeiger acht Byte groß. Ein Integer bleibt bei vier Byte, während der Typ NativeInt auf acht Byte mitwächst. Legt alter Code einen Zeiger in einer Integer-Variablen ab, wird die Adresse unter 64 Bit also auf vier Byte gekürzt. Solche Stellen müssen auf NativeInt umgestellt werden. Assembler-Code ist unter 64 Bit laut Embarcadero komplexer, weil es mehr Register und andere Aufrufkonventionen gibt. Dazu kommen fremde DLLs, denn ein 64-Bit-Prozess kann laut Microsoft keine 32-Bit-DLL laden. Gibt es keine 64-Bit-Fassung, muss die DLL ersetzt oder über einen eigenen 32-Bit-Prozess angebunden werden.

Komponenten von Drittanbietern

Bei einem Versionswechsel sind Komponenten von Drittanbietern laut dem Leitfaden von Embarcadero zu Drittkomponenten oft die größte Hürde. Für jede eingesetzte Bibliothek stellt sich die Frage, ob es eine Version für das aktuelle RAD Studio gibt, ob der Hersteller sie noch pflegt und ob der Quelltext vorliegt. Liegen nur kompilierte DCU-Dateien vor, lässt sich die Komponente nicht auf eine neue Compilerversion bringen. Liefert auch der Hersteller keine aktuelle Version mehr, muss sie ersetzt werden, manchmal durch Funktionen, die inzwischen in Delphi selbst enthalten sind. Bei meinen Umstellungen sind Berichtsgeneratoren und Rasterkomponenten meist am aufwendigsten. Ich empfehle, vor jeder Aufwandsschätzung eine vollständige Liste aller Komponenten mit Versionsnummern anzulegen. Auch Embarcadero rät zu einer solchen Liste, bevor die Umstellung beginnt.

Worauf es ankommt, wenn Sie Delphi nach C# migrieren

Fällt die Entscheidung für C#, gehört eine .NET-Version mit Langzeitunterstützung in den Plan. Microsoft unterstützt .NET 8 laut seiner Support-Richtlinie nur bis zum 10. November 2026 und die Langzeitversion .NET 10 bis November 2028. Ein neues Projekt setzt deshalb auf .NET 10 auf.

Bei der Oberfläche gibt es zwei Richtungen. Bleibt die Anwendung ein Windows-Programm, kommt Windows Forms aus meiner Sicht der Arbeitsweise der VCL am nächsten. In WPF wird die Oberfläche dagegen in XAML beschrieben, getrennt vom Programmcode, und lässt sich über Stile und Vorlagen an ein eigenes Erscheinungsbild anpassen. Läuft die Anwendung künftig im Browser, wird daraus eine Webanwendung mit ASP.NET Core. Diese Wahl hängt weniger von der Technik ab als davon, wo und auf welchen Geräten Ihr Team künftig arbeitet.

Wichtiger als jede Technikentscheidung ist der Nachweis, dass die neue Anwendung fachlich dasselbe tut wie die alte. Ich empfehle dafür Vergleichsfälle, also festgehaltene Eingaben zusammen mit den Ergebnissen, die das Delphi-Programm heute dafür liefert, etwa Rechnungsbeträge, Lagerbestände oder Auswertungen. Personenbezogene Daten sollten darin anonymisiert sein. Jeder neue Teil der Anwendung muss diese Fälle bestehen, bevor er den entsprechenden Teil des Altsystems ersetzt.

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. Martin Fowler beschreibt dieses Vorgehen mit dem Bild der Würgefeige (Strangler Fig), die auf einem Baum keimt, ihre Wurzeln bis in den Boden treibt und ihren Wirtsbaum mit der Zeit ersetzt. 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. Am Anfang steht die Frage, wie lange das System noch laufen soll. Bei einer Restlaufzeit von drei Jahren ist eine Migration selten sinnvoll, bei fünfzehn Jahren fast immer. Ebenso wichtig ist, wer es künftig warten wird und mit welchen Technologien diese Person arbeitet. Und schließlich sollten Sie wissen, welche Anforderungen absehbar sind, denn 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.

Delphi-Software modernisieren lassen: so gehe ich vor

Wenn Sie Ihre Delphi-Anwendung modernisieren lassen möchten, arbeite ich in festen Schritten. Sie sprechen dabei in jeder Phase direkt mit mir, ich gebe die Arbeit nicht an Subunternehmer weiter.

  1. Erstgespräch: Kostenlos und unverbindlich, bei Ihnen vor Ort in Freiburg und Südbaden oder per Video. Sie schildern, was die Anwendung leistet und wo es hakt, und ich gebe Ihnen eine ehrliche Einschätzung, welcher Weg infrage kommt.
  2. Bestandsaufnahme: Ich sehe mir den Code an, die Delphi-Version, die eingesetzten Komponenten und den Datenzugriff. Daraus ergibt sich, ob eine Umstellung auf eine aktuelle Delphi-Version, neue Schnittstellen, eine schrittweise Ablösung oder eine Migration nach C# der richtige Weg ist.
  3. Angebot: Festpreis bei klar definiertem Umfang, Stundensatz bei offenen Anforderungen, etwa wenn sich ein Teil des Aufwands erst im Code zeigt.
  4. Umsetzung im laufenden Betrieb: Ich modernisiere in kurzen Etappen, damit Ihr Tagesgeschäft weiterläuft. Zwischenstände sehen Sie früh. Bei einer Migration sichern Vergleichsfälle ab, dass die neue Anwendung dieselben Ergebnisse liefert wie die alte.
  5. Übergabe: Sie erhalten den vollständigen Quellcode und die Dokumentation ohne Lizenzbindung an mich, auf Wunsch mit Support-Vertrag.

Auf Anfragen über das Kontaktformular oder per E-Mail antworte ich werktags innerhalb von 48 Stunden. Welche Leistungen ich rund um gewachsene Anwendungen sonst anbiete, steht unter Leistungen im Abschnitt Legacy-Modernisierung.

Häufige Fragen zur Delphi-Modernisierung

Ist Delphi veraltet oder wird es 2026 noch weiterentwickelt?

Delphi wird weiterentwickelt. Embarcadero hat im September 2025 RAD Studio 13 Florence mit Delphi 13 veröffentlicht, im März 2026 das Update 13.1 nachgelegt und im September 2026 RAD Studio 13.2 herausgebracht, unter anderem mit einem Delphi-Compiler für Linux, der jetzt auf LLVM 20 aufbaut. Genutzt wird Delphi weiterhin, wenn auch von einer kleinen Gruppe. Von den 14.099 Befragten, die in der Entwicklerumfrage 2026 von Stack Overflow die Frage nach ihren Programmiersprachen beantwortet haben, gaben 267 an, im vergangenen Jahr intensiv mit Delphi entwickelt zu haben. Das sind 1,9 Prozent. Veraltet ist also nicht die Sprache selbst. Schwierig wird es bei Anwendungen, die auf einer alten Version stehen geblieben sind und deren Komponenten niemand mehr pflegt.

Lohnt sich der Umstieg von Delphi 7 auf eine aktuelle Delphi-Version?

Wenn die Anwendung fachlich noch passt und einige Jahre weiterlaufen soll, meistens ja. Der Aufwand steckt vor allem im Ersatz von Komponenten, die es nicht mehr gibt, in der Unicode-Bereinigung und, wo die Anwendung noch die BDE nutzt, im Wechsel auf FireDAC. Wie groß er ausfällt, zeigt erst ein Blick in den Code. Danach steht die Anwendung wieder auf einer gepflegten Grundlage, und Schnittstellen oder eine spätere Migration lassen sich in Ruhe planen.

Was ist der Unterschied zwischen Delphi-Modernisierung und Delphi-Migration?

Bei einer Modernisierung bleibt die Anwendung in Delphi. Sie wird auf eine aktuelle Delphi-Version gehoben, von veralteten Komponenten befreit oder um Schnittstellen erweitert. Bei einer Migration wechselt die Anwendung die Plattform, in meiner Praxis meist nach .NET mit C#. Dazwischen liegt die schrittweise Ablösung, bei der neue Module neben dem Delphi-Kern entstehen und ihn nach und nach ersetzen.

Kann man Delphi-Code automatisch nach C# übersetzen?

Es gibt Werkzeuge, die das anbieten. Selbst wenn der übersetzte Code läuft, bildet er die alte Struktur eins zu eins nach, samt ihrer Schwächen. Für eine ganze Anwendung rate ich deshalb davon ab. Der Gewinn einer Migration entsteht erst, wenn die Geschäftslogik verstanden und in der neuen Sprache sauber aufgebaut wird.

Womit lässt sich eine Delphi-Anwendung ablösen?

Für Windows-Anwendungen mit viel Geschäftslogik ist in meiner Praxis meist .NET mit C# der naheliegende Nachfolger. Soll die Anwendung künftig im Browser laufen, bietet sich eine Webanwendung mit C# auf dem Server an. Wichtiger als die Wahl der Sprache ist aber, dass Sie die Ablösung schrittweise angehen, damit der Betrieb weiterläuft, während die neuen Module wachsen.

Gibt es eine Alternative zu Delphi, die den bestehenden Code weiter nutzt?

In Grenzen ja. Lazarus ist eine quelloffene Entwicklungsumgebung auf Basis von Free Pascal, die sich selbst als Delphi-kompatibel beschreibt. Ihre Komponentenbibliothek LCL ist laut der Lazarus-Dokumentation der VCL von Delphi sehr ähnlich, ganz ohne Änderungen kommt eine Portierung aber nicht aus. Infrage kommt Lazarus etwa dann, wenn eine Anwendung mit VCL-Oberfläche auch unter Linux oder macOS laufen soll, denn Embarcadero sieht die VCL für Windows vor und für plattformübergreifende Oberflächen FireMonkey. Wer Teile einer Anwendung in den Browser bringen möchte, ohne die Sprache zu wechseln, kann sich TMS WEB Core ansehen, ein kommerzielles Framework für Webanwendungen in Delphi, das den Pascal-Code nach JavaScript übersetzt. Beides erspart nicht die Prüfung der eingesetzten Komponenten, und je mehr Fremdkomponenten eine Anwendung nutzt, desto aufwendiger wird ein solcher Wechsel.

Wie lange dauert die Modernisierung einer Delphi-Anwendung?

Das hängt vom Weg ab. Für eine vollständige Migration rechne ich je nach Umfang mit mehreren Monaten bis zu einem Jahr. Die Umstellung auf eine aktuelle Delphi-Version oder eine neue Schnittstelle geht deutlich schneller. Bei der Versionsumstellung hängt das vor allem von den verwendeten Komponenten ab. Eine belastbare Einschätzung gibt es erst nach einer Bestandsaufnahme des Codes.

Was tun, wenn der Quellcode der Delphi-Anwendung fehlt?

Aus einer kompilierten Programmdatei lässt sich der ursprüngliche Quelltext nicht vollständig zurückgewinnen. Retten lassen sich aber die Daten und das Wissen darüber, was das Programm tut. Sichern Sie in diesem Fall zuerst die Datenbank, halten Sie das Verhalten der Anwendung anhand echter Abläufe fest und lassen Sie daraus einen Nachfolger entwickeln, der dieselben Ergebnisse liefert. Das ist dann eine Neuentwicklung, aber eine mit klarer Vorlage.

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.

Im Oktober 2026 habe ich den Beitrag um die Abschnitte zum Umstieg von Delphi 7, zur Migration nach C# und zu meinem Vorgehen bei einer Beauftragung, ein weiteres Warnzeichen und die häufigen Fragen ergänzt. Die Angaben zu RAD Studio und zur Verbreitung von Delphi geben den Stand vom Oktober 2026 wieder.