Många företag driver sedan år eller decennier stabila Delphi-applikationer som beskriver kärnan i deras processer: orderhantering, produktion, service, logistik, fakturering, enhetshantering, dokumentarbetsflöden. I dessa system finns inte bara kod, utan ett robust samspel mellan affärsregler, datamodell, användarstyrning och driftserfarenhet. Det är just detta som gör modernisering utmanande: det verkliga värdet ligger sällan i gränssnittet, utan i den växande affärslogiken.
Om modernisering förstås som att ”bygga nytt” är förlusten förprogrammerad. Inte därför att nya teknologier per definition skulle vara dåliga, utan därför att implicit kunskap i det gamla systemet – specialfall, historiska data, processexceptioner, regulatoriska detaljer – vid flytt ofta inte går att rekonstruera fullständigt. Resultatet blir dyra regressionsfel, ändrade processtider, acceptansproblem och ett projekt som drar ut på tiden.
Delphi kan dock moderniseras mycket väl utan att tappa affärslogiken. Nyckeln är ett kontrollerat, stegvis tillvägagångssätt: först skapa transparens (arkitektur, data, risker), sedan avkoppla (UI, dataåtkomst, domänlogik), därefter modernisera (databasdrivrutiner, Unicode/64-bit, APIs, tjänster, multiplattform) – och samtidigt säkra den löpande driften. Denna artikel beskriver praktiskt användbara moderniseringsmönster, typiska fallgropar och en arbetsgång som fungerar i B2B-miljöer med hög processkritikalitet.
Varför Delphi-modernisering sällan är ett „teknikprojekt“
I verkligheten misslyckas moderniseringar inte på grund av en saknad compiler-flagga, utan av felaktiga antaganden om systemets beteende. Delphi-applikationer som byggts ut över år innehåller ofta:
- Affärsregler i GUI-events (OnClick, OnExit, OnValidate), ofta spridda över många forms
- SQL-satser „nära ytan“ och optimerade under år för exakt en databas
- Omgångar för historiska data, specialfall, kundvarianter eller klientlogik
- Batch-processer som i praktiken körs vid fasta tidpunkter och har beroenden
- Integrationer mot ERP, DMS, CRM eller maskiner som knappt är dokumenterade
- Tyst kunskap i form av driftprocedurer: „Vid fel X, kontrollera först Y“
Den som börjar med en Big-Bang-omskrivning måste återskapa all denna kunskap – inklusive de fel som den gamla lösningen länge inte längre orsakar. Ett bättre tillvägagångssätt är att behandla affärslogiken som en tillgång: först isolera, sedan säkra, därefter modernisera.
Modernisering utan logikförlust: målbild och ledprinciper
En hållbar målbild för B2B-system är inte „allt nytt“, utan en arkitektur som möjliggör förändring. Typiska egenskaper:
- Skilda ansvarsområden (UI, domän/affärslogik, dataåtkomst, integrationer)
- Test- och mätbarhet (regressionstester, logging, övervakning, reproducerbara builds)
- Stegvis utbytbarhet (uppdatera UI utan att omedelbart förändra datamodellen; migrera DB utan att skriva om UI)
- API-förmåga (REST-Server eller en tjänstelager för att koppla portaler, mobil och integrationer)
- Betriebsfähigkeit (Windows- och Linux-Services, tydliga deploys, rollback-strategi)
I Delphi är detta särskilt väl genomförbart, eftersom ni kan återanvända befintliga units och domänklasser medan ni moderniserar runtom: dataåtkomst från BDE till BDE-Ablösung mit nativer Anbindung, nya REST-endpoints, nya UI-moduler, nya deploys.
Inventering: Vad måste verkligen bevaras?
Innan kod „rörs“ är en strukturerad inventering värdefull. Målet är inte fullständig dokumentation, utan en robust underlagsbas för beslut.
1) Affärslogik-karta istället för kodläsningsmaraton
Praktiskt har en affärslogik-karta med följande perspektiv visat sig fungera:
- Användningsfall: Vilka kärnflöden är affärskritiska? (t.ex. skapa order, faktura, kreditnota, returleverans, maskinservice, serviceavtal)
- Regler: Vilka valideringar, beräkningar, tillståndsmaskiner finns?
- Varianter: Klienter, kundkonfigurationer, landspecifika regler
- Gränssnitt: Import/export, ERP/DMS/CRM, enheter/protokoll
- Batch/Jobs: nattkörningar, rapporter, dataavstämningar
Ur denna karta uppstår prioriterade moderniseringspaket: vad som måste vara stabilt, vad som kan förändras och vad som kan vänta.
2) Gör teknisk skuld synlig
Typiska tekniska skulder i äldre Delphi-system:
- Borland BDE/Paradox-beroenden
- ANSI-strängar/avsaknad Unicode-migrering
- Endast 32-bit, föråldrade tredjepartskomponenter
- Monolitisk formlogik, globala variabler, units med biverkningar
- Otydliga transaktionsgränser och „SQL överallt“
Konsten är att inte dogmatiskt „rensa bort“ dessa punkter, utan att ordna dem i en sekvens som minimerar risk och maximerar affärsvärde.
Arkitektur-avkoppling: hävstången mot logikförlust
Den vanligaste orsaken till logikförlust är en sammanblandning av UI, dataåtkomst och affärsregler. Modernisering börjar därför med avkoppling – inte med ett nytt UI-ramverk.
Layer-3-arkitektur som ett pragmatiskt mål
För många Delphi-beståndsapplikationer fungerar en Layer-3 Architektur mycket väl:
- Presentation Layer: VCL/FMX-forms, ViewModels/Presenter, validering endast UI-nära (format, obligatoriska fält)
- Business Layer: domänmodeller, tjänster, regler, tillståndslogik, beräkningar
- Data/Integration Layer: repositories, SQL/ORM-delar, gränssnittsadapter, REST-clients, messaging
Vinsten: affärslogik blir testbar och återanvändbar. Senare kan ett kundportal, en REST-Server eller en Linux-tjänst exakt använda samma domänservices. På så sätt moderniserar ni „yttre skiktet“ utan att uppfinna om kärnlogiken.
Strangulation Pattern: det gamla systemet stegvis „omfamnas“
En beprövad migrationsstrategi är Strangulation Pattern: nya funktioner byggs i den nya strukturen (t.ex. domänservice + repository), samtidigt som befintliga forms successivt byggs om. Den gamla världen förblir körbar men ersätts bit för bit av den nya.
Viktigt är att aktivt vända beroenden: inte „Form anropar SQL“, utan „Form anropar Service“, och service avgör. Denna lilla inversion ger ofta störst nytta.
Modernisera dataåtkomst: BDE-Ablösung och FireDAC noggrant planerade
En central moderniseringsåtgärd är BDE-Ablösung. Företag underskattar ofta att det inte bara handlar om drivrutiner utan om SQL-semantik, transaktioner, låsning, datatyper och felbeteende. Moderna Delphi-stackar bygger typiskt på BDE-Ablosung mit nativer Anbindung med nativa drivrutiner (t.ex. för MariaDB/MySQL, PostgreSQL, SQL Server).
Vad som verkligen måste beslutas vid omställningen
- Måldatabas: Blir det samma DB? Är en databasmigration meningsfull (t.ex. från Paradox/Firebird till MariaDB eller PostgreSQL)?
- Transaktionsmodell: Var börjar/slutar transaktioner? Vilka use-cases måste vara atomiska?
- Concurrency/Låsning: Optimistiskt vs. pessimistiskt, hantering av deadlocks, retry-strategier
- SQL-dialekt: datumfunktioner, strängbeteende, NULL-hantering, case-sensitivity
- Prestanda: index, query-planer, paging, batch-inserts
Affärslogiken är tätt bunden till databashanteringen. Den som migrerar „vid sidan om“ riskerar subtila avvikelser i praktiken: avrundningar, sorteringsskillnader, datumgränser, låskonflikter. Därför bör data-nivån komma tidigt i moderniseringsplanen, inklusive migrationsväg och testdata-strategi.
Pragmatiska steg för FireDAC-migration
I stället för att bygga om hela applikationen i ett svep har följande ordning visat sig framgångsrik:
- Inför en dataåtkomstlager (Repository/DAO) som fasad
- Byt över enskilda use-cases till FireDAC (t.ex. „läsa“ först, „skriva“ senare)
- Standardisera connection-hantering, felhantering och logging
- Fasvis avställning av BDE-komponenter när fasaden är stabil
Så förblir applikationen leveransbar hela tiden, och ni undviker en lång period där „allt är halvt färdigt“.
Unicode, 64-bit och beroenden: moderniseringsfällorna i detalj
Många moderniseringar fallerar inte på konceptnivå utan på underskattade detaljfrågor. Tre av dem är särskilt vanliga i Delphi-projekt.
Unicode-migrering: Inte bara strängar utan dataflöden
I mycket gamla Delphi-versioner härstammar systemen från en ANSI-värld. En Unicode-migrering berör då:
- Strängtyper och konverteringar (WideString/AnsiString/UnicodeString)
- Fil- och sökvägshantering (Windows-API, nätverkssökvägar)
- Import/export (CSV, fasta fältlängder, EDI, legacy-gränssnitt)
- Sortering/kollation i databasen
Avgörande är att identifiera kritiska dataflöden (t.ex. fakturatexter, artikelbenämningar, internationella adresser) och sätta upp regressionstester för dessa. Unicode är mindre en ren „ombyggnad“ än en genomgripande kvalitetsprocess.
Övergång till 64-bit: minne är inte enda frågan
Övergången till 64-bit reduceras ofta till „pekarestorlek“. I praktiken handlar det snarare om:
- Föråldrade tredjepartskomponenter utan 64-bit-stöd
- COM/ActiveX-beroenden
- DLL:er och drivrutiner (streckkod, enheter, kryptografi, signaturer)
- Installations-/deployflöden och registervägar (WOW64)
En rimlig strategi är att först inventera alla externa beroenden och definiera alternativ. Då blir 64-bit-steget planerat – inte en överraskning strax före release.
Windows 11 ARM64: Kontrollera tidigt istället för att betala sent
Med Windows 11 ARM64 dyker en ny klass av målplattformar upp. Även om inte alla företag omedelbart behöver native ARM64-byggen är det klokt att tidigt göra följande kontroller:
- Finns det native-beroenden (DLL:er, drivrutiner) som inte körs på ARM64?
- Är applikationen beroende av emulering, och är det acceptabelt?
- Hur ser installern ut, hur fungerar uppdatering/repair?
I moderniseringsprojekt är detta typiskt ett „sent“ ämne som blir dyrt. Bättre att tidigt ta in det i plattformsroadmapen och tekniskt klarlägga frågorna.
REST-Server och tjänster: gör affärslogik tillgänglig för portaler och integration
Många företag moderniserar inte Delphi för att desktop-appen ser gammal ut, utan för att nya krav uppstår: kundportal, partneråtkomst, mobila processer, integration med ERP/DMS/CRM, rapporteringspipelines. Det kräver tydliga gränssnitt. En REST-server är ofta den mest praktiska bryggan.
API först? Endast om rättigheter och domänlogik följer med
En API är bara en fördel om den genomdriver samma affärslogik som klienten. Annars uppstår två regelverk: ett i desktopklienten och ett i backend. Konsekvenserna blir inkonsistenser och säkerhetsbrister.
Därför bör en REST-server-lager helst lägga sig direkt på domänservices. Typiska byggstenar:
- Autentisering/auktorisation (roller, klienter, rättigheter)
- DTOs/serialisering med tydliga versioneringsregler
- Transaktions- och felkoncept (HTTP-status, Problem-Details, logging)
- Idempotens och samtidighet (för retries, köbearbetning)
Så blir REST-servern en stabil integrationspunkt – inte en „andra klient“.
Modernisera Linux-tjänster och Windows-tjänster
Batch-processer och integrationer körs i många företag som Windows-tjänster, Task Scheduler-jobs eller till och med „dolda“ desktopinstanser. Vid modernisering är konsolidering värdefull:
- Separera UI från bakgrundslogik
- Konfigurerbara körscheman och tydliga driftsparametrar
- Ren logging (strukturerade loggar, korrelation per jobb/request)
- Möjlighet att köra tjänster under Linux (t.ex. för containeriserad deployment)
Genvinsten är inte bara „modern“ utan operationell: reproducerbar drift, färre manuella ingripanden, bättre felsökning.
UI-modernisering utan att röra kärnan: VCL, FMX och hybrida angreppssätt
Många moderniseringsplaner börjar vid UI. Det kan vara rimligt – så länge målet med förändringen är klart. Om affärslogiken är avkopplad går UI-uppdateringen betydligt mindre riskfylld.
VCL-applikationer moderniseras stegvis
VCL är i många B2B-scenarier fortfarande ett robust val, särskilt i Windows-tunga miljöer med hög desktopproduktivitet. Modernisering kan innebära:
- Minska UI-logik (Presenter/ViewModel), flytta affärsregler till tjänster
- Rensa komponentlandskapet, konsolidera egna controls
- Förbättra responsivitet (asynkront, bakgrundsjobb, progress, avbryt)
- Tillgänglighetsanpassning, konsekvent validering, bättre felmeddelanden
Det ger märkbar nytta utan att skriva om hela ytan.
Delphi multiplattform: när FMX är meningsfullt
Om verkliga multiplattformskrav finns (Windows, macOS, eventuellt Linux i tjänstekontext) kan FMX vara ett alternativ. Avgörande är förväntningen: multiplattform innebär mer test- och integrationsarbete (teckensnitt, utskrift, OS-dialoger, filsystem, paketering/deployment). Kostnaderna är väl kalkylerbara om affärslogiken redan ligger i ett rent lager.
Ett vanligt pragmatiskt tillvägagångssätt är hybrid: VCL kvar för Windows-klienten, medan nya frontend (portal, mobilapp) ansluts via REST-servern. På så sätt uppnås multiplattform över systemgränser, inte genom ett enda UI-stack.
Testning och regression: Hur man säkrar affärslogiken
Att „förlora affärslogik“ innebär i praktiken att systemet levererar andra resultat i kantfall. Det är sällan omedelbart synligt men dyrt. Därför är testbarhet inte en lyx utan ett verktyg för modernisering.
Gyllene användningsfall och referensdata
Beprövat är ett set av „gyllene“ användningsfall: verkliga, kritiska flöden med definierad datamängd och förväntade resultat (t.ex. verifikationskedja från offert till kreditnota, eller ett underhållsjobb med reservdelar och tidrapportering). Dessa etableras som regressionstester eller åtminstone som reproducerbara testrutiner.
Viktigt: inte bara framgångsscenarier utan även typiska felvägar (låskonflikter, saknade rättigheter, ofullständiga stamdata, dubbla importfiler).
Automatisera där det ger störst effekt
Inte varje legacy-projekt behöver omedelbart 80% enhetstesttäckning. Hög avkastning uppstår ofta i:
- Domänservices (beräkningar, regler, tillståndsbyten)
- Dataåtkomst med tydliga kontrakt (mapping, SQL, transaktioner)
- API-tester (auth, rättigheter, versionering)
Målet är stabilitet vid förändringar, inte akademiska mått.
Tillämpningsmodell i praktiken: en moderniseringsfärdplan i etapper
Ur B2B-perspektiv måste modernisering vara leveransbar. En typisk färdplan som är riskorienterad ser ut så här:
Etapp 1: Analys, målarkitektur, snabba förbättringar (2–6 veckor)
- Systemkarta (moduler, databaser, gränssnitt, jobb, beroenden)
- Riskmatris (BDE, tredjepart, 32/64-bit, Unicode, deployment)
- Definition av målarkitektur (Layer-3, tjänstelager, API-strategi)
- Snabba förbättringar: stabilisera build-process, förbättra logging, städa versionshantering
Etapp 2: Avkoppling av affärslogiken (löpande, inkrementellt)
- Identifiera domänservices och flytta ut dem ur forms
- Införa repository-fasader
- Första regressionstesterna för kritiska användningsfall
Etapp 3: Modernisera dataåtkomst/DB-lager
- Inför FireDAC, etablera anslutnings- och transaktionskoncept
- BDE-Ablösung modulvis (eller databasmigration med parallellkörning)
- Testa prestanda och låsbeteende under belastning
Etapp 4: Bygg ut REST-server och integrationer
- API med auth, rättigheter, versionering
- Anslut portaler/integrationer utan att duplicera logik
- Konsolidera tjänster för batch och bakgrundsprocesser
Etapp 5: Plattform- och UI-beslut (64-bit, ARM64, multiplattform)
- 64-bit builds, ersätt beroenden
- Planera/undersök ARM64-kompatibilitet
- UI-modernisering: VCL-uppfräschning eller FMX/hybrid, baserat på affärsnytta
Ordningen är medvetet vald så att ni tidigt får transparens, sedan stabiliserar kärnan och först därefter rullar ut synliga förändringar. Så minskar risken och driften förblir planbar.
Typiska anti-mönster: vad som gör moderniseringar onödigt dyra
Vissa mönster återkommer i revisioner och räddningsprojekt:
- „Vi bygger nytt och tar bara över features“: leder nästan alltid till logikförlust eftersom specialfall saknas.
- API som parallellvärld: affärsregler lämnas i klienten och uppfinns på nytt i backend.
- Databasbyte utan semantiska tester: samma data men annorlunda beteende (NULL, sortering, datumlogik).
- För sent dependency-management: 64-bit/ARM64 fallerar på en liten DLL strax före Go-Live.
- „Refactoring först“ utan målbild: många ändringar, liten mätbar nytta, hög regression.
Motsatsen är alltid densamma: klarlägg målarkitektur och risker först, bygg sedan inkrementellt, testa och gör affärslogiken synlig.
Slutsats: Modernisering betyder bevara – och målmedvetet utöka
Att modernisera Delphi utan att förlora affärslogik är inget motsatsförhållande utan en disciplin. Företag behöver inte välja mellan att „behålla allt“ och att „ersätta allt“. Med ren arkitekturseparation (t.ex. Layer-3), en kontrollerad BDE-Ablösung mot FireDAC, en API-strategi via REST-server samt en tydlig plan för Unicode, 64-bit och nya plattformar som Windows 11 ARM64 kan ett växt system successivt föras över till en framtidssäker struktur.
Avgörande är att behandla affärslogiken som kärnasset: isolera, gör testbar, och modernisera därefter. Så uppstår en arkitektur som stöder portaler, tjänster och multiplattformsbehov utan att riskera den löpande driften.
Om ni planerar en Delphi Modernisierung och vill föra samman affärslogik, dataåtkomst och drift på ett kontrollerat sätt, prata med oss om en realistisk migrationsväg: https://net-base-software-gmbh.de/kontakt/