Mange virksomheter drifter i år eller tiår stabile Delphi-applikasjoner som dekker kjernen i prosessene deres: ordrebehandling, produksjon, service, logistikk, fakturering, enhetsadministrasjon, dokumentarbeidsflyter. I disse systemene ligger ikke bare kode, men et robust samspill av fagregler, datamodell, brukerflyt og driftserfaring. Nettopp dette gjør modernisering krevende: den reelle verdien ligger sjelden i brukergrensesnittet, men i den opparbeidede forretningslogikken.
Hvis modernisering forstås som «å bygge nytt», er tapet programmert. Ikke fordi nye teknologier i seg selv er dårlige, men fordi implisitt kunnskap fra det eksisterende systemet – spesialtilfeller, historiske data, unntak i prosesser, regulatoriske detaljer – ved migrering ofte ikke kan rekonstrueres fullt ut. Resultatet er kostbare regresjonsfeil, endrede prosessider, akseptproblemer og et prosjekt som varer lenger enn planlagt.
Delphi lar seg imidlertid godt modernisere uten å miste forretningslogikken. Nøkkelen er en kontrollert, trinnvis tilnærming: først skape transparens (arkitektur, data, risiko), så løsne koblinger (UI, dataadgang, domenelogikk), deretter modernisere (databasetreverktøy, Unicode/64-Bit, APIer, tjenester, multiplattform) – samtidig som produksjonsdriften sikres. Denne artikkelen beskriver praktiske moderniseringsmønstre, typiske fallgruver og en fremgangsmåte som fungerer i B2B-miljøer med høy prosesskritikalitet.
Hvorfor Delphi-modernisering sjelden er et «teknikkprosjekt»
I realiteten feiler moderniseringer ikke på grunn av et manglende compiler-flagg, men på grunn av feil antakelser om systematferd. Delphi-applikasjoner som er utvidet over år, inneholder ofte:
- Fagregler i GUI-hendelser (OnClick, OnExit, OnValidate), ofte fordelt over mange forms
- SQL-setninger «nært overflaten» og optimalisert i årevis for nøyaktig én database
- Omgåelser for historiske data, spesialtilfeller, kundevarianter eller multi-tenant-logikk
- Batch-prosesser som i praksis kjører til faste tidspunkter og har avhengigheter
- Integrasjoner mot ERP, DMS, CRM eller maskiner som knapt er dokumentert
- Tyst kunnskap i form av driftsrutiner: «Hvis feil X, sjekk først Y»
Den som starter med en Big-Bang-omskriving, må gjenskape all denne kunnskapen – inklusive feilene den gamle løsningen allerede har vokst fra. En bedre tilnærming er å behandle faglogikken som en eiendel: isoler først, sikre deretter, moderniser så.
Modernisering uten logikktap: Målbilde og førende prinsipper
Et holdbart målbilde for B2B-systemer er ikke «alt nytt», men en arkitektur som muliggjør endringer. Typiske egenskaper:
- Adskilte ansvarsområder (UI, domene/forretningslogikk, dataadgang, integrasjoner)
- Testbarhet og målbarhet (regresjonstester, logging, overvåking, reproducerbare builds)
- Trinnvis utskiftbarhet (modernisere UI uten å endre datamodell umiddelbart; migrere DB uten å omskrive UI)
- API-evne (REST-server eller en tjenestelag for å koble på portaler, mobile klienter og integrasjoner)
- Driftskapabilitet (Windows- og Linux-tjenester, klare deploy-strategier, rollback-planer)
I Delphi er dette spesielt oppnåelig fordi eksisterende units og domeneklasser ofte kan gjenbrukes mens man moderniserer omkring dem: dataadgang fra BDE til BDE-avløsning med native tilkobling, nye REST-endpoints, nye UI-moduler, nye deployments.
Oppsummering av beholdningsstatus: Hva må virkelig bevares?
Før kode «berøres», lønner det seg med en strukturert beholdningsanalyse. Målet er ikke full dokumentasjon, men et solid beslutningsgrunnlag.
1) Kart over forretningslogikken i stedet for endeløs kodelesing
Praktisk erfaring viser at et kart over forretningslogikken med følgende perspektiver er nyttig:
- Brukstilfeller: Hvilke kjerneflyter er forretningskritiske? (f.eks. opprette ordre, faktura, kreditnota, retur, maskinservice, vedlikeholdsavtale)
- Regler: Hvilke valideringer, beregninger, tilstandsmaskiner finnes?
- Varianter: Tenants, kundekonfigurasjoner, landspesifikke regler
- Grensesnitt: Import/eksport, ERP/DMS/CRM, enheter/protokoller
- Batch/Jobs: nattkjøringer, rapporter, data-synkroniseringer
Fra dette kartet oppstår prioriterte moderniseringspakker: hva må forbli stabilt, hva kan endres, hva kan komme senere.
2) Gjør teknisk gjeld synlig
Typisk teknisk gjeld i eldre Delphi-systemer:
- Borland BDE/Paradox-avhengigheter
- ANSI-strenger/manglende Unicode-migrasjon
- 32-Bit-only, utdaterte tredjepartskomponenter
- Monolitisk form-logikk, globale variabler, units med store sideeffekter
- Uklare transaksjonsgrenser og «SQL overalt»
Kunsten er å ikke behandle disse punktene dogmatisk, men sette dem i en rekkefølge som minimerer risiko og maksimerer forretningsverdi.
Arkitektur-løsning: Håndtaket mot logikktap
Den vanligste årsaken til logikktap er sammenblanding av UI, dataadgang og fagregler. Modernisering starter derfor med entkopleing – ikke med «nytt UI-framework».
Layer-3-arkitektur som pragmatisk måltilstand
For mange Delphi-eksisterende applikasjoner fungerer en Layer-3-arkitektur godt:
- Presentation Layer: VCL/FMX-forms, ViewModels/Presentere, validering kun UI-nært (format, obligatoriske felt)
- Business Layer: domenemodeller, tjenester, regler, tilstandslogikk, beregninger
- Data/Integration Layer: repositories, SQL/ORM-deler, grensesnittadaptere, REST-klienter, meldingshåndtering
Fordelen: faglogikk blir testbar og gjenbrukbar. Senere kan et kundeportal, en REST-server eller en Linux-tjeneste bruke nøyaktig de samme domenetjenestene. Dermed moderniserer du «ytterlaget» uten å finne opp kjernelogikken på nytt.
Strangulation Pattern: Omfavn det gamle systemet trinnvis
Et velprøvd migrasjonsmønster er Strangulation Pattern: nye funksjoner bygges i den nye strukturen (f.eks. domenetjeneste + repository), mens eksisterende forms bygges om suksessivt. Den gamle verden forblir kjørbar, men blir bit for bit erstattet av den nye.
Viktig er å aktivt snu avhengigheter: ikke «Form kaller SQL», men «Form kaller Service», og servicen tar beslutningen. Denne lille vendingen gir ofte størst gevinst.
Modernisere dataadgang: BDE-avløsning og FireDAC planlegges grundig
Et sentralt moderniseringstiltak er BDE-avløsningen. Virksomheter undervurderer ofte at dette ikke bare handler om drivere, men om SQL-semantikk, transaksjoner, låsing, datatyper og feilhåndtering. Moderne Delphi-stacks baserer seg typisk på BDE-Ablosung mit nativer Anbindung med native drivere (f.eks. for MariaDB/MySQL, PostgreSQL, SQL Server).
Hva som virkelig avgjøres ved omstillingen
- Mål-DB: Blir det værende på eksisterende DB? Er en databaseomlegging fornuftig (f.eks. fra Paradox/Firebird til MariaDB eller PostgreSQL)?
- Transaksjonsmodell: Hvor begynner/slutter transaksjoner? Hvilke use-cases må være atomiske?
- Concurrency/Låsing: Optimistisk vs. pessimistisk, håndtering av deadlocks, retry-strategier
- SQL-dialekt: Dato-funksjoner, strengatferd, NULL-håndtering, case-sensitivitet
- Ytelse: Indekser, query-planer, paging, batch-inserts
Forretningslogikken er tett knyttet til dataatferd. Den som migrerer dette «ved siden av», risikerer subtile avvik i praksis: avrundinger, sortering, datogrenseverdier, låskonflikter. Derfor bør datalag tidlig inn i moderniseringsplanen, inkludert migrasjonsvei og testdata-strategi.
Pragmatiske steg for FireDAC-migrasjon
I stedet for å bygge om hele applikasjonen i ett løp, har følgende rekkefølge vist seg effektiv:
- Innføre et dataadgangslag (Repository/DAO) som fasade
- Bytte enkelte use-cases til FireDAC (f.eks. «lese» først, «skrive» senere)
- Standardisere connection-håndtering, feilhåndtering, logging
- Trinnvis avvikle BDE-komponenter der fasaden er stabil
Slik forblir applikasjonen når som helst leveringsdyktig, og du unngår en lang periode med «halvferdig» system.
Unicode, 64-Bit og avhengigheter: Moderniseringsfeller i detalj
Mange moderniseringer feiler ikke på konseptet, men på undervurderte detaljspørsmål. Tre av dem er særlig vanlige i Delphi-prosjekter.
Unicode-migrasjon: Ikke bare strenger, men dataflyter
I svært gamle Delphi-versjoner stammer systemer fra en ANSI-verden. En Unicode-migrasjon omfatter da:
- Strengtyper og konverteringer (WideString/AnsiString/UnicodeString)
- Fil- og sti-håndtering (Windows-API, nettverksstier)
- Import/eksport (CSV, faste feltlengder, EDI, legacy-grensesnitt)
- Sortering/kollasjon i databasen
Avgjørende er å identifisere kritiske dataflyter (f.eks. fakturatekst, varenavn, internasjonale adresser) og etablere regresjonstester for disse. Unicode er mindre et «ombyggingsprosjekt» enn en konsekvent kvalitetsprosess.
64-Bit-overgang: Minne er ikke det eneste temaet
64-Bit-overgangen reduseres ofte til «pekernes størrelse». I praksis gjelder det heller:
- Utdaterte tredjepartskomponenter uten 64-Bit-støtte
- COM/ActiveX-avhengigheter
- DLLer og drivere (strekkodelesere, enheter, kryptografi, signatur)
- Installer/deployment og registerstier (WOW64)
En fornuftig strategi er først å inventarisere alle eksterne avhengigheter og definere alternativer. Da blir 64-Bit-steget planbart – og ikke en overraskelse rett før release.
Windows 11 ARM64: Sjekk tidlig i stedet for å betale senere
Med Windows 11 ARM64 kommer en ny klasse målplattformer. Selv om ikke alle virksomheter trenger native ARM64-builds med en gang, er det fornuftig å vurdere tidlig:
- Finnes det native avhengigheter (DLLer, drivere) som ikke kjører under ARM64?
- Er applikasjonen avhengig av emulering, og er det akseptabelt?
- Hvordan ser installasjonsprosessen ut, hvordan håndteres oppdatering/repair?
I moderniseringsprosjekter er dette typisk et «sent» tema som blir dyrt. Bedre: ta det tidlig inn i plattform-roadmapen og avklar teknisk.
REST-server og tjenester: Gjør forretningslogikk tilgjengelig for portaler og integrasjon
Mange virksomheter moderniserer ikke Delphi fordi desktop-appen ser utdatert ut, men fordi nye krav oppstår: kundeportal, partnertilgang, mobile prosesser, integrasjon mot ERP/DMS/CRM, rapporteringspipelines. Det krever klare grensesnitt. En REST-server er ofte den mest praktiske broen.
API først? Bare hvis rettigheter og domenelogikk følger med
En API er bare nyttig hvis den håndhever samme forretningslogikk som klienten. Ellers oppstår to regelsett: ett i desktopen, ett i backend. Konsekvensene er inkonsistenser og sikkerhetshull.
Derfor bør en REST-server-lag helst bygge direkte på domenetjenestene. Typiske byggesteiner:
- Autentisering/autorisering (roller, tenants, rettigheter)
- DTOer/serialisering med klare versjoneringsregler
- Transaksjons- og feilhåndteringskonsept (HTTP-status, problem-details, logging)
- Idempotens og samtidighet (for retries, købehandling)
Slik blir REST-serveren et stabilt integrasjonspunkt – ikke en «annen klient».
Linux-tjenester og Windows-tjenester modernisere
Batch-prosesser og integrasjoner kjører i mange virksomheter som Windows-tjenester, Task Scheduler-jobs eller til og med «skjulte» desktop-instans er. Ved modernisering lønner konsolidering seg:
- Skille UI fra bakgrunnslogikk
- Konfigurerbare kjøreplaner og klare driftsparametere
- Ren logging (strukturert, korrelasjon per job/request)
- Mulighet for å kjøre tjenester som Linux (f.eks. for containeriserte deploys)
Fordelen er ikke bare «moderne», men operasjonell: reproduserbar drift, færre manuelle inngrep, bedre feilsøking.
UI-modernisering uten å røre kjernen: VCL, FMX og hybride tilnærminger
Mange moderniseringsplaner starter med UI. Det kan være fornuftig – så lenge det er klart hva man oppnår. Er faglogikken entkopplet, kan UI moderniseres med betydelig lavere risiko.
Trinnvis modernisering av VCL-applikasjoner
VCL er i mange B2B-scenarier fortsatt et robust valg, særlig i Windows-tunge miljøer med høy desktop-produktivitet. Modernisering kan her innebære:
- Redusere UI-logikk (Presenter/ViewModel), flytte fagregler til tjenester
- Rydde komponentlandskapet, konsolidere egne controls
- Forbedre respons (async, bakgrunnsjobber, progress, avbryt)
- Tilgjengelighetsforbedringer, konsistent validering, bedre feilmeldinger
Dette gir merkbar nytte uten å skrive hele grensesnittet på nytt.
Delphi multiplattform: Når FMX gir mening
Hvis det finnes reelle multiplattform-krav (Windows, macOS, evt. Linux i tjenestekontekst), kan FMX være et alternativ. Avgørende er forventningene: multiplattform krever ekstra test- og integrasjonsarbeid (fonter, utskrift, OS-dialoger, filsystem, pakking/deploy). Kostnadene er godt kalkulerbare når faglogikken allerede ligger i et rent lag.
En vanlig pragmatisk vei er hybrid: VCL beholdes for Windows-klienten, mens nye frontend (portal, mobilapp) kobles via REST-serveren. Slik oppnås multiplattform over systemgrensene, ikke via én UI-stack.
Testing og regresjon: Hvordan «sperre fast» forretningslogikken
«Miste faglogikk» betyr i praksis: systemet gir andre resultater i randtilfeller. Det er sjelden umiddelbart synlig, men kostbart. Derfor er testbarhet ikke en luksus, men et verktøy i moderniseringen.
Gylne use-cases og referansedata
Et sett med «gylne» use-cases fungerer godt: reelle, kritiske flyter med definert datagrunnlag og forventet resultat (f.eks. dokumentkjede fra tilbud til kreditnota, eller vedlikeholdsordre med reservedeler og tidsregistreringer). Disse etableres som regresjonstester eller minst som gjentakbare testskript.
Viktig: ikke bare suksessløp, men også typiske feilspor (låskonflikter, manglende rettigheter, ufullstendige stamdata, dobbelt importfil).
Automatiser der gevinsten er størst
Ikke alle legacy-prosjekter trenger umiddelbart 80 % unit-testdekning. Høy ROI finnes ofte i:
- Domenetjenester (beregninger, regler, tilstandsbytter)
- Dataadgang med klare kontrakter (mapping, SQL, transaksjoner)
- API-tester (autentisering, rettigheter, versjonering)
Målet er stabilitet ved endring, ikke akademiske metrikker.
Fremgangsmodell i praksis: En moderniseringsplan i etapper
Fra et B2B-perspektiv må modernisering forbli leverbar. En typisk plan, styrt av risiko, ser slik ut:
Etappe 1: Analyse, målarkitektur, quick wins (2–6 uker)
- Systemkart (moduler, databaser, grensesnitt, jobs, avhengigheter)
- Risikomatrise (BDE, tredjepart, 32/64-Bit, Unicode, deploy)
- Definisjon av målarkitektur (Layer-3, tjenestelag, API-strategi)
- Quick wins: stabilisere build-prosess, forbedre logging, rydde versjonskontroll
Etappe 2: Løse ut forretningslogikk (løpende, inkrementelt)
- Identifisere domenetjenester og løsrive dem fra forms
- Innføre repository-fasader
- Første regresjonstester for kritiske use-cases
Etappe 3: Modernisere dataadgang/DB-lag
- Innføre FireDAC, etablere forbindelses- og transaksjonskonsept
- BDE-avløsning modulvis (eller databasemigrasjon med parallell drift)
- Teste ytelse og låseatferd under last
Etappe 4: Etterutstyre REST-server og integrasjoner
- API med autentisering, rettigheter, versjonering
- Koble portaler/integrasjoner uten dobbel forretningslogikk
- Konsolidere tjenester for batch og bakgrunnsprosesser
Etappe 5: Plattform- og UI-beslutninger (64-Bit, ARM64, multiplattform)
- 64-Bit build, erstatte avhengigheter
- Vurdere/planlegge ARM64-kompatibilitet
- UI-modernisering: VCL-refresh eller FMX/hybrid, basert på forretningsnytte
Rekkefølgen er valgt slik at du tidlig får transparens, deretter stabiliserer kjernen, og først så ruller ut synlige endringer i stor skala. Dermed reduseres risiko, og driften forblir planbar.
Typiske anti-mønstre: Hva gjør modernisering unødig dyrt
Noen mønstre går igjen i audits og redningsprosjekter:
- «Vi bygger nytt og tar bare med features»: fører nesten alltid til logikktap fordi spesialtilfeller mangler.
- API som parallell verden: forretningsregler beholdes i klienten og gjenskapes i backend.
- Databasebytte uten semantiske tester: samme data, men ulik atferd (NULL, sortering, datologikk).
- For sen dependency-håndtering: 64-Bit/ARM64 feiler på en liten DLL rett før go-live.
- «Refaktorering først» uten målbilde: mye endring, lite målbar gevinst, høy regresjon.
Mottilnærmingen er alltid den samme: klargjør målarkitektur og risiko først, bygg inkrementelt, test og gjør faglogikk synlig.
Konklusjon: Modernisere betyr bevare – og målrettet utvide
Å modernisere Delphi uten å miste forretningslogikken er ikke et paradoks, men en disiplin. Virksomheter behøver ikke velge mellom «alt bevare» og «alt erstatte». Med klar arkitekturseparasjon (f.eks. Layer-3), en kontrollert BDE-avløsning mot FireDAC, en API-strategi via REST-server og en tydelig plan for Unicode, 64-Bit og nye plattformer som Windows 11 ARM64 kan et modent system trinnvis overføres til en fremtidsrettet struktur.
Det avgjørende er å behandle forretningslogikken som kjerneverdien: isoler den, gjør den testbar, og moderniser deretter. Slik oppstår en arkitektur som støtter portaler, tjenester og multiplattformkrav uten å risikere løpende drift.
Hvis du planlegger en Delphi Modernisierung og ønsker å samle forretningslogikk, dataadgang og drift i en ryddig tilnærming, snakk med oss om en realistisk migrasjonsvei: https://net-base-software-gmbh.de/kontakt/