Mange virksomheder har i årevis eller årtier drevet stabile Delphi-applikationer, som afbilder kernen i deres processer: ordrebehandling, produktion, service, logistik, fakturering, enhedsadministration, dokument-workflows. I disse systemer findes ikke kun kode, men et robust samspil af forretningsregler, datamodel, brugerstyring og driftskundskab. Netop det gør modernisering krævende: den reelle værdi ligger sjældent i brugerfladen, men i den opvoksede forretningslogik.
Hvis modernisering forstås som „nybyggeri“, er tabet forudbestemt. Ikke fordi nye teknologier som sådan er dårlige, men fordi implicit viden fra det gamle system – undtagelsestilfælde, historiske data, proces-undtagelser, regulatoriske detaljer – ved migration ofte ikke rekonstrueres fuldstændigt. Resultatet er dyre regressionsfejl, ændrede procesvarigheder, acceptproblemer og et projekt, der trækker ud længere end planlagt.
Delphi kan imidlertid moderniseres meget godt uden at miste forretningslogikken. Nøglen er en kontrolleret, trinvis tilgang: først skabe transparens (arkitektur, data, risici), derefter frakoble (UI, dataadgang, domænelogik), efterfølgende modernisere (database-drivere, Unicode/64-Bit, APIs, services, multiplatform) – og samtidig sikre den løbende drift. Dette indlæg beskriver praktisk anvendelige moderniseringsmønstre, typiske faldgruber og en fremgangsmåde, der fungerer i B2B-miljøer med høj proceskritikalitet.
Hvorfor Delphi-modernisering sjældent er et „teknikprojekt“
I virkeligheden fejler moderniseringer ikke på et manglende compiler-flag, men på forkerte antagelser om systemadfærd. Delphi-applikationer, der er udvidet over år, indeholder ofte:
- Forretningsregler i GUI-events (OnClick, OnExit, OnValidate), ofte spredt over mange forms
- SQL-udtryk „tæt på overfladen“ og optimeret i årevis til netop én database
- Omgåelser for historiske data, undtagelsestilfælde, kundeversioner eller multitenant-logik
- Batch-processer, som i praksis kører på faste tidspunkter og har afhængigheder
- Integrationer til ERP, DMS, CRM eller maskiner, som er sparsomt dokumenterede
- Tavs viden i form af driftsrutiner: „Hvis fejl X, så tjek først Y“
Den, der starter på et Big-Bang-rewrite her, må genskabe al denne viden – inklusive de fejl, som den gamle løsning længe ikke længere laver. Den bedre tilgang er at behandle forretningslogikken som en aktivpost: først isolere, så sikre, dernæst modernisere.
Modernisering uden logiktab: Målbillede og ledende principper
Et holdbart målbillede for B2B-systemer er ikke „alt nyt“, men en arkitektur, der muliggør forandringer. Typiske karakteristika:
- Adskilte ansvarsområder (UI, domæne/forretningslogik, dataadgang, integrationer)
- Testbarhed og målelighed (regressionstests, logging, monitoring, reproducerbare builds)
- Trinvis udskiftbarhed (modernisere UI uden straks at ændre datamodel; migrere DB uden at omskrive UI)
- API-egnethed (REST-Server eller servicelag til at tilkoble portaler, mobile enheder, integrationer)
- Driftsevne (Windows- og Linux-Services, klare deployments, rollback-strategi)
I Delphi er dette særligt opnåeligt, fordi I kan genbruge eksisterende units og domæneklasser, mens I moderniserer udefra: dataadgang fra BDE til BDE-Ablösung mit nativer Anbindung, nye REST-endpoints, nye UI-moduler, nye deployments.
Statusopgørelse: Hvad skal virkelig bevares?
Før kode „berøres“, er en struktureret statusopgørelse værdifuld. Målet er ikke fuld dokumentation, men et robust beslutningsgrundlag.
1) Kort over forretningslogik i stedet for marathon-læsning af kode
En praktisk anvendt metode er et kort over forretningslogikken med følgende perspektiver:
- Use-cases: Hvilke kerneforløb er forretningskritiske? (f.eks. oprette ordre, faktura, kreditnota, returnering, maskinservice, serviceaftale)
- Regler: Hvilke valideringer, beregninger, tilstandsmaskiner findes?
- Varianter: Tenants, kundekonfigurationer, landespecifikke regler
- Grænseflader: Import/export, ERP/DMS/CRM, enheder/protokoller
- Batch/jobs: natlige job, rapporter, data-synkroniseringer
Fra dette kort opstår prioriterede moderniseringspakker: hvad der skal forblive stabilt, hvad der kan ændres, og hvad der kan vente.
2) Gør teknisk gæld synlig
Typisk teknisk gæld i ældre Delphi-systemer:
- Borland BDE/Paradox-afhængigheder
- ANSI-strings/manglende Unicode-migration
- 32-Bit-only, forældede tredjepartskomponenter
- Monolitisk form-logik, globale variable, units med bivirkninger
- Uklare transaktionsgrænser og „SQL overalt“
Kunsten er ikke at behandle disse punkter dogmatisk, men at rækkefølge dem, så risikoene minimeres og forretningsværdien maksimeres.
Arkitektur-frakobling: Håndtaget mod logiktab
Den hyppigste årsag til logiktab er sammenblanding af UI, dataadgang og forretningsregler. Modernisering starter derfor med frakobling – ikke med et „nyt UI-framework“.
Layer-3-arkitektur som pragmatisk måltilstand
For mange Delphi-bestandsapplikationer fungerer en Layer-3 Architektur meget godt:
- Presentation Layer: VCL/FMX-forms, ViewModels/Presenter, validering kun UI-nært (format, obligatoriske felter)
- Business Layer: Domænemodeller, services, regler, tilstandslogik, beregninger
- Data/Integration Layer: Repositories, SQL/ORM-komponenter, integrationsadaptere, REST-clients, messaging
Fordelen: forretningslogikken bliver testbar og genanvendelig. Senere kan et kundeserviceportal, en REST-server eller et Windows- und Linux-Services præcis genbruge de samme domæneservices. Dermed moderniserer I „ydersiden“ uden at genopfatte kernen.
Strangulation Pattern: Gradvis „omfavn“ det gamle system
Et afprøvet migrationsmønster er Strangulation Pattern: nye funktioner udvikles allerede i den nye struktur (f.eks. domæneservice + repository), mens eksisterende forms løbende ombygges. Den gamle verden forbliver kørbar, men erstattes stykkevis af den nye.
Vigtigt er aktivt at vende afhængigheder: ikke „Form kalder SQL“, men „Form kalder Service“, og servicen træffer beslutningen. Denne lille inversion er ofte den største gevinst.
Modernisere dataadgang: BDE-Ablösung og FireDAC planlægges omhyggeligt
Et centralt moderniseringsskridt er BDE-Ablösung. Virksomheder undervurderer ofte, at det ikke kun handler om drivere, men om SQL-semantik, transaktioner, locking, datatyper og fejladfærd. Moderne Delphi-stacks anvender typisk BDE-Ablosung mit nativer Anbindung med native drivere (f.eks. til MariaDB/MySQL, PostgreSQL, SQL Server).
Hvad der reelt besluttes ved omstillingen
- Databasemål: Bliver den eksisterende DB bevaret? Er en databaseombygning hensigtsmæssig (f.eks. fra Paradox/Firebird til MariaDB eller PostgreSQL)?
- Transaktionsmodel: Hvor begynder/slutter transaktioner? Hvilke use-cases skal være atomare?
- Concurrency/Locking: Optimistisk vs. pessimistisk, håndtering af deadlocks, retry-strategier
- SQL-dialekt: Dato-funktioner, string-adfærd, NULL-håndtering, case-sensitivitet
- Performance: Indekser, query-planer, paging, batch-inserts
Forretningslogikken er tæt knyttet til dataadfærd. Den, der migrerer „ved siden af“, risikerer subtile afvigelser i praksis: afrundinger, sorteringer, datogrænser, låsekonflikter. Derfor bør data-laget være tidligt på moderniseringsplanen, inklusive migrationssti og testdatastrategi.
Pragmatiske skridt til FireDAC-migration
I stedet for at bygge hele applikationen om på én gang, har følgende rækkefølge vist sig effektiv:
- Indfør en dataadgangslayer (Repository/DAO) som facade
- Skift enkelte use-cases til FireDAC (f.eks. „læsning“ først, „skrivning“ senere)
- Harmoniser connection-håndtering, fejlbehandling, logging
- Trinvis udfasning af BDE-komponenter, når facaden er stabil
Så forbliver applikationen leveringsdygtig til enhver tid, og I undgår en lang periode, hvor „alt er halvt færdigt“.
Unicode, 64-Bit og afhængigheder: Moderniseringsfaldgruber i detaljen
Mange moderniseringer fejler ikke på konceptet, men på undervurderede detaljeemner. Tre af dem er særligt hyppige i Delphi-projekter.
Unicode-migration: Ikke kun strings, men datagange
I meget gamle Delphi-versioner stammer systemerne fra en ANSI-verden. En Unicode-migration vedrører derfor:
- String-typer og konverteringer (WideString/AnsiString/UnicodeString)
- Fil- og sti-håndtering (Windows-API, netværksstier)
- Import/export (CSV, faste feltlængder, EDI, legacy-grænseflader)
- Sortering/kollation i databasen
Det afgørende er at identificere kritiske datagange (f.eks. fakturatekster, varenavne, internationale adresser) og opsætte regressionstests for dem. Unicode er mindre et enkeltstående „ombyg“ end en gennemgående kvalitetssikring.
64-Bit-overgang: Hukommelse er ikke det eneste emne
64-Bit-skiftet reduceres ofte til „pointer-størrelser“. I praksis drejer det sig ofte om:
- Forældede tredjepartskomponenter uden 64-Bit-support
- COM/ActiveX-afhængigheder
- DLLs og drivere (stregkoder, enheder, kryptografi, signatur)
- Installer/deployment og registry-stier (WOW64)
En fornuftig strategi er først at inventarisere alle eksterne afhængigheder og definere alternativer. Så bliver 64-Bit-skiftet planlægningsbart – og ikke en overraskelse tæt på release.
Windows 11 ARM64: Tidlig afklaring frem for sen betaling
Med Windows 11 ARM64 dukker en ny klasse af målplatforme op. Selv om ikke alle virksomheder straks behøver native ARM64-builds, er det klogt at afklare tidligt:
- Findes der native afhængigheder (DLLs, drivere), som ikke kører på ARM64?
- Er applikationen afhængig af emulation, og er det acceptabelt?
- Hvordan ser installer, opdatering/repair-funktion ud?
I moderniseringsprojekter er dette et typisk „senty“ emne, der bliver dyrt. Bedre: indarbejd det tidligt i platform-roadmappen og afklar teknisk.
REST-Server og services: Gør forretningslogikken tilgængelig for portaler og integrationer
Mange virksomheder moderniserer ikke Delphi blot fordi desktop-appen virker «gammel», men fordi nye krav opstår: kundeserviceportal, partneradgang, mobile processer, integration til ERP/DMS/CRM, reporting-pipelines. Det kræver klare grænseflader. En REST-server er ofte den mest praktiske bro.
API først? Kun hvis rettigheder og domænelogik følger med
En API er kun en gevinst, hvis den håndhæver samme forretningslogik som klienten. Ellers opstår to regelsæt: ét i desktop-klienten, ét i backend. Konsekvenserne er inkonsistenser og sikkerhedshuller.
Dérfor bør en REST-serverlag så vidt muligt bygge direkte på domæneservices. Typiske komponenter:
- Autentificering/autorisering (roller, tenants, rettigheder)
- DTOs/serialisering med klare versionsregler
- Transaktions- og fejlkoncept (HTTP-status, problem-details, logging)
- Idempotens og samtidighed (til retries, kø-behandling)
På den måde bliver REST-serveren et stabilt integrationspunkt – ikke en „anden klient“.
Linux-Services og Windows-services modernisere
Batch-processer og integrationer kører i mange virksomheder som Windows-services, Task Scheduler-jobs eller endda som „skjulte“ desktop-instanser. Ved modernisering er konsolidering ofte fordelagtig:
- Adskille UI og baggrundslogik
- Konfigurerbare kørselsplaner og klare driftsparametre
- Ren logging (strukturerede logs, korrelation per job/request)
- Mulighed for at køre services under Linux (f.eks. til containeriserede deployments)
Fordelen er ikke kun „modernitet“, men operationel: reproducerbar drift, færre manuelle indgreb, bedre fejlsøgning.
UI-modernisering uden at røre kernen: VCL, FMX og hybride tilgange
Mange moderniseringsplaner starter ved UI. Det kan være fornuftigt – så længe gevinsterne er klare. Når forretningslogikken er frakoblet, kan UI fornyes med markant lavere risiko.
Trinvis modernisering af VCL-applikationer
VCL er i mange B2B-scenarier fortsat et robust valg, især i Windows-tunge miljøer med høj produktivitet på desktop. Modernisering kan betyde:
- Reducere UI-logik (Presenter/ViewModel), flytte forretningsregler til services
- Rydde op i komponentlandskabet, konsolidere egne controls
- Forbedre responsivitet (async, baggrundsjob, progress, cancel)
- Tilgængelighed, konsekvent validering, bedre fejlbeskeder
Det giver mærkbar værdi uden at omskrive hele brugerfladen.
Delphi multiplatform: Hvornår FMX giver mening
Hvis der er reelle multiplatform-krav (Windows, macOS, eventuelt Linux i servicekontext), kan FMX være en mulighed. Afgørende er forventningen: multiplatform medfører ekstra test- og integrationsarbejde (fonts, udskrift, OS-dialoger, filsystem, pakning/deployment). Omkostningerne er velberegnelige, når forretningslogikken allerede ligger i et rent lag.
En hyppig pragmatisk vej er hybrid: VCL forbliver til Windows-klienten, mens nye frontend-løsninger (portal, mobilapp) tilgår via REST-serveren. Så opnår man multiplatform på tværs af systemgrænser, ikke via et enkelt UI-stack.
Test og regression: Hvordan man „spænder fast“ forretningslogikken
At „miste forretningslogik“ betyder i praksis: systemet leverer i kanttilfælde andre resultater. Det er sjældent øjeblikkeligt synligt, men dyrt. Derfor er testbarhed ikke luksus, men et moderniseringsværktøj.
Guld-Use-Cases og referencedata
En effektiv praksis er et sæt af „guld“-use-cases: reelle, kritiske forløb med defineret datagrundlag og forventede resultater (f.eks. dokumentspor fra tilbud til kreditnota, eller en serviceordre med reservedele og tidsregistreringer). Disse etableres som regressionstests eller mindst som gentagelige testskripter.
Vigtigt: ikke kun successtier, men også typiske fejlstier (låsekonflikter, manglende rettigheder, ufuldstændige stamdata, duplikerede importfiler).
Automatisér hvor ROI er størst
Ikke hvert legacy-projekt har brug for straks 80% unit-test-dækning. Høj ROI opnås ofte ved:
- Domæneservices (beregninger, regler, tilstandsændringer)
- Dataadgang med klare kontrakter (mapping, SQL, transaktioner)
- API-tests (auth, rettigheder, versionering)
Målet er stabilitet ved ændringer, ikke akademiske metrics.
Fremgangsmodel i praksis: En moderniseringskøreplan i etaper
Fra et B2B-perspektiv skal modernisering forblive leverbar. En typisk køreplan, der prioriterer efter risici:
Etape 1: Analyse, målarkitektur, Quick Wins (2–6 uger)
- Systemkort (moduler, databaser, grænseflader, jobs, afhængigheder)
- Risikomatrix (BDE, tredjepart, 32/64-Bit, Unicode, deployment)
- Definition af målarkitektur (Layer-3, service-lag, API-strategi)
- Quick Wins: stabilisere build-process, forbedre logging, rydde versionsstyring op
Etape 2: Frakobling af forretningslogik (løbende, inkrementelt)
- Identificere domæneservices og udløse dem fra forms
- Indføre repository-facader
- Første regressions-tests for kritiske use-cases
Etape 3: Modernisere dataadgang/DB-lag
- Indføre FireDAC, etablere forbindelses- og transaktionskoncept
- BDE-Ablösung modulvis (eller databasemigration med parallel drift)
- Teste performance og låseadfærd under belastning
Etape 4: Eftermontere REST-Server og integrationer
- API med auth, rettigheder, versionering
- Tilkoble portaler/integrationer uden dobbelt logik
- Konsolidere services til batch og baggrundsprocesser
Etape 5: Platform- og UI-beslutninger (64-Bit, ARM64, multiplatform)
- 64-Bit build, udskifte afhængigheder
- Afklare/planlægge ARM64-kompatibilitet
- UI-modernisering: VCL-refresh eller FMX/hybrid, baseret på forretningsnytte
Rækkefølgen er bevidst valgt, så I tidligt opnår transparens, derefter stabiliserer kernen og først derefter ruller de „synlige“ ændringer stort ud. På den måde mindskes risikoen, og driften forbliver planbar.
Typiske anti-patterns: Hvad gør moderniseringer unødigt dyre
Nogle mønstre dukker gentagne gange op i audits og redningsprojekter:
- „Vi bygger nyt og tager kun funktioner med“: fører næsten altid til logiktab, fordi undtagelsestilfælde mangler.
- API som parallel verden: Forretningsregler forbliver i klienten og genopfindes i backend.
- Database-skift uden semantiske tests: samme data, men anderledes adfærd (NULL, sortering, datologik).
- For sent dependency-management: 64-Bit/ARM64 fejler på en lille DLL lige før go-live.
- „Refactoring først“ uden målbillede: mange ændringer, lille målbar gevinst, høj regression.
Modsvaret er altid det samme: afklar målarkitektur og risici først, byg så inkrementelt, test og gør forretningslogikken synlig.
Konklusion: Modernisere betyder bevare – og målrettet udvide
At modernisere Delphi uden at miste forretningslogik er ikke en selvmodsigelse, men en disciplin. Virksomheder behøver ikke vælge mellem „alt beholde“ og „alt erstatte“. Med klar arkitekturadskillelse (f.eks. Layer-3), en kontrolleret BDE-Ablösung mod FireDAC, en API-strategi via REST-servere samt en klar plan for Unicode, 64-Bit og nye platforme som Windows 11 ARM64 kan et opvokset system trinvis overføres til en fremtidssikret struktur.
Det afgørende er at behandle forretningslogikken som kerneaktivet: isoler den, gør den testbar, og moderniser derefter. Så opstår en arkitektur, som understøtter portaler, services og multiplatform-krav uden at bringe den løbende drift i fare.
Hvis I planlægger en Delphi Modernisierung og ønsker at samle forretningslogik, dataadgang og drift i en afstemt plan, tal med os om en realistisk migrationssti: https://net-base-software-gmbh.de/kontakt/