Dienst · Software-ontwikkeling

Delphi-applicatie moderniseren.

Een grijze Windows-applicatie die al jaren meegaat, gebouwd in Delphi met Object Pascal en een Visual Component Library-interface die niemand meer durft aan te raken. De database eronder is een Paradox-bestand, een InterBase-server of een Firebird-installatie die nooit is bijgewerkt. Wij zetten er een moderne, webgebaseerde laag naast, gefaseerd en zonder dat de dagelijkse werkzaamheden stilvallen.

Plan een kennismaking Bekijk ons werk
↻

Een Delphi-applicatie is geen gewone legacy-software.

Delphi-toepassingen zijn te herkennen aan een vaste set kenmerken. Een lokaal geïnstalleerde .exe per werkstation, een typisch grijs VCL-scherm met vierkante knoppen, en een database die vrijwel nooit een moderne relationele server is maar een Paradox-bestand, een dBase-tabel of een InterBase- of Firebird-installatie die via de Borland Database Engine wordt aangesproken. Er is geen webtoegang, geen mobiele variant, en vaak is de applicatie gekoppeld aan één specifieke versie van Windows omdat drivers of de BDE-configuratie op een nieuwere versie niet meer werken.

Dat maakt vervangen van een Delphi-applicatie in de praktijk vaak urgenter dan bij een gemiddelde legacy-vervanging zoals we die beschrijven op legacy software vervangen. Het aantal developers dat nog actief met Object Pascal en de Visual Component Library werkt, is sterk gekrompen, en de applicatie draait doorgaans op één machine of één specifieke Windows-versie in plaats van op redundante infrastructuur. Valt die ene machine uit, dan valt vaak een compleet bedrijfsproces stil: administratie, planning, voorraad of productie.

Deze pagina is een verdieping op onze bredere aanpak voor legacy software moderniseren, specifiek toegesneden op wat Delphi-toepassingen lastig maakt: de gesloten VCL-architectuur, het gebrek aan koppelmogelijkheden, en een database-laag die zelden op een moderne manier benaderbaar is. Onze aanpak begint met begrijpen wat de applicatie precies doet, vóór we bepalen hoe en in welke volgorde we vervangen.

Hoe wij Delphi-trajecten aanpakken.

Strangler-eerst
Nieuwe web/API-laag naast de bestaande Delphi-app, functie voor functie overgenomen
Discovery-fase
Schermen, business-regels en databasestructuur eerst in kaart voor we bouwen
Data-eigenaarschap
Volledige migratie uit Paradox, InterBase of Firebird met validatie en rollback-pad
Build of buy
Per module beoordeeld, maatwerk waar het écht onderscheidt

Drie manieren om een Delphi-applicatie te moderniseren.

Welke route past hangt af van de omvang van de applicatie, het aantal schermen, de staat van de onderliggende database en het aantal externe systemen dat ermee praat. Onderstaande drie aanpakken dekken samen het overgrote deel van de Delphi-trajecten waar wij bij betrokken raken.

Aanpak 01

Strangler-pattern: nieuwe web/API-laag naast de Delphi-app

De standaardroute bij Delphi-trajecten

We bouwen een nieuwe web- en API-laag die naast de bestaande Delphi-applicatie draait en dezelfde onderliggende data en business-regels ontsluit. Functie voor functie, meestal beginnend bij de eenvoudigste schermen, leiden we gebruikers om naar de nieuwe laag. De Delphi-applicatie blijft intussen gewoon actief voor alles wat nog niet is overgenomen, en wordt pas uitgezet zodra de laatste functie is gemigreerd.

Voor uw team betekent dit dat er nooit een moment is waarop alles tegelijk verandert. Geen weekend waarin de administratie, planning of productie stilligt, geen all-or-nothing-risico, en ruimte om te wennen aan de nieuwe schermen terwijl de oude vertrouwde applicatie op de achtergrond nog bestaat voor wat nog niet klaar is.

Web/API-laagModule-voor-moduleParallel-draaienAnti-corruption layerFeature-parity-eerstGefaseerde uitrol
Aanpak 02

Data-migratie uit Paradox, InterBase of Firebird

De kern van elk Delphi-traject

De meeste Delphi-applicaties draaien op een Borland Database Engine-koppeling naar Paradox-tabellen of dBase-bestanden, of op een InterBase-server. Firebird is de open source-afsplitsing die begin jaren 2000 uit InterBase is voortgekomen en wordt in de praktijk vaak aangetroffen als latere vervanger, soms in een versie die al jaren niet meer is bijgewerkt. Wij beginnen met een data-audit: hoeveel tabellen en records er zijn, welke velden ontbreken of afwijken, en welke business-regels alleen impliciet in de Delphi-code zitten en niet in de database zelf.

