Delphi modernisieren ohne Fachlogik zu verlieren

Delphi-Anwendungen laufen in vielen Unternehmen seit Jahren stabil – und bilden genau die Fachlogik ab, die Umsatz, Servicequalität und Compliance sichert. Bei einer Modernisierung geht es daher selten um „neue Oberfläche“, sondern um eine kontrollierte Weiterentwicklung, bei der Regeln, Sonderfälle und historisches Prozesswissen erhalten bleiben.

In diesem Beitrag zeigen wir ein praxiserprobtes Vorgehen, um Delphi schrittweise zu modernisieren: von der Bestandsaufnahme über die Entkopplung von UI/Datenzugriff bis zur technischen Modernisierung (Unicode/64‑Bit, BDE-Ablösung, API/Services) – inklusive Absicherung durch Tests, Monitoring und Parallelbetrieb. Ziel ist eine modernisierbare Architektur, ohne Big-Bang-Rewrite und ohne Logikverlust.

Modernisierungen scheitern in der Praxis selten am Compiler oder an einem Framework, sondern an falschen Annahmen über das Systemverhalten. Über Jahre gewachsene Delphi-Anwendungen enthalten typischerweise Fachregeln in GUI-Events, SQL in Formularlogik, Varianten pro Kunde/Mandant, historisch bedingte Sonderfälle sowie Integrationen, die nur „im Betrieb“ dokumentiert sind.

Ein Big-Bang-Rewrite zwingt dazu, dieses Wissen neu zu rekonstruieren – inklusive der Fehler, die das Altsystem längst nicht mehr macht. Der bessere Ansatz ist, die Fachlogik als Vermögenswert zu behandeln: isolieren, absichern, dann Schritt für Schritt modernisieren.

Ein tragfähiges Zielbild für prozesskritische B2B-Systeme ist nicht „alles neu“, sondern eine Architektur, die Veränderungen ermöglicht – ohne den laufenden Betrieb zu gefährden:

• klare Trennung von UI, Domänenlogik, Datenzugriff und Integrationen
• Test- und Messbarkeit (Regression, Logging, Monitoring, reproduzierbare Builds)
• schrittweise Austauschbarkeit (UI modernisieren ohne sofortige DB-Migration – oder umgekehrt)
• API-Fähigkeit (z. B. REST), um Portale, Mobile oder System-Integrationen anzubinden
• betriebsfähige Deployments mit Rollback-Option

Delphi eignet sich dafür gut, weil bestehende Units und Domänenklassen weiterverwendet werden können, während außen herum modernisiert wird.

Bevor Code angepasst wird, braucht es eine belastbare Entscheidungsgrundlage – keine Voll-Dokumentation. Bewährt haben sich diese drei Ergebnisse:

• Fachlogik-Landkarte: kritische Use-Cases, Regeln/Berechnungen, Varianten (Mandanten/Länder/Kunden), Schnittstellen, Jobs/Batch-Läufe.
• Risikoprofil: besonders fehlerkritische Bereiche, Datenqualität, regulatorische Anforderungen, Engpässe im Betrieb (Performance, Stabilität, Wartbarkeit).
• Modernisierungs-Backlog: priorisierte Pakete nach Business-Wert und Risiko (was muss stabil bleiben, was darf sich ändern, was später).

Damit lässt sich Modernisierung planbar machen: mit klaren Inkrementen statt einem einzigen „Alles-oder-nichts“-Projekt.

Damit Fachlogik nicht „versehentlich“ verändert wird, braucht es eine Absicherung, die unabhängig vom UI-Refactoring funktioniert. Typische Bausteine:

• Characterization/Golden-Master-Tests: vorhandenes Verhalten wird über repräsentative Eingaben/Ausgaben eingefroren (Reports, Berechnungen, Prozessschritte).
• Regressionstests auf Use-Case-Ebene: die geschäftskritischen Abläufe werden automatisiert oder halbautomatisiert nachgestellt.
• Telemetry: Logging, Metriken und Fehlerbilder werden vor/nach einer Änderung vergleichbar gemacht.
• Parallelbetrieb & kontrollierte Umstellung: neue Module laufen neben dem Bestand (Feature Toggles, Pilotgruppen), mit klarer Rollback-Strategie.

Erst wenn diese Sicherheitsnetze stehen, lohnt die eigentliche technische Modernisierung – weil Risiko und Nacharbeit drastisch sinken.

Der häufigste Grund für Logikverlust ist die Vermischung von UI, Datenzugriff und Fachregeln. Modernisierung beginnt daher mit Entkopplung – nicht mit dem Austausch des UI-Frameworks.

Ein pragmatisches Ziel ist eine 3‑Schichten-Struktur:

• Presentation: VCL/FMX, Presenter/ViewModel, nur UI-nahe Validierung (Format, Pflichtfelder)
• Business: Domänenmodelle, Services, Regeln, Zustandslogik, Berechnungen
• Data/Integration: Repositories, DB-Zugriff, Adapter zu ERP/DMS/CRM, REST-Clients, Messaging

