Modernisera Delphi utan att förlora domänlogiken

Delphi-applikationer körs i många företag stabilt i åratal – och speglar exakt den affärslogik som säkrar intäkter, servicekvalitet och regelefterlevnad. Vid en modernisering handlar det därför sällan om en „ny yta“, utan om en kontrollerad vidareutveckling där regler, specialfall och historisk processkunskap bevaras.

I detta inlägg visar vi en praxisbaserad metod för att stegvis modernisera Delphi: från inventering över avkoppling av UI/dataåtkomst till teknisk modernisering (Unicode/64‑Bit, BDE-utfasning, API/tjänster) – inklusive säkring genom tester, övervakning och parallellkörning. Målet är en moderniserbar arkitektur, utan Big-Bang-omskrivning och utan logikförlust.

Moderniseringar misslyckas i praktiken sällan på grund av kompilatorn eller ett ramverk, utan på grund av felaktiga antaganden om systemets beteende. Under år växande Delphi-applikationer innehåller typiskt affärsregler i GUI-händelser, SQL i formulärlogik, varianter per kund/mandant, historiskt betingade specialfall samt integrationer som endast är dokumenterade „i drift“.

En Big-Bang-omskrivning tvingar fram att denna kunskap rekonstrueras – inklusive de fel som det gamla systemet längst inte längre gör. Ett bättre angreppssätt är att behandla affärslogiken som en tillgång: isolera, säkra, och modernisera sedan steg för steg.

En hållbar målbild för processkritiska B2B-system är inte „allt nytt“, utan en arkitektur som möjliggör förändring – utan att äventyra den löpande driften:

• klar separation av UI, domänlogik, dataåtkomst och integrationer
• mätbarhet och testbarhet (regression, logging, monitoring, reproducerbara builds)
• stegvis utbytbarhet (modernisera UI utan omedelbar DB-migrering – eller tvärtom)
• API-kapabilitet (t.ex. REST), för att ansluta portaler, mobila enheter eller systemintegrationer
• driftsäkra deployment med rollback-alternativ

Delphi lämpar sig väl för detta eftersom befintliga enheter och domänklasser kan återanvändas medan omgivningen moderniseras.

Innan kod ändras behövs en belastbar beslutsgrund – inte fullständig dokumentation. Dessa tre resultat har visat sig effektiva:

• Domänlogik-karta: kritiska use-cases, regler/beräkningar, varianter (mandanter/länder/kunder), gränssnitt, jobb/batchkörningar.
• Risikoprofil: särskilt feltåliga områden, datakvalitet, regulatoriska krav, driftens flaskhalsar (prestanda, stabilitet, underhållbarhet).
• Moderniserings-backlog: prioriterade paket efter affärsvärde och risk (vad måste vara stabilt, vad får ändras, vad kan vänta).

Detta gör modernisering planbar: med tydliga inkrement istället för ett enda „allt-eller-inget“-projekt.

För att affärslogik inte ska förändras „oavsiktligt“ behövs en säkring som fungerar oberoende av UI-refaktoriseringen. Typiska byggstenar:

• Characterization/Golden-Master-tester: befintligt beteende fryses med representativa in-/utdata (rapporter, beräkningar, processteg).
• Regressionstester på use-case-nivå: de affärskritiska flödena återskapas automatiserat eller halvautomatiserat.
• Telemetri: loggning, mätvärden och felbilder görs jämförbara före/efter en ändring.
• Parallellkörning & kontrollerad omställning: nya moduler körs bredvid befintligt system (Feature Toggles, pilotgrupper), med tydlig rollback-strategi.

Först när dessa säkerhetsnät finns på plats är den faktiska tekniska moderniseringen motiverad – eftersom risk och efterarbete minskar drastiskt.

Den vanligaste orsaken till logikförlust är sammanblandning av UI, datatillgång och affärsregler. Modernisering börjar därför med avkoppling – inte med byte av UI-ramverk.

Ett pragmatiskt mål är en 3-lagersstruktur:

• Presentation: VCL/FMX, Presenter/ViewModel, endast UI-nära validering (format, obligatoriska fält)
• Business: domänmodeller, tjänster, regler, tillståndslogik, beräkningar
• Data/Integration: repositories, databasåtkomst, adaptrar till ERP/DMS/CRM, REST-klienter, messaging

