Mange verksemder driv i årevis eller tiår stabile Delphi-applikasjonar som dekkjer kjernen i prosessane deira: ordrehandsaming, produksjon, service, logistikk, avrekning, utstyrsforvaltning, dokumentarbeidsflytar. I desse systema finst ikkje berre kode, men eit robust samspel av fagreglar, datamodell, brukarleiing og driftserfaring. Det er nettopp dette som gjer modernisering utfordrande: den reelle verdien ligg sjeldan i grensesnittet, men i den veksne faglogikken.
Om modernisering blir forstått som «å bygge nytt», er tapet forprogramert. Ikkje fordi nye teknologiar per se er dårlege, men fordi implisitt kunnskap frå det gamle systemet – unntakstilfelle, historiske data, prosessavvik, regulatoriske detaljar – ved flytting ofte ikkje blir fullstendig rekonstruerte. Resultatet er dyre regresjonsfeil, endra prosesstider, akseptansproblem og eit prosjekt som varar lenger enn planlagt.
Delphi let seg likevel godt modernisere utan å miste faglogikken. Nøkkelen er ein kontrollert, trinnvis tilnærming: først skape transparens (arkitektur, data, risiko), så kopla frå (UI, datatilgang, domeneloggikk), deretter modernisere (database-drivarar, Unicode/64-bit, API-ar, tenester, multiplattform) – og samtidig sikre løpande drift. Denne artikkelen skisserer praktiske moderniseringsmønster, typiske fallgruver og eit framgangssett som fungerer i B2B-miljø med høg prosesstebilitet.
Kvarfor Delphi-modernisering sjeldan er eit «teknikkprosjekt»
I praksis feiler moderniseringar ikkje på manglande compiler-flag, men på feilaktige antakingar om systemåtferd. Delphi-applikasjonar som er blitt utvida gjennom år inneheld ofte:
- Fagreglar i GUI-hendingar (OnClick, OnExit, OnValidate), ofte spreidde over mange forms
- SQL-setningar «nært overflata» og i årevis optimalisert for nettopp ei database
- Omvegar for historiske data, særtilfelle, kundevariasjonar eller tenants-logikk
- Batch-prosessar som i praksis køyrer til faste tidspunkt og har avhengigheiter
- Integrasjonar mot ERP, DMS, CRM eller maskinar som knapt er dokumenterte
- Stille kunnskap i form av driftsrutinar: «Ved feil X, sjå først på Y»
Kven som startar med eit Big-Bang-rewrite må produsere all denne kunnskapen på nytt – inklusive feila den gamle løysinga lenge har unngått. Ein betre strategi er å handsame faglogikken som ein verdi: først isolere, så sikre, deretter modernisere.
Modernisering utan logiktap: målbilde og leiande prinsipp
Eit berekraftig målbilete for B2B-system er ikkje «alt nytt», men ei arkitektur som legg til rette for endring. Typiske eigenskapar:
- Separa ansvar (UI, domene/faglogikk, datatilgang, integrasjonar)
- Test- og målbarheit (regresjonstestar, logging, overvaking, reproduserbare bygg)
- Trinnvis utskiftbarheit (modernisere UI utan å riva opp datamodellen med ein gong; migrere DB utan å skrive om UI)
- API-moglegheit (REST-Server eller ein tenestelag for å knyte til portal, mobil og integrasjonar)
- Driftsevne (Windows- og Linux-tenester, klare deployment-prosessar, rollback-strategi)
I Delphi er dette særleg oppnåeleg, fordi du kan gjenbruke eksisterande units og domeneklassar medan du moderniserer rundt dei: datatilgang frå BDE til BDE-Ablösung med nativer tilkoplingar, nye REST-endepunkt, nye UI-modular, nye deployment-enheter.
Bestandsoversikt: kva må verkeleg bevarast?
Før kode blir «tatt på», løner det seg med ei strukturert bestandsoversikt. Målet er ikkje full dokumentasjon, men eit robust grunnlag for avgjersler.
1) Faglogikk-kart i staden for kode-lesemaraton
Praktisk erfaring viser at eit faglogikk-kart med følgjande perspektiv fungerer godt:
- Use-cases: Kva kjerneflytar er forretningskritiske? (t.d. opprette ordre, fakturere, kreditnota, returleveranse, maskinservice, vedlikehaldsavtale)
- Reglar: Kva valideringar, utrekningar, tilstandsmaskinar finst?
- Variantar: Tenantar, kundekonfigurasjonar, lands-spesifikke reglar
- Grensesnitt: Import/eksport, ERP/DMS/CRM, utstyr/protokollar
- Batch/Jobbar: nattlege køyringar, rapportar, datasykronisering
Frå dette kartet kjem prioriterte moderniseringspakke: kva må vere stabilt, kva kan endrast, kva kan venta på.
2) Gjere teknisk gjeld synleg
Typisk teknisk gjeld i eldre Delphi-system:
- Borland BDE/Paradox-avhengigheiter
- ANSI-strengar/manglande Unicode-migrasjon
- 32-bit-only, utdaterte tredjeparts-komponentar
- Monolittisk form-logikk, globale variablar, units med mange sideeffekt
- Uklare transaksjonsavgrensingar og «SQL overalt»
Kunsten er å ikkje handtere desse punkta dogmatisk, men å setje dei i ei rekkjefølgje som minimerer risiko og maksimerer forretningsverdi.
Arkitektur-avkopling: spaken mot logiktap
Den vanlegaste årsaka til logiktap er samblanding av UI, datatilgang og fagreglar. Modernisering startar difor med avkopling – ikkje med «nytt UI-rammeverk».
Layer-3-arkitektur som pragmatisk måltilstand
For mange Delphi-bestandsapplikasjonar fungerer ei Layer-3 Architektur svært godt:
- Presentation Layer: VCL/FMX-Forms, ViewModels/Presenter, validering berre UI-nært (format, obligatoriske felt)
- Business Layer: domenemodellar, tenester, reglar, tilstandlogikk, utrekningar
- Data/Integration Layer: repositories, SQL/ORM-delar, grensesnittadapterar, REST-clients, messaging
Gevinsten: faglogikk blir testbar og gjenbrukbar. Seinare kan eit kundesenter/portal, ein REST-Server eller ein Linux-teneste bruke nøyaktig dei same domenetenestene. På den måten moderniserer du «utsida» utan å finne opp kjernelogikken på nytt.
Strangulation Pattern: omfamne det gamle systemet trinnvis
Eit etablert migrasjonsmønster er Strangulation Pattern: nye funksjonar blir implementerte i den nye strukturen (t.d. domeneteneste + repository), medan eksisterande forms gradvis blir bytte ut. Den gamle verda held seg i drift, men blir bit for bit erstatta av ny funksjonalitet.
Viktig her er å snu avhengigheitene aktivt: ikkje «form kalllar SQL», men «form kalllar service», og servicen tar avgjerda. Denne simple inversjonen er ofte den største vinsten.
Modernisere datatilgang: BDE-Ablösung og FireDAC planleggast nøye
Eit sentralt moderniseringstrinn er BDE-Ablösung. Verksemder undervurderer ofte at det ikkje berre handlar om drivarar, men om SQL-semantikk, transaksjonar, locking, datatypar og feilåtferd. Moderne Delphi-stakkar brukar typisk BDE-Ablosung mit nativer Anbindung med native drivarar (t.d. for MariaDB/MySQL, PostgreSQL, SQL Server).
Kva som verkeleg blir avgjort ved omstilling
- Databasemål: Blir ein verande på eksisterande DB? Er ein databasemigrasjon fornuftig (t.d. frå Paradox/Firebird til MariaDB eller PostgreSQL)?
- Transaksjonsmodell: Kor startar/stoppar transaksjonane? Kva use-cases må vere atomiske?
- Concurrency/Locking: Optimistisk vs. pessimistisk, handtering av deadlocks, retry-strategiar
- SQL-dialekt: datumsfunksjonar, strenghandtering, NULL-handtering, case-sensitivitet
- Ytelse: indeksar, query-planar, paging, batch-inserts
Faglogikken heng tett saman med datatferda. Den som migrerer «ved sidan av» risikerer subtile avvik i praksis: avrunding, sorteringsrekkefølgje, datumsgrenser, låsekonfliktar. Difor må data-nivået kome tidleg inn i moderniseringsplanen, inkludert migrasjonsveg og testdatastrategi.
Pragmatiske steg mot FireDAC-migrasjon
I staden for å skriva om heile applikasjonen i eitt kast, har fylgjande rekkjefølgje vist seg nyttig:
- Innføre eit datatilgangslag (Repository/DAO) som fasade
- Bytte enkelte use-cases til FireDAC (t.d. «lese» først, «skrive» seinare)
- Standardisere connection-handling, feilhandtering, logging
- Gradvis slå av BDE-komponentar der fasaden er stabil
Slik held applikasjonen seg leveringsdyktig til kvar tid, og du unngår lange periodar der «alt er halvferdig».
Unicode, 64-bit og avhengigheiter: detaljfallgruvene i moderniseringa
Mange moderniseringar strandar ikkje på konseptet, men på undervurderte detaljar. Tre slike tema går igjen i Delphi-prosjekt.
Unicode-migrasjon: ikkje berre strengtypar, men dataflyt
I svært gamle Delphi-versjonar stammar systema frå ei ANSI-verda. Ein Unicode-migrasjon omfattar då:
- Strengtypar og konverteringar (WideString/AnsiString/UnicodeString)
- Fil- og banehandtering (Windows-API, nettverksstiar)
- Import/eksport (CSV, faste feltdimensjonar, EDI, legacy-grensesnitt)
- Sortering/kollasjon i databasen
Avgjerande er å identifisere kritiske dataflytar (t.d. fakturatekster, varenamn, internasjonale adresser) og etablera regresjonstestar for desse. Unicode er mindre eit «ombyggingstema» enn ein gjennomgåande kvalitetsprosess.
64-bit skifte: minnet er ikkje det einaste
64-bit overgangen blir ofte redusert til «pointer-størrelsar». I praksis dreier det seg oftare om:
- Utdaterte tredjeparts-komponentar utan 64-bit-støtte
- COM/ActiveX-avhengigheiter
- DLLs og drivarar (strekodeskannar, utstyr, kryptografi, signatur)
- Installer/deployment og registerstiar (WOW64)
Ein fornuftig strategi er først å inventarisere alle eksterne avhengigheiter og definere alternativ. Så blir 64-bit-steget planleggjande – og ikkje eit overraskingspakke like før release.
Windows 11 ARM64: sjekk tidleg i staden for å betale seint
Med Windows 11 ARM64 kjem ei ny klasse av målplattformer. Sjølv om ikkje alle verksemder straks treng native ARM64-builds, er det lurt å avklare tidleg:
- Finns det native avhengigheiter (DLLs, drivarar) som ikkje køyrer på ARM64?
- Er applikasjonen avhengig av emulering, og er det akseptabelt?
- Kva ser installasjons- og update/repair-prosessen ut som?
I moderniseringsprosjekt er dette eit typisk «seint» tema som blir dyrt. Bedre: ta det inn i plattform-roadmappa tidleg og avklar teknisk.
REST-Server og tenester: gjere faglogikk tilgjengeleg for portal og integrasjon
Mange verksemder moderniserer ikkje Delphi fordi skrivebords-appen ser gamal ut, men fordi nye krav oppstår: kundesenter, partnarportal, mobile prosessar, integrasjon mot ERP/DMS/CRM, rapportpipelines. Det krev tydlege grensesnitt. Ein REST-Server er ofte den mest praktiske broa.
API først? Berre om rettar og domeneloggikk følgjer med
Ein API er berre nyttig om han handhevar same faglogikk som klienten. Elles oppstår to regelsett: eitt i desktopen, eitt i backend. Konsekvensane er inkonsistensar og sikkerheitsauke.
Difor bør ein REST-Server-lag setje seg direkte på domenetenestene når mogleg. Typiske byggjesteinar:
- Autentisering/autorisering (roller, tenantar, rettar)
- DTOs/serialisering med klare versjoneringsreglar
- Transaksjons- og feilhandsamingskonsept (HTTP-status, Problem-Details, logging)
- Idempotens og samtidshandtering (for retry, kø-arbeid)
Slik blir REST-Server ein stabil integrasjonspunkt – ikkje ein «andre klient».
Linux-tenester og Windows-tenester modernisere
Batch-prosessar og integrasjonar køyrer i mange verksemder som Windows-tenester, Task Scheduler-jobbar eller til og med «skulte» desktop-instansar. Ved modernisering løner det seg å konsolidere:
- Skilje UI frå bakgrunnslogikk
- Konfigurerbare køyreskjema og klare driftsparameter
- Rein logging (strukturerte loggar, korrelasjon per jobb/request)
- Valet om tenester kan drifta under Linux (t.d. for container-deployments)
Vinsten er ikkje berre «modern», men operasjonell: reproduserbar drift, færre manuelle inngrep, betre feilsøking.
UI-modernisering utan å røre kjernen: VCL, FMX og hybride vegar
Mange moderniseringsplanar startar med UI. Det kan vere fornuftig – så lenge det er klart kva gevinsten er. Når faglogikken er avkopla, kan UI byttast med langt lågare risiko.
VCL-applikasjonar modernisere trinnvis
VCL er i mange B2B-scenarier framleis eit robust val, særleg i Windows-tunge miljø med høg produktivitet på skrivebordet. Modernisering kan bety:
- Redusere UI-logikk (Presenter/ViewModel), flytte fagreglane til tenester
- Renske komponentlandskapet, konsolidere eigne controls
- Forbetre respons (Async, bakgrunnsjobbar, framdrift, avbryt)
- Tilgjengelegheit, konsekvent validering, betre feilmeldingar
Det gir synleg nytte utan å skrive heile grensesnittet om.
Delphi Multiplattform: når FMX gir meining
Om det finst reelle multiplattform-krav (Windows, macOS, eventuelt Linux i tenestekontekst), kan FMX vere eit alternativ. Avgjerande er forventninga: multiplattform krev meir test- og integrasjonsarbeid (fontar, utskrift, OS-dialogar, filsystem, pakking/deployment). Kostnadene er likevel kalkulerbare når faglogikken ligg i eit reint lag.
Eit vanleg pragmatisk løp er hybrid: VCL blir verande for Windows-klienten, medan nye frontendar (portal, mobilapp) koplar seg via REST-Server. Då oppnår ein multiplattform over systemgrensene, ikkje gjennom ein einskild UI-stack.
Testing og regresjon: korleis «spikre fast» faglogikken
Å «miste faglogikk» betyr i praksis: systemet gjev andre resultat i kanttilfelle. Det er sjeldan synleg med ein gong, men dyrt. Difor er testbarheit ikkje luksus, men eit moderniseringsverktøy.
Gylne use-cases og referansedata
Ein etablert praksis er eit sett med «gylne» use-cases: reelle, kritiske flytar med definert datagrunnlag og forventet resultat (t.d. dokumentkjeda frå tilbod til kreditnota, eller vedlikehaldsordre med reservedelar og timeregistrering). Desse blir etablert som regresjonstestar eller i det minste som repeterbare testskript.
Viktig: ikkje berre suksessvegar, men også typiske feilvegar (låsekonfliktar, manglande rettar, ufullstendige stamdata, duplisert importfil).
Automatisering der den gir størst effekt
Ikkje alle bestandsprosjekt treng straks 80 % unit-test-dekning. Høg ROI finst ofte innan:
- Domenetenester (utrekningar, reglar, tilstandsovergangar)
- Datatilgang med klare kontraktar (mapping, SQL, transaksjonar)
- API-testar (auth, rettar, versjonering)
Målet er stabilitet ved endringar, ikkje akademiske metrikkar.
Framgangsmodell i praksis: ein moderniseringsplan i etappar
Frå eit B2B-perspektiv må modernisering halde seg leveringsdyktig. Ein typisk plan som følgjer risikoen ser slik ut:
Etappe 1: Analyse, målarkitektur, Quick Wins (2–6 veker)
- Systemkart (modular, databasar, grensesnitt, jobbar, avhengigheiter)
- Risikomatrise (BDE, tredjepart, 32/64-bit, Unicode, deployment)
- Definisjon av målarkitektur (Layer-3, tenestelag, API-strategi)
- Quick Wins: stabilisere build-prosess, forbetre logging, rydde versjonskontroll
Etappe 2: Avkopling av faglogikk (löpande, inkrementelt)
- Identifisere domenetenester og løyse dei ut av forms
- Inføre repository-fasadar
- Første regresjonstestar for kritiske use-cases
Etappe 3: Modernisere datatilgang/DB-lag
- Inføre FireDAC, etablere tilkoblings- og transaksjonskonsept
- BDE-Ablösung modulvis (eller databasemigrasjon med parallell drift)
- Teste ytelse og låseåtferd under last
Etappe 4: Etterutstyre REST-Server og integrasjonar
- API med auth, rettar, versjonering
- Kople til portal/integ rasjonar utan dobbel logikk
- Konsolidere tenester for batch og bakgrunnsprosessar
Etappe 5: Plattform- og UI-avgjerder (64-bit, ARM64, multiplattform)
- 64-bit build, erstatte avhengigheiter
- Planlegg/avklar ARM64-kompatibilitet
- UI-modernisering: VCL-refresh eller FMX/hybrid, basert på forretningsnytte
Rekkjefølga er vald med vilje slik at du tidleg får transparens, deretter stabiliserer kjernen, og først så rullar ut «synlege» endringar i stort omfang. På den måten går risikoen ned, og drifta held seg planbar.
Typiske anti-mønster: kva som gjer modernisering unødig dyr
Ein del mønster går att i auditing og redningsprosjekt:
- «Vi byggjer nytt og tek berre over funksjonar»: fører nesten alltid til logiktap, fordi særtilfelle manglar.
- API som eigen parallellverda: forretningsreglar blir verande i klienten og nyoppfunne i backend.
- Databasebytte utan semantiske testar: same data, men anna åtferd (NULL, sortering, datumslogikk).
- For seint dependency-management: 64-bit/ARM64 feilar på ein liten DLL rett før Go-Live.
- «Refactoring fyrst» utan målbilete: mange endringar, lite målbar nytte, høg regresjonsrisiko.
Motsetninga er alltid den same: avklar målarkitektur og risiko først, bygg inkrementelt, test og gjer faglogikken synleg.
Konklusjon: modernisere betyr å bevare – og målretta utvide
Å modernisere Delphi utan å mista faglogikk er ikkje eit paradoks, men ein disiplin. Verksemder treng ikkje velje mellom «alt beholdt» og «alt erstatta». Med rein arkitekturseparasjon (t.d. Layer-3), ei kontrollert BDE-Ablösung mot FireDAC, ein API-strategi via REST-Server og ein klar plan for Unicode, 64-bit og nye plattformar som Windows 11 ARM64 kan eit veksent system trinnvis førast over i ei framtidsretta struktur.
Det avgjerande er å handsame faglogikken som kjerneasset: isolere, gjere testbar, og så modernisere. Slik oppstår ei arkitektur som støttar portal, tenester og multiplattform-krav utan å risikere løpande drift.
Om du planlegg ei Delphi Modernisierung og vil slå saman faglogikk, datatilgang og drift på ein ryddig måte, snakk med oss om ein realistisk migrasjonsveg: https://net-base-software-gmbh.de/kontakt/