Op basis daarvan bouwen we een migratiepad naar een moderne relationele database, met een validatiesuite die elke migratie-run vergelijkt met het origineel op aantallen, sleutelvelden en referentiële integriteit. De oude Paradox-, InterBase- of Firebird-omgeving houden we read-only beschikbaar als archief tot ruim na de cut-over, zodat een rollback-pad altijd openstaat.

Data-auditParadox/dBase-exportInterBase/Firebird-migratieValidatiesuiteReferentiële integriteitArchief-kopie
Aanpak 03

Lift-and-shift: API-laag om de bestaande Delphi-logica

Wanneer de Delphi-app deels nog mag blijven

Niet elk onderdeel van een Delphi-applicatie hoeft direct vervangen te worden. Soms is het voldoende om een API-laag om de bestaande logica en database heen te bouwen, zodat andere systemen en een nieuwe webinterface er via een schone interface mee kunnen praten zonder dat de onderliggende applicatie meteen herbouwd wordt. De Delphi-applicatie blijft dan op de achtergrond draaien, vaak op gevirtualiseerde of geïsoleerde infrastructuur zodat de afhankelijkheid van één fysieke machine wordt weggenomen.

De build-vs-buy-keuze maken we per module. Voor een standaardproces zoals boekhouding is er vaak geen reden om maatwerk te bouwen, daar is een geschikt pakket voor. Voor het stuk dat ooit in Delphi is gebouwd juist omdat het uw werkwijze uniek maakt, bouwen we gericht een moderne vervanging.

API-wrapperVirtualisatieBuild-vs-buyHybride landschapKoppel-laagMaatwerk-add-on

Wat u aan het einde heeft.

Een webgebaseerde applicatie die niet meer draait op de goodwill van één werkstation, één Windows-versie en één developer die de Delphi-code nog begrijpt.

Productie + staging

Twee omgevingen, in uw eigen cloud of bij ons gehost, uw keuze.

Codebase + architectuur-docs

Volledige source code, build-instructies en overzicht van alle gemaakte keuzes.

Migratie-rapport

Welke data uit Paradox, InterBase of Firebird is overgegaan, welke validaties zijn uitgevoerd.

Decommissioning-plan

Hoe en wanneer de Delphi-applicatie wordt uitgezet, en welk read-only-archief overblijft.

Beheer (optie)

Monitoring, backups, security-patches en doorontwikkeling onder een onderhoudscontract.

Wat een Delphi-applicatie herkenbaar maakt.

Vier kenmerken die Delphi-toepassingen net iets urgenter maken dan een gemiddelde legacy-vervanging, en waarin wij meestal eerst worden uitgenodigd voor een kennismakingsgesprek voor er iets concreets gepland wordt.

Platform

Eén Windows-versie, vaak één machine

De applicatie is gebouwd met de Visual Component Library en draait het beste, of soms alleen nog, op een specifieke Windows-versie met bijbehorende drivers en de Borland Database Engine geconfigureerd. Een upgrade van het besturingssysteem is een risico op zichzelf. Valt de machine uit, dan valt vaak een compleet proces stil.

Kennis

Bijna geen Delphi-developers meer te vinden

Object Pascal en de VCL zijn geen actieve keuze meer voor nieuwe projecten, waardoor het aanbod van developers die de taal en het framework nog goed kennen sterk is gekrompen. Een nieuwe ontwikkelaar inwerken op een oude Delphi-codebase kost meer tijd en moeite dan opnieuw bouwen op een moderne stack.

Database

Een Paradox-bestand of een oude InterBase- of Firebird-server

De data zit vaak in lokale Paradox-tabellen of dBase-bestanden die via de Borland Database Engine worden aangesproken, of in een InterBase- of Firebird-server die al jaren niet meer is bijgewerkt. Backups, replicatie en beveiligingspatches zijn op deze database-lagen doorgaans minimaal geregeld.

Koppelingen

Nauwelijks te koppelen met moderne systemen

Er is geen REST- of JSON-API, alleen bestandsexports, gedeelde mappen of handmatige overtypeacties naar andere systemen. Rapportages lopen vaak via QuickReport of Crystal Reports, waarvoor wij een aparte verdieping hebben op Crystal Reports vervangen. Elke koppeling die nu bestaat, is een handmatig proces dat bij vervanging opnieuw ontworpen moet worden.

Risico's die we expliciet adresseren.

Een Delphi-modernisering is geen technisch project, het is een verandering die uw operatie raakt. Vier risico-categorieën die we in elk traject bovenaan zetten.

Data

Dataverlies bij migratie uit Paradox of Firebird