Praktisk regel: Affärsregler flyttas från OnClick/OnExit till domänservices. SQL flyttas från formulär till repositories. På så sätt blir logiken testbar och senare återanvändbar via UI, tjänster och jobb.

Vid Strangulation Pattern skapas nytt medvetet „vid sidan av“ det befintliga: nya funktioner implementeras redan i den avkopplade strukturen medan arvssystemet fortsätter att köras. Steg för steg tar det nya lagret över mer ansvar tills gamla delar kan tas bort.

Exempel (typiskt B2B):

• Ni extraherar orderlogiken till en domänservice.
• Det befintliga VCL-UI använder initialt samma service (ingen processbrytning).
• Parallellt skapas en REST-endpoint för en kundportal eller en integration.
• Efter stabilisering ersätts enskilda gamla formulär – utan att kärnlogiken behöver byggas om.

Så minskar ni projektrisk, bibehåller driftsförmåga och uppnår snabbt mätbar nytta (t.ex. API, prestanda, underhållbarhet).

Beroende på utgångsläge är dessa byggstenar ofta relevanta – avgörande är prioritering efter risk och affärsvärde:

• BDE/Legacy-DB-Zugriff ablösen: moderna drivrutiner/provider, rena transaktionsgränser, reproducerbara deployments.
• Unicode: stränghantering, databas/gränssnitt, tredjepartskomponenter.
• 64‑Bit: beroenden, minne/prestanda, externa bibliotek.
• API- und Service-Schicht: REST, Windows-/Linux-tjänster, integrationer.
• Build & Release: CI/CD, artefakthantering, signerade installatörer, rollback.

Viktigt: Dessa punkter bör idealiskt genomföras efter avkoppling och säkring – då kan ändringar verifieras säkert.

En fullständig omskrivning är i vissa fall motiverad – ofta är det dock den dyraste vägen för att få „modern teknik“. Dessa frågor hjälper vid bedömningen:

• Är affärslogiken fullständigt förstådd och testbar – eller ligger mycket kunskap implicit i driften?
• Finns det hårda deadlines (t.ex. plattformens slut, compliance) som utesluter parallellkörning?
• Hur stor är variationsbredden (kund-/mandantlogik)?
• Hur kritisk är tillgängligheten, och hur hög är toleransen för processförändringar?
• Vilka delar är verkligen „skyldiga“ (UI, databasåtkomst, integrationer, deployment) – och vilka är stabila?

I många B2B-scenarier leder en stegvis strategi snabbare till mätbara resultat, eftersom den kontrollerar risker och skyddar affärslogiken.

Delphi-moderniseringsaudit (för proceskritiska applikationer): Vi analyserar arkitektur, beroenden, riskområden och levererar en prioriterad roadmap för hur ni moderniserar utan att förlora affärslogiken.

• Input: kodbas (read-only), build-setup, 2–3 kärn-use-cases, systemomgivning (DB, integrationer).
• Resultat: affärslogik-/modulkarta, risk- och beroendeanalys, rekommenderad målarkitektur, genomförandeplan i inkrement inklusive säkring (tester/parallellkörning).
• Valfritt: Proof of Concept för avkoppling + första Golden-Master-testet.

Så får ni ett pålitligt beslutsunderlag innan budget och tid investeras i en riskfylld omskrivning.

Går det att modernisera Delphi utan att skriva om applikationen?
Ja. I många fall avkopplas först affärslogik och dataåtkomst, därefter moderniseras den tekniska plattformen. Det minskar risken och håller driften stabil.

Hur förhindrar man att affärslogiken ändras „tyst“?
Genom Golden-Master-/regressionstester, telemetri samt en kontrollerad parallellkörning med tydlig rollback-strategi.

Vilka åtgärder ger ofta snabbast nytta?
Transparens (Assessment), avkoppling av UI/SQL, BDE-ersättning och ett API-/servicelager för integrationer – var och en säkrad genom tester.

Hur lång tid tar en modernisering?
Det beror på kritiska use-cases, variationsmångfald och beroenden. En audit levererar typiskt på kort tid en tillförlitlig roadmap och prioriterade inkrement.