Praxisregel: Fachregeln wandern aus OnClick/OnExit in Domänenservices. SQL wandert aus Forms in Repositories. So wird Logik testbar und später über UI, Services und Jobs wiederverwendbar.

Beim Strangulation Pattern entsteht Neues gezielt „neben“ dem Bestand: Neue Funktionen werden bereits in der entkoppelten Struktur implementiert, während das Altsystem weiterläuft. Schritt für Schritt übernimmt die neue Schicht mehr Verantwortung, bis alte Teile entfallen.

Beispiel (typisch B2B):

• Sie extrahieren die Auftragslogik in einen Domänenservice.
• Das bestehende VCL-UI nutzt zunächst denselben Service (kein Prozessbruch).
• Parallel entsteht ein REST-Endpunkt für ein Kundenportal oder eine Integration.
• Nach Stabilisierung werden einzelne alte Forms abgelöst – ohne dass die Kernlogik neu gebaut werden muss.

So reduzieren Sie Projektrisiko, erhalten Betriebsfähigkeit und gewinnen schnell messbaren Nutzen (z. B. API, Performance, Wartbarkeit).

Je nach Ausgangslage sind diese Bausteine häufig relevant – entscheidend ist die Priorisierung nach Risiko und Business-Wert:

• BDE/Legacy-DB-Zugriff ablösen: moderne Treiber/Provider, saubere Transaktionsgrenzen, reproduzierbare Deployments.
• Unicode: String-Handling, Datenbank/Interfaces, Drittanbieter-Komponenten.
• 64‑Bit: Abhängigkeiten, Memory/Performance, externe Libraries.
• API- und Service-Schicht: REST, Windows-/Linux-Services, Integrationen.
• Build & Release: CI/CD, Artefaktmanagement, signierte Installer, Rollback.

Wichtig: Diese Punkte werden idealerweise nach Entkopplung und Absicherung umgesetzt – dann lassen sich Änderungen sicher verifizieren.

Ein kompletter Rewrite ist in manchen Fällen sinnvoll – oft ist er aber der teuerste Weg, um „moderne Technik“ zu bekommen. Diese Fragen helfen bei der Einordnung:

• Ist die Fachlogik vollständig verstanden und testbar – oder steckt viel Wissen implizit im Betrieb?
• Gibt es harte Deadlines (z. B. Plattform-Ende, Compliance), die einen Parallelbetrieb ausschließen?
• Wie groß ist die Variantenvielfalt (Kunden-/Mandantenlogik)?
• Wie kritisch ist die Verfügbarkeit, und wie hoch ist die Toleranz für Prozessänderungen?
• Welche Teile sind wirklich „schuld“ (UI, Datenzugriff, Integrationen, Deployment) – und welche sind stabil?

In vielen B2B-Szenarien führt ein schrittweiser Ansatz schneller zu messbaren Ergebnissen, weil er Risiken kontrolliert und die Fachlogik schützt.

Delphi-Modernisierungs-Audit (für prozesskritische Anwendungen): Wir analysieren Architektur, Abhängigkeiten, Risikobereiche und liefern eine priorisierte Roadmap, wie Sie modernisieren, ohne Fachlogik zu verlieren.

• Input: Codebasis (read-only), Build-Setup, 2–3 Kern-Use-Cases, Systemumfeld (DB, Integrationen).
• Ergebnis: Fachlogik-/Modul-Landkarte, Risiko- und Abhängigkeitsanalyse, empfohlene Zielarchitektur, Umsetzungsplan in Inkrementen inkl. Absicherung (Tests/Parallelbetrieb).
• Optional: Proof of Concept für Entkopplung + erster Golden-Master-Test.

So bekommen Sie eine belastbare Entscheidungsgrundlage, bevor Budget und Zeit in einen riskanten Rewrite fließen.

Kann man Delphi modernisieren, ohne die Anwendung neu zu schreiben?
Ja. In vielen Fällen werden zuerst Fachlogik und Datenzugriff entkoppelt, dann technisch modernisiert. Das reduziert Risiko und hält den Betrieb stabil.

Wie verhindert man, dass Fachlogik „still“ verändert wird?
Über Golden-Master-/Regressionstests, Telemetrie sowie einen kontrollierten Parallelbetrieb mit klarer Rollback-Strategie.

Welche Schritte bringen oft den schnellsten Nutzen?
Transparenz (Assessment), Entkopplung von UI/SQL, BDE-Ablösung und eine API-/Service-Schicht für Integrationen – jeweils abgesichert durch Tests.

Wie lange dauert eine Modernisierung?
Das hängt von kritischen Use-Cases, Variantenvielfalt und Abhängigkeiten ab. Ein Audit liefert typischerweise in kurzer Zeit eine belastbare Roadmap und priorisierte Inkremente.