Oude Paradox-tabellen en InterBase- of Firebird-databases bevatten vaak dubbele records, ontbrekende referenties en tekens die het oude systeem stilzwijgend tolereerde. Wij doen een data-audit vooraf, bouwen een validatiesuite die elke migratie-run vergelijkt met het origineel en houden een rollback-pad open tot ruim na de cut-over.

Functionaliteit

Functionaliteits-erosie en vergeten schermen

De Delphi-applicatie doet vaak nog iets waar niemand zich meer bewust van is: een nachtelijke export, een specifiek rapport voor de directie, een correctie-scherm dat maar één keer per kwartaal wordt geopend. We doen stakeholder-interviews per gebruikersgroep en draaien shadow-tests waarin oud en nieuw parallel dezelfde invoer verwerken.

Continuïteit

Business-disruptie tijdens cut-over

Omdat Delphi-applicaties vaak op één machine draaien, is het risico van een verstoorde overgang groter dan bij een gespreide, redundante omgeving. We faseren elke transitie zodat één deelproces tegelijk overgaat, plannen cut-overs in rustige periodes en houden een rollback-script paraat.

Adoptie

Weerstand van gebruikers gewend aan de oude schermen

Mensen die jarenlang met dezelfde VCL-schermen hebben gewerkt, ervaren een webinterface aanvankelijk als onwennig, ook als die objectief sneller en toegankelijker is. We betrekken sleutelgebruikers vanaf het begin, bouwen workflows die de oude sneltoetsen en volgorde respecteren en organiseren training zodat de overgang niet als verlies voelt.

Hoe een Delphi-moderniseringstraject loopt.

01Kennismaking→ 02Discovery→ 03Bouw & migratie→ 04Cut-over & beheer
Stap 01

Kennismaking

Welke Delphi-applicatie staat er, hoe oud is de code, welke database eronder, welke pijn is acuut. Vrijblijvend gesprek met IT en de afdelingen die de applicatie dagelijks gebruiken.

Stap 02

Discovery & architectuur

We documenteren de bestaande schermen en business-regels, interviewen eindgebruikers, doen een data-audit op Paradox, InterBase of Firebird en kiezen per module tussen strangler, lift-and-shift of volledige rewrite.

Stap 03

Bouw & data-migratie

Werkende modules in sprints, parallel draaiend naast de bestaande Delphi-applicatie, validatiesuite voor de data-migratie en regelmatige shadow-tests op echte invoer.

Stap 04

Cut-over & decommissioning

Gefaseerde overgang per deelproces, rollback-pad paraat, de Delphi-applicatie leegmaken en uiteindelijk uitzetten. Een read-only-archief van de oude database blijft beschikbaar.

Van Delphi, Paradox en Firebird naar een moderne stack.

Delphi is een ontwikkelplatform van oorspronkelijk Borland, later Embarcadero, gebaseerd op de programmeertaal Object Pascal met de Visual Component Library als GUI-framework. Databasetoegang liep van oudsher via de Borland Database Engine naar Paradox- en dBase-bestanden of naar InterBase, waarvan Firebird de open source-afsplitsing is. Vergelijkbare trajecten voeren we uit voor andere stacks uit dezelfde periode, zoals bij het vervangen van FoxPro-applicaties. Zie ook het bredere overzicht onder software-ontwikkeling als startpunt.

Delphi-stack die we aantreffen
Delphi / Object PascalVCLBorland Database EngineParadoxdBaseInterBaseFirebirdQuickReport / Crystal ReportsRAD Studio
Doelstack, frontend en backend
Next.jsAstroReactNode.jsPython.NET 8PostgreSQLRedis
Migratie, infra & koppeling
Strangler-routeringETL-pipelinesAPI-laagAuth0Azure ADGCP/AWSDockerAnti-corruption layer

Veelgestelde vragen.

