Veel bedrijven draaien al jaren of zelfs decennia stabiele Delphi-toepassingen die de kern van hun processen modelleren: orderverwerking, productie, service, logistiek, facturering, apparaatbeheer, documentworkflows. In deze systemen zit niet alleen code, maar een robuuste samenhang van domeinregels, datamodel, gebruikersinteractie en beheerervaring. Juist dat maakt modernisering complex: de echte waarde zit zelden in de gebruikersinterface, maar in de gegroeide domeinlogica.
Als modernisering wordt opgevat als „nieuw bouwen“, is verlies voorgeprogrammeerd. Niet omdat nieuwe technologieën per definitie slecht zouden zijn, maar omdat impliciete kennis uit het legacy-landschap — randgevallen, historische data, procesuitzonderingen, reglementaire details — bij de migratie vaak niet volledig kan worden gereconstrueerd. Het resultaat zijn dure regressiefouten, veranderde procestijden, acceptatieproblemen en een project dat langer loopt dan gepland.
Delphi laat zich echter heel goed moderniseren zonder de domeinlogica te verliezen. De sleutel is een gecontroleerde, stapsgewijze aanpak: eerst transparantie creëren (architectuur, data, risico’s), dan ontkoppelen (UI, data-access, domeinlogica), vervolgens moderniseren (databasetreiber, Unicode/64-bit, API’s, services, multiplatform) — en daarbij de lopende operatie borgen. Dit artikel beschrijft praktijkgerichte moderniseringspatronen, typische valkuilen en een werkwijze die werkt in B2B-omgevingen met hoge proceskritikaliteit.
Waarom Delphi-modernisering zelden een „technisch project“ is
In de praktijk mislukken moderniseringen niet door een ontbrekende compiler-flag, maar door verkeerde aannames over het systeemgedrag. Delphi-toepassingen die over jaren zijn uitgebreid, bevatten vaak:
- domeinregels in GUI-events (OnClick, OnExit, OnValidate), vaak verspreid over veel Forms
- SQL-statements „dicht bij de presentatie“ en al jaren geoptimaliseerd voor precies één database
- omwegen voor historische data, randgevallen, klantvarianten of tenant-logica
- batchprocessen die in de praktijk op vaste tijden draaien en afhankelijkheden hebben
- integraties met ERP, DMS, CRM of machines die nauwelijks zijn gedocumenteerd
- stille kennis in de vorm van bedieningsroutines: „Als fout X, controleer dan eerst Y“
Wie hier met een Big-Bang-rewrite begint, moet al die kennis opnieuw produceren — inclusief de fouten die de oude oplossing al lang niet meer maakt. De betere aanpak is om de domeinlogica als kapitaal te behandelen: eerst isoleren, dan borgen, daarna moderniseren.
Moderniseren zonder logicaverlies: doelbeeld en leidende principes
Een houdbaar doelbeeld voor B2B-systemen is geen „alles nieuw“, maar een architectuur die verandering mogelijk maakt. Typische kenmerken:
- Gescheiden verantwoordelijkheden (UI, domein/domeinlogica, data-access, integraties)
- Test- en meetbaarheid (regressietests, logging, monitoring, reproduceerbare builds)
- Stapsgewijze vervangbaarheid (UI moderniseren zonder direct het datamodel te herstructureren; DB migreren zonder UI opnieuw te schrijven)
- API-mogelijkheid (REST-Server of een serviceschil om portalen, mobiel en integraties aan te sluiten)
- Operationele betrouwbaarheid (Windows- en Linux-services, duidelijke deployments, rollbackstrategie)
In Delphi is dit bijzonder goed haalbaar, omdat u bestaande Units en domeinklassen kunt hergebruiken terwijl u de buitenkant moderniseert: data-access van BDE naar BDE-aflossing met native koppeling, nieuwe REST-endpoints, nieuwe UI-modules, nieuwe deployments.
Inventarisatie: wat moet echt behouden blijven?
Voordat code „aangeraakt“ wordt, loont een gestructureerde inventarisatie. Het doel is niet volledige documentatie, maar een betrouwbare beslisbasis.
1) Domeinlogica-kaart in plaats van code-lezemarathon
Praktisch heeft zich een domeinlogica-kaart bewezen met de volgende perspectieven:
- Use-cases: Welke kernprocessen zijn bedrijfskritisch? (bijv. order aanmaken, factuur, storno, retourzending, machineonderhoud, onderhoudscontract)
- Regels: Welke validaties, berekeningen, toestandsautomaten bestaan er?
- Varianten: tenants, klantconfiguraties, landspecifieke regels
- Schnittstellen: import/export, ERP/DMS/CRM, apparaten/protocollen
- Batch/jobs: nachtelijke runs, rapporten, dataconciliaties
Uit deze kaart ontstaan geprioriteerde moderniseringspakketten: wat moet stabiel blijven, wat mag veranderen, wat kan later volgen.
2) Technische schuld zichtbaar maken
Typische technische schuld in oudere Delphi-systemen:
- Borland BDE/Paradox-afhankelijkheden
- ANSI-strings/ontbrekende Unicode-migratie
- 32-bit-only, verouderde third-party componenten
- monolithische form-logica, globale variabelen, units met veel bijwerkingen
- onduidelijke transactiegrenzen en „SQL overal“
De kunst is deze punten niet dogmatisch te „opschonen“, maar in een volgorde te zetten die risico minimaliseert en businesswaarde maximaliseert.
Architectuurontkoppeling: het hefboomeffect tegen logicaverlies
De meest voorkomende oorzaak van logicaverlies is de vermenging van UI, data-access en domeinregels. Modernisering begint daarom met ontkoppeling — niet met een „nieuw UI-framework“.
Layer-3-architectuur als pragmatische doeltoestand
Voor veel Delphi-legacytoepassingen werkt een Layer-3-architectuur heel goed:
- Presentation Layer: VCL/FMX-Forms, ViewModels/Presenter, validatie alleen UI-dicht (formaat, verplichte velden)
- Business Layer: domeinmodellen, services, regels, toestandslogica, berekeningen
- Data/Integration Layer: repositories, SQL/ORM-delen, interface-adapters, REST-clients, messaging
Het voordeel: domeinlogica wordt testbaar en herbruikbaar. Later kan een klantenportaal, een REST-Server of een Windows- und Linux-Services precies dieselde domeinservices gebruiken. Zo moderniseert u de „buitenlaag“ zonder de kernlogica opnieuw uit te vinden.
Strangulation Pattern: het oude systeem stapsgewijs „omarmen“
Een beproefd migratiepatroon is het Strangulation Pattern: nieuwe functionaliteit ontstaat al in de nieuwe structuur (bijv. domeinservice + repository), terwijl bestaande Forms geleidelijk worden omgebouwd. De oude wereld blijft draaiend, maar wordt stukje bij beetje door de nieuwe vervangen.
Belangrijk is afhankelijkheden actief om te keren: niet „Form roept SQL“, maar „Form roept Service“, en de Service beslist. Deze kleine omkering is vaak de grootste winst.
Data-access moderniseren: BDE-aflossing en FireDAC zorgvuldig plannen
Een centraal moderniseringsstap is de BDE-aflossing. Bedrijven onderschatten hier vaak dat het niet alleen om drivers gaat, maar om SQL-semantiek, transacties, locking, datatypes en foutgedrag. Moderne Delphi-stacks zetten typisch in op BDE-Ablosung mit nativer Anbindung met native drivers (bijv. voor MariaDB/MySQL, PostgreSQL, SQL Server).
Wat bij de overstap echt besloten wordt
- Doeldatabase: Blijft het bij de bestaande DB? Is een databaseherontwerp zinvol (bijv. van Paradox/Firebird naar MariaDB of PostgreSQL)?
- Transactie-model: Waar beginnen/eindigen transacties? Welke use-cases moeten atomair zijn?
- Concurrency/locking: optimistisch vs. pessimistisch, omgaan met deadlocks, retry-strategieën
- SQL-dialect: datumfuncties, stringgedrag, NULL-handling, case-sensitivity
- Performance: indexen, queryplannen, paging, batch-inserts
De domeinlogica hangt nauw samen met het datagedrag. Wie de migratie „er even bij“ doet, loopt het risico op subtiele afwijkingen in de praktijk: afrondingen, sorteringen, datumgrenzen, lockingconflicten. Daarom hoort de data-laag vroeg in het moderniseringsplan, inclusief migratiepad en testdataplan.
Pragmatische stappen naar een FireDAC-migratie
In plaats van de volledige applicatie in één keer om te bouwen, heeft de volgende volgorde zich bewezen:
- Invoeren van een data-accesslaag (Repository/DAO) als façade
- Overzetten van individuele use-cases naar FireDAC (bijv. eerst „lezen“, later „schrijven“)
- Vereenvoudigen van connection-handling, foutafhandeling, logging
- Gefaseerd uitschakelen van BDE-componenten waar de façade stabiel is
Zo blijft de applicatie te allen tijde leverbaar en voorkomt u een lange periode waarin „alles half af“ is.
Unicode, 64-bit en afhankelijkheden: moderniseringsvallen in detail
Veel moderniseringen stranden niet op conceptniveau, maar op onderschatte detailonderwerpen. Drie daarvan komen in Delphi-projecten bijzonder vaak voor.
Unicode-migratie: niet alleen strings, maar datastromen
Bij zeer oude Delphi-versies stammen systemen uit een ANSI-wereld. Een Unicode-migratie betreft dan:
- Stringtypes en conversies (WideString/AnsiString/UnicodeString)
- Bestand- en padhandling (Windows-API, netwerkpaden)
- Import/export (CSV, fixed-width velden, EDI, legacy-interfaces)
- Sortering/collatie in de database
Beslissend is het identificeren van kritische datastromen (bijv. factuurteksten, artikelbenamingen, internationale adressen) en daar regressietests voor op te zetten. Unicode is minder een enkele „herbouw“ dan een doorlopend kwaliteitsproces.
64-bit overstap: geheugen is niet het enige onderwerp
De 64-bit overstap wordt vaak gereduceerd tot „pointergroottes“. In de praktijk gaat het vaker om:
- Verouderde third-party componenten zonder 64-bit support
- COM/ActiveX-afhankelijkheden
- DLLs en drivers (barcode, apparaten, cryptografie, handtekening)
- Installer/deployment en registerpaden (WOW64)
Een verstandige strategie is eerst alle externe afhankelijkheden inventariseren en alternatieven definiëren. Dan wordt de 64-bit stap planbaar — en geen verrassingspakket vlak voor release.
Windows 11 ARM64: vroeg controleren in plaats van laat betalen
Met Windows 11 ARM64 verschijnt een nieuwe klasse doelsystemen. Ook als niet elk bedrijf direct native ARM64-builds nodig heeft, is het verstandig om vroeg te controleren:
- Zijn er native afhankelijkheden (DLLs, drivers) die onder ARM64 niet draaien?
- Is de applicatie op emulatie aangewezen, en is dat acceptabel?
- Hoe ziet de installer eruit, hoe werkt update/repair?
In moderniseringsprojecten is dit typisch een „laat“ onderwerp dat dan duur wordt. Beter: vroeg in de platform-roadmap opnemen en technisch afkaderen.
REST-Server en services: domeinlogica bruikbaar maken voor portalen en integratie
Veel bedrijven moderniseren Delphi niet omdat de desktop-app „ouderwets“ oogt, maar omdat er nieuwe eisen ontstaan: klantenportaal, partnertoegangen, mobiele processen, integratie met ERP/DMS/CRM, reportingpipelines. Daarvoor zijn duidelijke interfaces nodig. Een REST-server is vaak de meest praktische brug.
API eerst? Alleen als rechten en domeinlogica meekomen
Een API levert alleen winst op als hij dezelfde domeinlogica afdwingt als de client. Anders ontstaan twee regelsets: één in de desktop, één in de backend. Gevolgen zijn inconsistenties en beveiligingslekken.
Daarom moet een REST-serverlaag bij voorkeur direct op domeinservices aansluiten. Typische bouwstenen:
- Authenticatie/autorisatie (rollen, tenants, rechten)
- DTOs/serialisatie met duidelijke versieerregels
- Transactie- en foutconcept (HTTP-status, Problem-Details, logging)
- Idempotentie en concurrentiegedrag (voor retries, queue-verwerking)
Zo wordt de REST-server het stabiele integratiepunt — niet de „tweede client“.
Linux-services en Windows-services moderniseren
Batchprocessen en integraties draaien in veel bedrijven als Windows-services, Task Scheduler-jobs of zelfs als „verborgen“ desktopinstanties. Bij modernisering loont consolidatie:
- UI en achtergrondlogica scheiden
- Configureerbare runtimeschema’s en duidelijke bedieningsparameters
- Schone logging (gestructureerde logs, correlatie per job/request)
- Optie om services onder Linux te draaien (bijv. voor containerized deployments)
Het voordeel is niet alleen „modern“, maar operationeel: reproduceerbare exploitatie, minder handmatige ingrepen, betere foutanalyse.
UI moderniseren zonder de kern aan te raken: VCL, FMX en hybride benaderingen
Veel moderniseringsplannen beginnen bij de UI. Dat kan zinvol zijn — mits helder is wat u ermee wint. Als de domeinlogica ontkoppeld is, laat de UI zich aanzienlijk minder risicovol vernieuwen.
VCL-toepassingen stapsgewijs moderniseren
VCL is in veel B2B-scenario’s nog steeds een robuuste keuze, zeker voor Windows-rijke omgevingen met hoge productiviteit op desktop. Modernisering kan hier betekenen:
- UI-logica reduceren (Presenter/ViewModel), domeinregels naar services verplaatsen
- Componentenlandschap opschonen, eigen controls consolideren
- Responsiveness verbeteren (async, achtergrondtaken, voortgang, annuleren)
- Toegankelijke bediening, consistente validatie, betere foutmeldingen
Dat levert merkbare waarde zonder de volledige interface opnieuw te schrijven.
Delphi multiplatform: wanneer FMX zinvol is
Als er echte multiplatform-eisen zijn (Windows, macOS, eventueel Linux in servicecontext), kan FMX een optie zijn. Beslissend is de verwachting: multiplatform vereist extra test- en integratiewerk (fonts, afdrukken, OS-dialogen, bestandssysteem, verpakking/deployment). De kosten zijn goed te begroten als de domeinlogica al in een schone laag ligt.
Eén veel gebruikte pragmatische route is hybride: VCL blijft voor de Windows-client, terwijl nieuwe frontends (portaal, mobiele app) via de REST-server komen. Zo ontstaat multiplatform over systeemgrenzen, niet via één enkele UI-stack.
Testing en regressie: hoe u domeinlogica „vastlegt“
„Domeinlogica verliezen“ betekent in de praktijk: het systeem levert in randgevallen andere resultaten. Dat is zelden direct zichtbaar, maar duur. Daarom is testbaarheid geen luxe, maar een moderniseringsinstrument.
Gouden use-cases en referentiedata
Bewezen heeft zich een set van „gouden“ use-cases: reële, kritische processen met gedefinieerde data en verwachte resultaten (bijv. de documentketen van offerte tot creditnota, of een onderhoudsopdracht met onderdelen en tijdregistraties). Deze worden als regressietests of op zijn minst als herhaalbare testscripts vastgelegd.
Belangrijk: niet alleen succespaden, maar ook typische foutpaden (lockingconflicten, ontbrekende rechten, incomplete stamdata, dubbele importbestanden).
Automatisering waar het grootste hefboomeffect zit
Niet elk legacyproject heeft direct 80% unit-testcoverage nodig. Hoge ROI ontstaat vaak bij:
- domeinservices (berekeningen, regels, toestandswisselingen)
- data-access met duidelijke contracts (mapping, SQL, transacties)
- API-tests (auth, rechten, versiebeheer)
Het doel is stabiliteit bij wijzigingen, niet academische metrics.
Werkwijze in de praktijk: een moderniseringsroadmap in fasen
Vanuit B2B-oogpunt moet modernisering leverbaar blijven. Een typische roadmap, gericht op risico’s, ziet er als volgt uit:
Fase 1: Analyse, doelarchitectuur, quick wins (2–6 weken)
- Systemkaart (modules, databases, interfaces, jobs, afhankelijkheden)
- Risikomatrix (BDE, third-party, 32/64-bit, Unicode, deployment)
- Definitie van de doelarchitectuur (Layer-3, serviceschil, API-strategie)
- Quick wins: buildproces stabiliseren, logging verbeteren, versiebeheer opschonen
Fase 2: Ontkoppelen van de domeinlogica (doorlopend, incrementeel)
- domeinservices identificeren en uit Forms halen
- repository-facades invoeren
- eerste regressietests voor kritische use-cases
Fase 3: Data-access/DB-laag moderniseren
- FireDAC invoeren, verbindings- en transactiesconcept vastleggen
- BDE-aflossing modulair uitvoeren (of databasemigratie met parallelle werking)
- performance- en lockinggedrag onder load testen
Fase 4: REST-Server en integraties toevoegen
- API met auth, rechten, versiebeheer
- portalen/integraties aansluiten zonder dubbele logica
- services voor batch en achtergrondprocessen consolideren
Fase 5: Platform- en UI-besluiten (64-bit, ARM64, multiplatform)
- 64-bit build, afhankelijkheden vervangen
- ARM64-compatibiliteit controleren/plannen
- UI-modernisering: VCL-refresh of FMX/hybride, op basis van businessnut
De volgorde is bewust zo gekozen dat u vroeg transparantie krijgt, vervolgens de kern stabiliseert en pas daarna zichtbare veranderingen grootschalig uitrolt. Zo daalt het risico en blijft de operatie planbaar.
Typische anti-patterns: wat moderniseringen onnodig duur maakt
Sommige patronen komen in audits en reddingsprojecten steeds terug:
- „We bouwen nieuw en nemen alleen features over“: leidt vrijwel altijd tot logicaverlies omdat randgevallen ontbreken.
- API als parallelle wereld: businessregels blijven in de client en worden in de backend opnieuw uitgevonden.
- Databasewissel zonder semantische tests: dezelfde data, maar ander gedrag (NULL, sortering, datumlogica).
- Te laat dependency-management: 64-bit/ARM64 strandt op een kleine DLL vlak voor Go-Live.
- „Refactoring eerst“ zonder doelbeeld: veel veranderingen, weinig meetbaar resultaat, hoge regressiekans.
De tegenhanger is altijd hetzelfde: eerst doelarchitectuur en risico’s helder krijgen, daarna incrementeel herbouwen, en daarbij domeinlogica testen en zichtbaar maken.
Conclusie: moderniseren betekent bewaren — en gericht uitbreiden
Delphi moderniseren zonder domeinlogica te verliezen is geen contradictie, maar een discipline. Bedrijven hoeven niet te kiezen tussen „alles behouden“ en „alles vervangen“. Met consequente architectuurscheiding (bijv. Layer-3), een gecontroleerde BDE-aflossing richting FireDAC, een API-strategie via REST-servers en een duidelijk plan voor Unicode, 64-bit en nieuwe platformen zoals Windows 11 ARM64 kan een gegroeid systeem stap voor stap in een toekomstvaste structuur worden overgebracht.
De cruciale stap is de domeinlogica als kernasset te behandelen: isoleren, testbaar maken, en pas dan moderniseren. Zo ontstaat een architectuur die portalen, services en multiplatform-eisen ondersteunt zonder de lopende operatie te riskeren.
Als u een Delphi modernisering plant en daarbij domeinlogica, data-access en operatie zorgvuldig wilt samenbrengen, spreek met ons over een realistisch migratiepad: https://net-base-software-gmbh.de/kontakt/