Viele Unternehmen betreiben seit Jahren oder Jahrzehnten stabile Delphi-Anwendungen, die den Kern ihrer Prozesse abbilden: Auftragsabwicklung, Produktion, Service, Logistik, Abrechnung, Geräteverwaltung, Dokumenten-Workflows. In diesen Systemen steckt nicht nur Code, sondern ein belastbares Zusammenspiel aus Fachregeln, Datenmodell, Benutzerführung und Betriebserfahrung. Genau das macht die Modernisierung anspruchsvoll: Der eigentliche Wert liegt selten in der Oberfläche, sondern in der gewachsenen Fachlogik.
Wenn Modernisierung als „Neu bauen“ verstanden wird, ist der Verlust programmiert. Nicht, weil neue Technologien per se schlecht wären, sondern weil implizites Wissen aus dem Altbestand – Sonderfälle, historische Daten, Prozess-Ausnahmen, regulatorische Details – beim Umzug oft nicht vollständig rekonstruiert wird. Ergebnis sind teure Regressionsfehler, veränderte Prozesszeiten, Akzeptanzprobleme und ein Projekt, das länger läuft als geplant.
Delphi lässt sich jedoch sehr gut modernisieren, ohne die Fachlogik zu verlieren. Der Schlüssel ist ein kontrollierter, schrittweiser Ansatz: erst Transparenz schaffen (Architektur, Daten, Risiken), dann entkoppeln (UI, Datenzugriff, Domänenlogik), anschließend modernisieren (Datenbanktreiber, Unicode/64-Bit, APIs, Services, Multiplattform) – und dabei den laufenden Betrieb absichern. Dieser Beitrag beschreibt praxistaugliche Modernisierungsmuster, typische Fallstricke und eine Vorgehensweise, die in B2B-Umgebungen mit hoher Prozesskritikalität funktioniert.
Warum Delphi-Modernisierung selten ein „Technikprojekt“ ist
In der Realität scheitern Modernisierungen nicht an einem fehlenden Compiler-Flag, sondern an falschen Annahmen über das Systemverhalten. Delphi-Anwendungen, die über Jahre erweitert wurden, enthalten häufig:
- Fachregeln in GUI-Events (OnClick, OnExit, OnValidate), oft verteilt über viele Forms
- SQL-Statements „nah an der Oberfläche“ und seit Jahren optimiert für genau eine Datenbank
- Umgehungen für historische Daten, Sonderfälle, Kundenvarianten oder Mandantenlogik
- Batch-Prozesse, die in der Praxis zu festen Uhrzeiten laufen und Abhängigkeiten haben
- Integrationen in ERP, DMS, CRM oder Maschinen, die kaum dokumentiert sind
- Stilles Wissen in Form von Betriebsroutinen: „Wenn Fehler X, dann erst Y prüfen“
Wer hier mit einem Big-Bang-Rewrite startet, muss all das Wissen erneut erzeugen – inklusive der Fehler, die die alte Lösung schon lange nicht mehr macht. Der bessere Ansatz ist, die Fachlogik als Vermögenswert zu behandeln: zuerst isolieren, dann absichern, dann modernisieren.
Modernisierung ohne Logikverlust: Zielbild und Leitprinzipien
Ein tragfähiges Zielbild für B2B-Systeme ist kein „alles neu“, sondern eine Architektur, die Veränderungen ermöglicht. Typische Eigenschaften:
- Getrennte Verantwortlichkeiten (UI, Domäne/Fachlogik, Datenzugriff, Integrationen)
- Test- und Messbarkeit (Regressionstests, Logging, Monitoring, reproduzierbare Builds)
- Schrittweise Austauschbarkeit (UI modernisieren, ohne Datenmodell sofort umzubauen; DB migrieren, ohne UI neu zu schreiben)
- API-Fähigkeit (REST-Server oder Service-Schicht, um Portale, Mobile, Integrationen anzubinden)
- Betriebsfähigkeit (Windows- und Linux-Services, klare Deployments, Rollback-Strategie)
In Delphi ist das besonders gut erreichbar, weil Sie vorhandene Units und Domänenklassen weiterverwenden können, während Sie außen herum modernisieren: Datenzugriff von BDE auf BDE-Ablosung mit nativer Anbindung, neue REST-Endpoints, neue UI-Module, neue Deployments.
Bestandsaufnahme: Was muss wirklich erhalten bleiben?
Bevor Code „angefasst“ wird, lohnt eine strukturierte Bestandsaufnahme. Ziel ist nicht eine Voll-Dokumentation, sondern eine belastbare Entscheidungsgrundlage.
1) Fachlogik-Landkarte statt Code-Lesemarathon
Praktisch bewährt hat sich eine Fachlogik-Landkarte mit folgenden Perspektiven:
- Use-Cases: Welche Kernabläufe sind geschäftskritisch? (z. B. Auftrag anlegen, Rechnung, Storno, Rücklieferung, Maschinenservice, Wartungsvertrag)
- Regeln: Welche Validierungen, Berechnungen, Zustandsautomaten existieren?
- Varianten: Mandanten, Kundenkonfigurationen, länderspezifische Regeln
- Schnittstellen: Import/Export, ERP/DMS/CRM, Geräte/Protokolle
- Batch/Jobs: nächtliche Läufe, Reports, Datenabgleiche
Aus dieser Landkarte entstehen priorisierte Modernisierungspakete: Was muss stabil bleiben, was darf sich ändern, was kann später folgen.
2) Technische Schulden sichtbar machen
Typische technische Schulden in älteren Delphi-Systemen:
- Borland BDE/Paradox-Abhängigkeiten
- ANSI-Strings/fehlende Unicode-Migration
- 32-Bit-Only, veraltete Drittanbieter-Komponenten
- Monolithische Form-Logik, globale Variablen, seiteneffektlastige Units
- Unklare Transaktionsgrenzen und „SQL überall“
Die Kunst ist, diese Punkte nicht dogmatisch zu „bereinigen“, sondern in eine Reihenfolge zu bringen, die Risiko minimiert und Business-Wert maximiert.
Architektur-Entkopplung: Der Hebel gegen Logikverlust
Der häufigste Grund für Logikverlust ist die Vermischung von UI, Datenzugriff und Fachregeln. Modernisierung beginnt daher mit Entkopplung – nicht mit „neuem UI-Framework“.
Layer-3 Architektur als pragmatischer Zielzustand
Für viele Delphi-Bestandsanwendungen funktioniert eine Layer-3 Architektur sehr gut:
- Presentation Layer: VCL/FMX-Forms, ViewModels/Presenter, Validierung nur UI-nah (Format, Pflichtfelder)
- Business Layer: Domänenmodelle, Services, Regeln, Zustandslogik, Berechnungen
- Data/Integration Layer: Repositories, SQL/ORM-Teile, Schnittstellenadapter, REST-Clients, Messaging
Der Mehrwert: Fachlogik wird testbar und wiederverwendbar. Später kann ein Kundenportal, ein REST-Server oder ein Windows- und Linux-Services exakt dieselben Domänenservices nutzen. Damit modernisieren Sie die „Außenhaut“, ohne die Kernlogik neu zu erfinden.
Strangulation Pattern: Altes System schrittweise „umarmen“
Ein bewährtes Migrationsmuster ist das Strangulation Pattern: Neue Funktionen entstehen bereits in der neuen Struktur (z. B. Domänenservice + Repository), während bestehende Forms sukzessive umgebaut werden. Die alte Welt bleibt lauffähig, wird aber Stück für Stück durch die neue ersetzt.
Wichtig ist dabei, Abhängigkeiten aktiv zu drehen: nicht „Form ruft SQL“, sondern „Form ruft Service“, und der Service entscheidet. Diese kleine Umkehr ist oft der größte Gewinn.
Datenzugriff modernisieren: BDE-Ablösung und FireDAC sauber planen
Ein zentraler Modernisierungsschritt ist die BDE-Ablösung. Unternehmen unterschätzen hier oft, dass es nicht nur um Treiber geht, sondern um SQL-Semantik, Transaktionen, Locking, Datentypen und Fehlerverhalten. Moderne Delphi-Stacks setzen typischerweise auf BDE-Ablosung mit nativer Anbindung mit nativen Treibern (z. B. für MariaDB/MySQL, PostgreSQL, SQL Server).
Was bei der Umstellung wirklich entschieden wird
- Datenbankziel: Bleibt es bei der bestehenden DB? Ist ein Datenbank-Umbau sinnvoll (z. B. von Paradox/Firebird zu MariaDB oder PostgreSQL)?
- Transaktionsmodell: Wo beginnen/enden Transaktionen? Welche Use-Cases müssen atomar sein?
- Concurrency/Locking: Optimistisch vs. pessimistisch, Umgang mit Deadlocks, Retry-Strategien
- SQL-Dialekt: Datumsfunktionen, Stringverhalten, NULL-Handling, Case-Sensitivity
- Performance: Indizes, Query-Pläne, Paging, Batch-Inserts
Die Fachlogik hängt eng am Datenverhalten. Wer das „nebenbei“ migriert, riskiert in der Praxis subtile Abweichungen: Rundungen, Sortierungen, Datumsgrenzen, Sperrkonflikte. Darum gehört die Datenebene früh in den Modernisierungsplan, inklusive Migrationspfad und Testdatenstrategie.
Pragmatische Schritte zur FireDAC-Migration
Statt die komplette Anwendung in einem Rutsch umzubauen, hat sich folgende Reihenfolge bewährt:
- Einführen einer Datenzugriffsschicht (Repository/DAO) als Fassade
- Umstellen einzelner Use-Cases auf FireDAC (z. B. „Lesen“ zuerst, „Schreiben“ später)
- Vereinheitlichen von Connection-Handling, Fehlerbehandlung, Logging
- Schrittweise Abschalten von BDE-Komponenten, wo die Fassade stabil ist
So bleibt die Anwendung jederzeit lieferfähig, und Sie vermeiden einen langen Zeitraum, in dem „alles halb fertig“ ist.
Unicode, 64-Bit und Abhängigkeiten: Die Modernisierungsfallen im Detail
Viele Modernisierungen scheitern nicht am Konzept, sondern an unterschätzten Detailthemen. Drei davon sind in Delphi-Projekten besonders häufig.
Unicode-Migration: Nicht nur Strings, sondern Datenflüsse
Bei sehr alten Delphi-Versionen stammen Systeme aus einer ANSI-Welt. Eine Unicode-Migration betrifft dann:
- String-Typen und Konvertierungen (WideString/AnsiString/UnicodeString)
- Datei- und Pfadhandling (Windows-API, Netzwerkpfade)
- Import/Export (CSV, feste Feldlängen, EDI, Legacy-Schnittstellen)
- Sortierung/Kollation in der Datenbank
Entscheidend ist, die kritischen Datenflüsse zu identifizieren (z. B. Rechnungstexte, Artikelbezeichnungen, internationale Adressen) und dafür Regressionstests aufzusetzen. Unicode ist weniger ein „Umbau“ als ein durchgängiger Qualitätsprozess.
64-Bit Umstieg: Speicher ist nicht das einzige Thema
Der 64-Bit Umstieg wird oft auf „Pointer-Größen“ reduziert. In der Praxis sind es eher:
- Veraltete Drittanbieter-Komponenten ohne 64-Bit-Support
- COM/ActiveX-Abhängigkeiten
- DLLs und Treiber (Barcode, Geräte, Kryptografie, Signatur)
- Installer/Deployment und Registry-Pfade (WOW64)
Eine sinnvolle Strategie ist, zuerst alle externen Abhängigkeiten zu inventarisieren und Alternativen zu definieren. Dann ist der 64-Bit-Schritt planbar – und wird nicht zum Überraschungspaket kurz vor dem Release.
Windows 11 ARM64: Früh prüfen statt spät bezahlen
Mit Windows 11 ARM64 taucht eine neue Klasse von Zielsystemen auf. Auch wenn nicht jedes Unternehmen sofort native ARM64-Builds braucht, ist es klug, früh zu prüfen:
- Gibt es native Abhängigkeiten (DLLs, Treiber), die unter ARM64 nicht laufen?
- Ist die Anwendung auf Emulation angewiesen, und ist das akzeptabel?
- Wie sieht der Installer aus, wie das Update/Repair?
In Modernisierungsprojekten ist das ein typisches „spätes“ Thema, das dann teuer wird. Besser: früh in die Plattform-Roadmap aufnehmen und technisch abklären.
REST-Server und Services: Fachlogik für Portale und Integration nutzbar machen
Viele Unternehmen modernisieren Delphi nicht, weil die Desktop-App „alt“ aussieht, sondern weil neue Anforderungen entstehen: Kundenportal, Partnerzugänge, mobile Prozesse, Integration mit ERP/DMS/CRM, Reporting-Pipelines. Dafür braucht es klare Schnittstellen. Ein REST-Server ist häufig die praktikabelste Brücke.
API zuerst? Nur, wenn Rechte und Domänenlogik mitkommen
Eine API ist nur dann ein Gewinn, wenn sie dieselbe Fachlogik durchsetzt wie der Client. Sonst entstehen zwei Regelwerke: eins im Desktop, eins im Backend. Konsequenzen sind Inkonsistenzen und Sicherheitslücken.
Darum sollte eine REST-Server-Schicht möglichst direkt auf Domänenservices aufsetzen. Typische Bausteine:
- Authentifizierung/Autorisierung (Rollen, Mandanten, Rechte)
- DTOs/Serialisierung mit klaren Versionierungsregeln
- Transaktions- und Fehlerkonzept (HTTP-Status, Problem-Details, Logging)
- Idempotenz und Nebenläufigkeit (für Retries, Queue-Verarbeitung)
So wird der REST-Server zum stabilen Integrationspunkt – nicht zum „zweiten Client“.
Linux-Services und Windows Services modernisieren
Batch-Prozesse und Integrationen laufen in vielen Unternehmen als Windows Services, Task Scheduler Jobs oder sogar „versteckte“ Desktop-Instanzen. Bei der Modernisierung lohnt die Konsolidierung:
- Trennen von UI und Hintergrundlogik
- Konfigurierbare Laufpläne und klare Betriebsparameter
- Sauberes Logging (strukturierte Logs, Korrelation pro Job/Request)
- Option, Services unter Linux zu betreiben (z. B. für containerisierte Deployments)
Der Vorteil ist nicht nur „modern“, sondern operational: reproduzierbarer Betrieb, weniger manuelle Eingriffe, bessere Fehlersuche.
UI modernisieren, ohne den Kern anzufassen: VCL, FMX und hybride Ansätze
Viele Modernisierungspläne starten beim UI. Das kann sinnvoll sein – solange klar ist, was man damit gewinnt. Wenn die Fachlogik entkoppelt ist, lässt sich das UI deutlich risikoärmer erneuern.
VCL-Anwendungen schrittweise modernisieren
VCL ist in vielen B2B-Szenarien weiterhin eine robuste Wahl, insbesondere für Windows-lastige Umgebungen mit hoher Produktivität am Desktop. Modernisierung kann hier heißen:
- UI-Logik reduzieren (Presenter/ViewModel), Fachregeln in Services verschieben
- Komponentenlandschaft bereinigen, eigene Controls konsolidieren
- Responsiveness verbessern (Async, Hintergrundjobs, progress, Cancel)
- Barrierearme Bedienung, konsistente Validierung, bessere Fehlermeldungen
Das ergibt spürbaren Nutzen, ohne die komplette Oberfläche neu zu schreiben.
Delphi Multiplattform: Wann FMX Sinn ergibt
Wenn echte Multiplattform-Anforderungen bestehen (Windows, macOS, ggf. Linux im Service-Kontext), kann FMX eine Option sein. Entscheidend ist die Erwartung: Multiplattform bedeutet zusätzliche Test- und Integrationsarbeit (Fonts, Druck, OS-Dialoge, Dateisystem, Verpackung/Deployment). Die Kosten sind gut kalkulierbar, wenn die Fachlogik bereits in einer sauberen Schicht liegt.
Ein häufiger pragmatischer Weg ist hybrid: VCL bleibt für den Windows-Client, während neue Frontends (Portal, mobile App) über den REST-Server kommen. So entsteht Multiplattform über die Systemgrenzen, nicht über einen einzigen UI-Stack.
Testing und Regression: Wie man Fachlogik „festnagelt“
„Fachlogik verlieren“ bedeutet in der Praxis: Das System liefert in Randfällen andere Ergebnisse. Das ist selten sofort sichtbar, aber teuer. Darum ist Testbarkeit kein Luxus, sondern Modernisierungswerkzeug.
Goldene Use-Cases und Referenzdaten
Bewährt hat sich ein Set aus „goldenen“ Use-Cases: reale, kritische Abläufe mit definierter Datenlage und erwarteten Ergebnissen (z. B. Belegkette von Angebot bis Gutschrift, oder Wartungsauftrag mit Ersatzteilen und Zeitbuchungen). Diese werden als Regressionstests oder zumindest als wiederholbare Testskripte etabliert.
Wichtig: nicht nur Erfolgspfade, sondern auch typische Fehlerpfade (Sperrkonflikte, fehlende Rechte, unvollständige Stammdaten, doppelte Importdatei).
Automatisierung dort, wo sie den größten Hebel hat
Nicht jedes Bestandsprojekt braucht sofort 80% Unit-Test-Abdeckung. Hoher ROI entsteht oft bei:
- Domänenservices (Berechnungen, Regeln, Zustandswechsel)
- Datenzugriff mit klaren Contracts (Mapping, SQL, Transaktionen)
- API-Tests (Auth, Rechte, Versionierung)
Das Ziel ist Stabilität bei Änderungen, nicht akademische Metriken.
Vorgehensmodell in der Praxis: Ein Modernisierungsfahrplan in Etappen
Aus B2B-Sicht muss Modernisierung lieferfähig bleiben. Ein typischer Fahrplan, der sich an den Risiken orientiert:
Etappe 1: Analyse, Zielarchitektur, Quick Wins (2–6 Wochen)
- Systemlandkarte (Module, Datenbanken, Schnittstellen, Jobs, Abhängigkeiten)
- Risikomatrix (BDE, Drittanbieter, 32/64-Bit, Unicode, Deployment)
- Definition der Zielarchitektur (Layer-3, Service-Schicht, API-Strategie)
- Quick Wins: Build-Prozess stabilisieren, Logging verbessern, Versionsverwaltung aufräumen
Etappe 2: Entkopplung der Fachlogik (laufend, inkrementell)
- Domänenservices identifizieren und aus Forms herauslösen
- Repository-Fassaden einführen
- Erste Regressionstests für kritische Use-Cases
Etappe 3: Datenzugriff/DB-Schicht modernisieren
- FireDAC einführen, Verbindungs- und Transaktionskonzept etablieren
- BDE-Ablösung modulweise (oder Datenbankmigration mit Parallelbetrieb)
- Performance- und Sperrverhalten unter Last testen
Etappe 4: REST-Server und Integrationen nachrüsten
- API mit Auth, Rechten, Versionierung
- Portale/Integrationen anbinden, ohne doppelte Logik
- Services für Batch und Hintergrundprozesse konsolidieren
Etappe 5: Plattform und UI-Entscheidungen (64-Bit, ARM64, Multiplattform)
- 64-Bit Build, Abhängigkeiten ersetzen
- ARM64-Kompatibilität prüfen/planen
- UI-Modernisierung: VCL refresh oder FMX/hybrid, basierend auf Business-Nutzen
Die Reihenfolge ist bewusst so gewählt, dass Sie früh Transparenz gewinnen, dann den Kern stabilisieren und erst danach „sichtbare“ Veränderungen groß ausrollen. So sinkt das Risiko, und der Betrieb bleibt planbar.
Typische Anti-Patterns: Was Modernisierungen unnötig teuer macht
Einige Muster tauchen in Audits und Rettungsprojekten immer wieder auf:
- „Wir bauen neu und übernehmen nur Features“: führt fast immer zu Logikverlust, weil Sonderfälle fehlen.
- API als Parallelwelt: Business-Regeln werden im Client belassen und im Backend neu erfunden.
- Datenbankwechsel ohne Semantiktests: gleiche Daten, aber anderes Verhalten (NULL, Sortierung, Datumslogik).
- Zu spätes Dependency-Management: 64-Bit/ARM64 scheitert an einer kleinen DLL kurz vor Go-Live.
- „Refactoring zuerst“ ohne Zielbild: viele Änderungen, wenig messbarer Nutzen, hohe Regression.
Der Gegenentwurf ist immer derselbe: zuerst Zielarchitektur und Risiken klären, dann inkrementell umbauen, dabei Fachlogik testen und sichtbar machen.
Fazit: Modernisieren heißt bewahren – und gezielt erweitern
Delphi modernisieren ohne Fachlogik zu verlieren ist kein Widerspruch, sondern eine Disziplin. Unternehmen müssen nicht zwischen „alles behalten“ und „alles ersetzen“ wählen. Mit sauberer Architekturtrennung (z. B. Layer-3), einer kontrollierten BDE-Ablösung hin zu FireDAC, einer API-Strategie über REST-Server sowie einem klaren Plan für Unicode, 64-Bit und neue Plattformen wie Windows 11 ARM64 lässt sich ein gewachsenes System schrittweise in eine zukunftsfähige Struktur überführen.
Der entscheidende Punkt ist, die Fachlogik als Kernasset zu behandeln: isolieren, testbar machen, dann modernisieren. So entsteht eine Architektur, die Portale, Services und Multiplattform-Anforderungen unterstützt, ohne den laufenden Betrieb zu riskieren.
Wenn Sie eine Delphi Modernisierung planen und dabei Fachlogik, Datenzugriff und Betrieb sauber zusammenführen möchten, sprechen Sie mit uns über einen realistischen Migrationspfad: https://net-base-software-gmbh.de/kontakt/