Hoe herken ik of onze applicatie een Delphi-applicatie is?
Een aantal signalen komen bijna altijd terug: een grijze Windows-interface met vierkante knoppen en een typisch VCL-uiterlijk, een .exe die lokaal op elk werkstation geïnstalleerd staat, foutmeldingen die verwijzen naar de Borland Database Engine of een BDE-alias, en een database die bestaat uit Paradox-tabellen, dBase-bestanden of een InterBase- of Firebird-server. Vaak draait de applicatie al vele jaren zonder noemenswaardige aanpassingen aan de architectuur. Als dat bekend klinkt, is de kans groot dat u met Delphi te maken heeft.
Waarom is vervangen van een Delphi-applicatie vaak urgenter dan bij een modernere stack?
Een Delphi-applicatie is doorgaans strakker vastgeklonken aan één specifieke Windows-versie, één set drivers en soms zelfs één fysieke machine dan een gemiddelde webapplicatie. Het aantal developers dat nog actief met Object Pascal en de Visual Component Library werkt, is de afgelopen jaren sterk gekrompen, waardoor vervanging van personeel of uitbreiding van functionaliteit steeds moeilijker wordt. Daarbij komt dat een Delphi-applicatie zelden webtoegang of een mobiele variant heeft, terwijl de rest van uw softwarelandschap daar wel naartoe is bewogen. De combinatie van schaarse kennis, een kwetsbaar platform en ontbrekende toegankelijkheid maakt uitstel risicovoller dan bij nieuwere systemen.
Kunnen we tijdens de modernisering gewoon doorwerken met de bestaande Delphi-applicatie?
Ja. We werken vrijwel altijd volgens een strangler-pattern: er komt een nieuwe web- en API-laag naast de bestaande Delphi-applicatie, en functie voor functie wordt verkeer omgeleid naar de nieuwe laag zodra die klaar is. De oude applicatie blijft intussen gewoon draaien voor de onderdelen die nog niet zijn overgenomen. Uw team werkt dus nooit met een systeem dat in één keer wisselt, en er is geen moment waarop de hele operatie van één cut-over afhankelijk is.
Wat gebeurt er met onze data in Paradox, InterBase of Firebird?
We beginnen met een data-audit: hoeveel tabellen en records er zijn, welke velden ontbreken of zijn beschadigd, en welke business-regels impliciet in de Delphi-code verwerkt zitten in plaats van in de database zelf. Op basis daarvan bouwen we een migratiepad naar een moderne relationele database, met een validatiesuite die elke migratie-run vergelijkt met het origineel op aantallen, sleutelvelden en referentiële integriteit. De oude Paradox-, InterBase- of Firebird-database houden we read-only beschikbaar als archief tot ruim na de cut-over.
Is het mogelijk om alleen een webinterface toe te voegen zonder de hele Delphi-applicatie te vervangen?
Ja, dat is precies wat een lift-and-shift-aanpak inhoudt. We bouwen een API-laag om de bestaande Delphi-logica en -database heen, zodat andere systemen en een nieuwe webinterface er via een schone interface mee kunnen praten, zonder dat de onderliggende applicatie meteen herbouwd wordt. Dat is een goede tussenstap wanneer bepaalde onderdelen van de Delphi-applicatie nog een tijd mogen blijven draaien, of wanneer alleen externe toegankelijkheid het acute probleem is.
Wat als de oorspronkelijke Delphi-developer niet meer te vinden is?
Dat is bij Delphi-trajecten eerder regel dan uitzondering en geen blokkade. In de discoveryfase reverse-engineeren we de bestaande applicatie: analyse van de Object Pascal-broncode voor zover aanwezig, interviews met eindgebruikers over de daadwerkelijke workflows, en analyse van de databasestructuur om business-regels te reconstrueren die nergens gedocumenteerd zijn. Waar de broncode zelf ontbreekt, reconstrueren we het gedrag via de database en het geobserveerde gebruik, en zetten we shadow-tests op om afwijkingen zichtbaar te maken voor de cut-over.
Wat bepaalt de aanpak en omvang van een Delphi-moderniseringstraject?
De belangrijkste factoren zijn de omvang van de applicatie, het aantal schermen en rapportages, de staat van de onderliggende database, de hoeveelheid koppelingen met andere systemen, en de mate waarin de broncode en business-regels nog te doorgronden zijn. Een compacte Delphi-applicatie met een overzichtelijke Paradox- of Firebird-database is een ander traject dan een uitgebreid productiesysteem met tientallen schermen en koppelingen naar boekhouding, planning en voorraad. We geven na de discoveryfase een eerlijke inschatting van de aanpak en fasering, niet vooraf.
Behouden we eigenaarschap van de nieuwe software en data?
Ja, volledig. De code, infrastructuur, documentatie en credentials komen op uw naam te staan, in een repository die door u beheerd wordt of aan het einde van het traject aan u wordt overgedragen. Ook de gemigreerde data blijft volledig van u, met een gedocumenteerd exportformaat voor eventuele toekomstige migraties. Als u kiest voor onze beheerlaag na oplevering, blijft alle code en infrastructuur van u. Beheer is een dienst, geen vendor-lock-in.

Praat met ons over uw Delphi-applicatie.

Een kennismaking, vrijblijvend. We luisteren naar wat er nu draait, welke database eronder zit, waar het knelt en wat de aanleiding is om er nu wél naar te kijken, ook als blijkt dat vervanging op dit moment niet de juiste route is.

Plan een kennismakingMail fabian.vandijk@appfront.nl

Edit Content