Modernisere Delphi uden at miste forretningslogikken

Delphi-applikationer kører i mange virksomheder stabilt i årevis – og afbilder præcis den domænelogik, der sikrer omsætning, servicekvalitet og compliance. Ved en modernisering handler det derfor sjældent om „ny brugerflade“, men om en kontrolleret videreudvikling, hvor regler, særlige tilfælde og historisk procesviden bevares.

I dette indlæg viser vi en praksisafprøvet fremgangsmåde til gradvis modernisering af Delphi: fra kortlægning over afkobling af UI/dataadgang til teknisk modernisering (Unicode/64‑Bit, BDE-udskiftning, API/Services) – inklusiv sikring gennem tests, monitoring og paralleldrift. Målet er en moderniserbar arkitektur uden Big-Bang-rewrite og uden tab af logik.

Moderniseringer fejler i praksis sjældent på grund af compileren eller et framework, men på grund af forkerte antagelser om systemets adfærd. Over år opbyggede Delphi-applikationer indeholder typisk fagregler i GUI-events, SQL i formularlogik, varianter per kunde/mandant, historisk betingede særtilfælde samt integrationer, der kun er dokumenteret „i drift“.

Et Big-Bang-rewrite tvinger til at rekonstruere denne viden på ny – inklusiv de fejl, som det ældre system ikke længere laver. En bedre tilgang er at behandle domænelogikken som en aktiv: isolere, sikre og så modernisere trinvis.

Et holdbart målbillede for proceskritiske B2B-systemer er ikke „alt nyt“, men en arkitektur, der tillader forandring – uden at sætte den løbende drift på spil:

• klar adskillelse af UI, domænelogik, dataadgang og integrationer
• testbarhed og målbarhed (regression, logging, monitoring, reproducerbare builds)
• trinvis udskiftelighed (modernisere UI uden øjeblikkelig DB-migration – eller omvendt)
• API-mulighed (f.eks. REST), for at koble portaler, mobil eller systemintegrationer på
• driftsparate deployments med rollback-mulighed

Delphi egner sig godt hertil, fordi eksisterende Units og domæneklasser kan genbruges, mens omgivelserne moderniseres.

Før koden tilpasses, er der brug for et solidt beslutningsgrundlag – ikke fulddokumentation. Følgende tre resultater har vist sig nyttige:

• Domænelogik-kort: kritiske use-cases, regler/beregninger, varianter (mandanter/lande/kunder), grænseflader, jobs/batchkørsler.
• Risikoprofil: særligt fejlkritiske områder, datakvalitet, regulatoriske krav, flaskehalse i driften (performance, stabilitet, vedligeholdelsesvenlighed).
• Moderniserings-backlog: prioriterede pakker efter forretningsværdi og risiko (hvad skal forblive stabilt, hvad kan ændres, hvad kan vente).

Derved kan modernisering gøres planbar: med klare inkrementer i stedet for ét enkelt „alt-eller-intet“-projekt.

For at domænelogikken ikke ved et uheld ændres, er der brug for en sikring, som virker uafhængigt af UI-refactoring. Typiske byggesten:

• Characterization/Golden-Master-Tests: eksisterende adfærd fryses ved repræsentative input/output (rapporter, beregninger, procestrin).
• Regressionstests på use-case-niveau: de forretningskritiske forløb efterspilles automatisk eller semi-automatisk.
• Telemetry: logging, metrikker og fejlbilleder gøres sammenlignelige før/efter en ændring.
• Paralleldrift & kontrolleret omstilling: nye moduler kører ved siden af det eksisterende (feature toggles, pilotgrupper), med en klar rollback-strategi.

Først når disse sikkerhedsnet er på plads, kan den egentlige tekniske modernisering betale sig – fordi risiko og efterarbejde falder drastisk.

Den hyppigste årsag til tab af forretningslogik er sammenblanding af UI, dataadgang og forretningsregler. Modernisering starter derfor med afkobling – ikke med udskiftning af UI-rammeværket.

Et pragmatisk mål er en 3‑lags struktur:

• Presentation: VCL/FMX, Presenter/ViewModel, kun UI-nær validering (format, obligatoriske felter)
• Business: Domænemodeller, Services, regler, tilstandslogik, beregninger
• Data/Integration: Repositories, DB-adgang, adapter til ERP/DMS/CRM, REST-Clients, Messaging

Praktisk regel: Forretningsregler flyttes fra OnClick/OnExit til Domänenservices. SQL flyttes fra Forms til Repositories. Så bliver logikken testbar og senere genanvendelig via UI, Services og Jobs.

Ved Strangulation Pattern opstår nyt målrettet „ved siden af“ det eksisterende: Nye funktioner implementeres allerede i den afkoblede struktur, mens det gamle system fortsætter. Skridt for skridt overtager det nye lag mere ansvar, indtil gamle dele bortfalder.

Eksempel (typisk B2B):

• I ekstraherer ordrelogikken til en Domänenservice.
• Det eksisterende VCL-UI bruger indledningsvis den samme service (ingen procesbrud).
• Parallelt oprettes en REST-endepunkt til et kundeportal eller en integration.
• Efter stabilisering afløses enkelte gamle Forms – uden at kerne­logikken behøver at blive genopbygget.

På den måde reducerer I projektrisiko, bevarer driftsevnen og opnår hurtigt målbar værdi (z. B. API, Performance, Wartbarkeit).

Afhængigt af udgangssituationen er disse byggesten ofte relevante – afgørende er prioritering efter risiko og forretningsværdi:

• BDE/Legacy-DB-Zugriff ablösen: moderne drivere/provider, klare transaktionsgrænser, reproducerbare Deployments.
• Unicode: String-Handling, Datenbank/Interfaces, Drittanbieter-Komponenten.
• 64‑Bit: afhængigheder, Memory/Performance, eksterne Libraries.
• API- und Service-Schicht: REST, Windows-/Linux-Services, Integrationen.
• Build & Release: CI/CD, Artefaktmanagement, signierte Installationspakker, Rollback.

Vigtigt: Disse punkter bør ideelt set gennemføres efter afkobling og sikring – så kan ændringer verificeres sikkert.

En komplet Rewrite er i nogle tilfælde fornuftig – ofte er det dog den dyreste vej til at få „moderne teknik“. Følgende spørgsmål hjælper med vurderingen:

• Er forretningslogikken fuldt ud forstået og testbar – eller ligger meget viden implicit i driften?
• Er der stramme deadlines (z. B. Plattform-Ende, Compliance), som udelukker parallel drift?
• Hvor stor er variantsammensætningen (Kunden-/Mandantenlogik)?
• Hvor kritisk er tilgængeligheden, og hvor stor er tolerancen for procesændringer?
• Hvilke dele er virkelig „schuld“ (UI, Datenzugriff, Integrationen, Deployment) – og hvilke er stabile?

I mange B2B-scenarier fører en trinvis tilgang hurtigere til målbare resultater, fordi den kontrollerer risici og beskytter forretningslogikken.

Delphi-Modernisierungs-Audit (für prozesskritische Anwendungen): Vi analyserer arkitektur, afhængigheder, risikoområder og leverer en prioriteret roadmap, hvordan I moderniserer uden at miste forretningslogik.

• Input: Kodebasis (read-only), Build-Setup, 2–3 Kern-Use-Cases, Systemumfeld (DB, Integrationen).
• Resultat: Forretningslogik-/modulkort, risiko- og afhængighedsanalyse, anbefalet målarkitektur, implementeringsplan i inkrementer inkl. sikring (tests/parallelkørsel).
• Valgfrit: Proof of Concept til afkobling + første Golden-Master-test.

Så får I et solidt beslutningsgrundlag, før budget og tid investeres i en risikabel omskrivning.

Kan man Delphi modernisere uden at omskrive applikationen?
Ja. I mange tilfælde afkobles først forretningslogik og dataadgang, hvorefter den tekniske modernisering gennemføres. Det reducerer risiko og holder driften stabil.

Hvordan forhindrer man, at forretningslogik ændres „stille“?
Gennem Golden-Master-/regressionstests, telemetri samt en kontrolleret parallelkørsel med en klar rollback-strategi.

Hvilke skridt giver ofte den hurtigste gevinst?
Gennemsigtighed (Assessment), afkobling af UI/SQL, BDE-udfasning og et API-/service-lag til integrationer – hver især sikret ved tests.

Hvor lang tid tager en modernisering?
Det afhænger af kritiske use-cases, antal varianter og afhængigheder. Et audit leverer typisk i kort tid en solid roadmap og prioriterede inkrementer.