Eje eller leje software? Beslutningsguide for danske virksomheder

Eje eller leje software? Svaret afhænger af, hvad systemet betyder for jer: lej standardsystemer langt fra kerneforretningen, men eje (eller self-host) de systemer, hvor jeres data og processer er selve værdien. Agent360 er bygget som et internalOS-produkt til netop det valg: hver kunde får sin egen instans med egen database, så dataejerskabet ligger hos virksomheden selv — ikke hos leverandøren.

Det korte svar: lej de systemer, der er standardvare og langt fra jeres kerneforretning — og overvej at eje (eller self-hoste) de systemer, hvor jeres data, jeres processer og jeres tilpasninger er selve værdien. I mange år var det svar mest teoretisk, fordi “at eje” krævede en udviklingsafdeling eller et dyrt konsulenthus. Det har AI-assisteret udvikling ændret markant: prisen på at bygge og vedligeholde egen software er faldet så meget, at eje-spørgsmålet igen er et reelt strategisk valg — også for mellemstore danske virksomheder uden eget IT-hold.

At eje software er at drive systemet på en instans, I selv kontrollerer — med jeres data i jeres egen database, uden løbende licens pr. bruger og med ret til at ændre i systemet uden at spørge en leverandør om lov. At leje software er det modsatte: et abonnement (typisk SaaS), hvor leverandøren driver systemet, ejer infrastrukturen og fastsætter både prisen, funktionerne og vilkårene for at komme ud igen.

Denne guide gennemgår begge veje uden religionskrig. SaaS er ikke ondt, og eje er ikke automatisk klogt. Men beslutningen bliver ofte truffet ved et tilfælde — nogen i teamet oprettede en prøvekonto for tre år siden — og ikke som det, den faktisk er: et langsigtet valg om omkostninger, data og kontrol.

Eje vs. leje: hvad betyder det egentlig?

Ordene bruges løst i branchen, så lad os få definitionerne på plads, før vi diskuterer fordele og ulemper.

Leje: SaaS-abonnementet

Software as a Service betyder, at leverandøren hoster og driver softwaren, og at I betaler løbende for adgang — typisk pr. bruger pr. måned. I ejer intet ud over jeres data (og selv dét kan være mere kompliceret i praksis, som vi vender tilbage til). Fordelene er velkendte: ingen servere at passe, opdateringer sker automatisk, og I kan komme i gang samme dag. Det er derfor, SaaS vandt det seneste årti — og for mange systemtyper er det fortsat det rigtige valg.

Lejemodellen dækker i dag alt fra e-mail og regnskab til CRM, projektstyring og HR. Hvis du vil have et konkret billede af, hvad et lejet system typisk kan i salgsdomænet, har vi gennemgået det grundigt i vores guide til hvad CRM-automatisering egentlig er.

Eje: egen instans og egen kode

At eje kan betyde flere ting, og det er værd at skelne:

• Klassisk on-premise: software installeret på egne servere med en engangslicens. Den model er reelt døende for nye systemer, men findes stadig i ældre ERP- og fagsystemer.
• Self-host: I kører softwaren (ofte open source eller fair source) på egen infrastruktur eller i en cloud, I selv kontrollerer. Koden er ikke nødvendigvis jeres, men driften og dataene er.
• Egenudviklet: software bygget til jer — enten af et bureau, af egne udviklere eller, i stigende grad, med AI-agenter som byggekraft. Her ejer I både kode, data og retning.

Fælles for eje-varianterne: der er ingen måler, der tikker pr. bruger, ingen leverandør der kan ændre vilkårene ensidigt, og jeres data ligger et sted, I selv bestemmer over.

Hvorfor skellet er blevet vigtigere

For fem år siden var det her mest en diskussion for store virksomheder. To ting har ændret det. For det første er SaaS-porteføljen i en typisk virksomhed vokset år for år, så abonnementsomkostningerne samlet set er blevet en post, ledelsen faktisk kigger på. For det andet er alternativet — at bygge og drive selv — blevet radikalt billigere med AI-assisteret udvikling. Når begge sider af ligningen flytter sig, skal regnestykket laves om.

SaaS-abonnementernes reelle omkostningsbillede over tid

Startprisen på et SaaS-produkt er sjældent problemet. Problemet er den kurve, prisen følger, efterhånden som jeres brug vokser og jeres afhængighed stiger. Fire mekanismer går igen på tværs af stort set alle abonnementsprodukter.

Pr.-bruger-prisen vokser med organisationen

De fleste SaaS-produkter prissættes pr. bruger pr. måned. Det føles fair i starten: fem sælgere, fem licenser. Men modellen betyder, at jeres softwareomkostning er koblet direkte til jeres vækst — hver ny medarbejder gør softwaren dyrere, uanset om systemet reelt koster leverandøren mere at drive. Og fordi mange systemer efterhånden skal bruges af “alle” (CRM’et skal ses af kundeservice, økonomi vil have adgang til pipeline-tal), ender virksomheder ofte med at betale fulde licenser for medarbejdere, der kun kigger i systemet få gange om måneden. Det er et mønster, vi også har beskrevet i vores gennemgange af Salesforce-alternativer og HubSpot-alternativer: licensmodellen straffer netop dét, systemet burde belønne — at hele organisationen bruger det.

Feature-gates: funktionerne flytter opad i pakkerne

Den anden mekanisme er pakkelogikken. Funktioner, I regner som basale — API-adgang, avancerede rapporter, single sign-on, workflows — placeres typisk i de dyrere pakker. Og pakkegrænserne flytter sig over tid: en funktion, der lå i mellempakken, da I skrev under, kan i næste version ligge i enterprise-laget. Resultatet er, at den reelle pris for det, I faktisk har brug for, ofte er markant højere end den pakke, I startede på. Beslutningen “vi opgraderer lige for at få den ene funktion” er en af de mest almindelige måder, softwarebudgettet vokser på, uden at nogen aktivt har besluttet det.

Prisstigninger, I ikke kontrollerer

Som lejer accepterer I, at leverandøren kan hæve prisen — og det sker jævnligt i branchen, typisk begrundet i nye funktioner (i disse år ofte AI-funktioner, som lægges oven i prisen, uanset om I bruger dem). Jo dybere systemet er integreret i jeres hverdag, desto svagere står I i den forhandling. Leverandøren ved det godt: omkostningen ved at flytte er jeres, ikke deres. En prisstigning på et system, hele salgsafdelingen lever i, bliver næsten altid accepteret — ikke fordi den er rimelig, men fordi alternativet er et migreringsprojekt.

Data-lock-in: den dyreste omkostning står ikke på fakturaen

Den fjerde mekanisme er den vigtigste, fordi den forstærker de tre andre: jeres data bor hos leverandøren, i leverandørens datamodel. Jo længere tid der går, desto mere historik, desto flere integrationer og desto flere vaner er bundet op på netop dét system. Eksport er sjældent umulig — men det, I kan eksportere, er typisk rådata uden den struktur, automatik og historik, der gjorde systemet værdifuldt. Lock-in er ikke en fejl i SaaS-modellen; det er en del af forretningsmodellen. EU har da også fundet det nødvendigt at lovgive på området: dataforordningen (Data Act) indeholder regler, der skal gøre det lettere for kunder at skifte mellem udbydere af databehandlingstjenester, netop fordi skifteomkostningerne i praksis har låst kunder fast.

Ingen af de fire mekanismer betyder, at SaaS er et dårligt valg. De betyder, at prisen på skiltet ikke er prisen. Det reelle omkostningsbillede er skiltprisen plus vækstkobling plus pakkeglidning plus prisstigninger plus den dag, I vil ud.

Hvad man får ved at eje

Ejersiden af regnestykket handler ikke kun om at undgå ovenstående. Der er fire positive gevinster, som er svære at få i lejemodellen.

Egen instans — og data hos jer selv

Når systemet kører på en instans, I kontrollerer, med jeres egen database, er spørgsmålet “hvor er vores data, og hvem har adgang?” pludselig let at besvare. Det har praktisk værdi hver eneste dag: I kan lave direkte databaseopslag, bygge egne rapporter, koble andre systemer på uden at vente på en API-kvote, og svare revisor og kunder præcist på, hvor data ligger. Og det har strategisk værdi den dag, noget ændrer sig — en leverandør lukker, ændrer vilkår eller bliver opkøbt. Jeres data flytter ikke med leverandørens beslutninger, for de har aldrig ligget hos leverandøren.

Ingen licens pr. bruger

Ejer I systemet, koster medarbejder nummer 50 det samme som medarbejder nummer 5: ingenting ekstra. Det lyder banalt, men det ændrer adfærd. I lejemodellen rationeres adgang (“skal hun virkelig have en licens?”), og systemets værdi begrænses af, hvem der har råd til at være med. I ejemodellen er det omvendt: jo flere der bruger systemet, desto mere værdifuldt bliver det — uden at fakturaen vokser. For virksomheder, der arbejder seriøst med at samle salg, drift og data ét sted — det vi i anden sammenhæng har kaldt revenue operations — er netop dét afgørende: sammenhæng kræver, at alle er på, og pr.-bruger-licenser er en skat på sammenhæng.

Tilpasning uden at vente på leverandørens roadmap

I et lejet system er jeres ønsker et “feature request” i en kø, I ikke kan se. I et ejet system er de en opgave. Har jeres forretning en proces, der ikke ligner standardskabelonen — og det har de fleste virksomheder, der er mere end få år gamle — kan I bygge den ind i systemet i stedet for at bøje processen efter softwaren. Det er her, forskellen mellem “vi bruger et system” og “vi har et system, der passer til os” opstår.

Forudsigelig økonomi

Ejemodellen har også omkostninger — drift, vedligehold, videreudvikling — men de er jeres at styre og prioritere. Der kommer ikke en mail om, at prisen stiger, eller at den funktion, I er afhængige af, nu ligger i en dyrere pakke. For økonomifunktionen er forskellen mellem en variabel, leverandørstyret omkostning og en fast, egenstyret omkostning ofte vigtigere end selve beløbet.

Hvad der før gjorde “byg selv” urealistisk — og hvad AI-agenter har ændret

Hvis eje er så attraktivt, hvorfor lejer alle så? Fordi eje-vejen historisk havde tre benhårde forudsætninger, som de færreste kunne opfylde.

Før: tre barrierer

Byggeomkostningen. Skræddersyet software krævede enten egne udviklere eller et konsulenthus, og begge dele var dyre og langsomme. Et system, der i SaaS-form kostede et abonnement, kostede som egenudvikling et projekt med kravspecifikation, tilbudsrunder og måneders udvikling — med reel risiko for, at resultatet alligevel ikke ramte behovet.

Vedligeholdelsesbyrden. Software er ikke færdig, når den er bygget. Sikkerhedsopdateringer, fejlrettelser, nye behov, integrationer der ændrer sig — alt det, SaaS-leverandøren håndterer usynligt, skulle man selv bemande. Mange egenudviklede systemer endte som “det system, kun Torben forstår”, og da Torben stoppede, blev systemet et problem i stedet for et aktiv.

Kompetencekløften. Selv med penge til begge dele krævede det teknisk ledelse at bestille, vurdere og drive softwareudvikling. Uden en person, der kunne oversætte mellem forretning og kode, blev egenudvikling et sats.

Tilsammen gjorde de tre barrierer lejemodellen til det eneste fornuftige valg for de fleste — ikke fordi leje var bedst, men fordi eje var utilgængeligt.

Nu: AI-agenter som byggekraft

Det er den ligning, AI-assisteret udvikling har ændret. Moderne AI-agenter kan i dag skrive, ændre og teste kode i et tempo og til en pris, der var utænkelig for få år siden. Det betyder ikke, at software bygger sig selv, eller at man kan undvære dømmekraft — men det flytter grænsen for, hvad en virksomhed uden udviklingsafdeling realistisk kan eje:

• Byggeomkostningen falder, fordi en stor del af selve kodearbejdet kan udføres af AI-agenter under menneskelig styring. Det, der før krævede et team, kan ofte drives af få personer, der beskriver behovet præcist og kvalitetssikrer resultatet.
• Vedligehold bliver en samtale i stedet for et projekt. “Tilføj et felt”, “lav en rapport over X”, “integrér med Y” er opgaver, en AI-agent kan løse i det system, I ejer — uden ticket-kø hos en leverandør.
• Kompetencekløften indsnævres, fordi kravene flytter sig fra “kan skrive kode” til “kan beskrive forretningen præcist og vurdere, om resultatet er rigtigt”. Det er en kompetence, mange forretningsfolk allerede har.

Det er præcis den udvikling, Agent360 er bygget på: en dansk platform, der samler virksomhedens AI i én IDE, hvor en agent bygget på Claude kan bygge og tilpasse virksomhedens egne systemer — på en egen instans med egen database pr. virksomhed. Pointen her er ikke produktet, men princippet: når byggekraften bliver tilgængelig, bliver eje-spørgsmålet aktuelt for virksomheder, der aldrig før har haft det som en reel mulighed.

Et ærligt forbehold hører med: AI-agenter fjerner ikke behovet for arkitektur, sikkerhedstænkning og drift. De fjerner flaskehalsen på selve byggearbejdet. Virksomheder, der tror, eje nu er gratis, begår bare den klassiske egenudviklingsfejl med nye værktøjer. Mere om faldgruberne til sidst.

Mellemvejen: fair source og self-host

Eje eller leje er heldigvis ikke et binært valg. Mellem de to yderpunkter findes modeller, der kombinerer lejemodellens bekvemmelighed med ejemodellens kontrol.

Self-host: lejet kode, ejet drift

Mange modne softwareprodukter — særligt open source — kan self-hostes: I kører selve softwaren på infrastruktur, I kontrollerer. I skriver ikke koden selv, men jeres data ligger hos jer, og ingen kan lukke for adgangen eller hæve prisen på noget, der kører på jeres egne maskiner. Prisen er driftsansvaret: opdateringer, backup og sikkerhed er jeres bord. For virksomheder med bare lidt teknisk kapacitet (eller en partner, der leverer den) er self-host ofte det bedste kompromis for systemer med følsomme data.

Fair source: åben kode med en tidsforsinkelse

En nyere mellemform er fair source-licenser: leverandøren driver og videreudvikler produktet kommercielt, men koden er tilgængelig, og efter en defineret periode bliver den ægte open source. Det ændrer magtbalancen fundamentalt i forhold til klassisk SaaS: I kan læse koden, I kan self-hoste, og selv i det værst tænkelige scenarie — leverandøren lukker eller ændrer kurs — bliver koden fri, og I (eller enhver anden) kan drive den videre. Agent360 bruger selv denne model: fair source, hvor koden bliver ægte open source efter to år. For en kunde betyder det, at “hvad sker der, hvis leverandøren forsvinder?” har et konkret svar i licensen — ikke bare et løfte i en salgspræsentation.

Hybriden i praksis

De fleste virksomheder ender fornuftigt i en portefølje: lejede standardsystemer til det generiske (løn, regnskab, e-mail), self-hostede eller fair source-systemer til det datafølsomme, og ejede/egenudviklede systemer dér, hvor forretningen er unik. Kunsten er ikke at vælge én model for alt — det er at vælge bevidst pr. system i stedet for at lade tilfældige prøvekonti afgøre arkitekturen.

GDPR- og exit-perspektivet: kan I komme ud igen?

Databeskyttelse og exit hænger tættere sammen, end de fleste softwarebeslutninger afspejler.

Ansvaret er jeres — uanset hvem der hoster

GDPR gælder, uanset om softwaren er lejet eller ejet. Men rollerne er forskellige: med SaaS er leverandøren typisk databehandler, og I skal have databehandleraftaler, styr på underdatabehandlere og overblik over, hvilke lande data behandles i. EU’s fælles GDPR-regler pålægger virksomheder ansvar for, hvordan persondata indsamles, opbevares og videregives — herunder pligten til at kunne udlevere eller overføre en persons data, og det ansvar kan ikke outsources sammen med driften. Ejer eller self-hoster I systemet, er kæden kortere: færre parter, færre aftaler, mere direkte kontrol — men også det fulde ansvar for sikkerheden, uden en leverandør at læne sig op ad.

For virksomheder, der bruger AI i kundevendte processer, kommer der desuden et ekstra reguleringslag oveni — det har vi behandlet særskilt i vores guide til EU’s AI-forordning for danske salgsorganisationer.

Dataportabilitet: en rettighed for personer — og en øvelse for jer

Registrerede personer har efter GDPR ret til dataportabilitet — at få deres oplysninger udleveret i et struktureret, maskinlæsbart format og flyttet til en anden dataansvarlig. Datatilsynets vejledningsmateriale om de registreredes rettigheder beskriver, hvad retten indebærer i praksis. For softwarevalget er pointen denne: hvis jeres system ikke kan eksportere data ordentligt, kan I hverken opfylde den slags anmodninger elegant — eller selv komme ud af systemet den dag, I vil skifte. Test det, før I skriver under: bed om en fuld eksport i prøveperioden, og se på, hvad I faktisk får. Rå CSV-filer uden relationer er ikke en exit-mulighed; det er en gidselsituation med pænere formatering.

Exit-planen hører til i beslutningen, ikke i krisen

En softwarebeslutning uden exit-plan er en halv beslutning. Konkret bør I, inden valget træffes, kunne svare på: Hvad kan eksporteres, i hvilket format, og hvor ofte? Hvad koster det (nogle leverandører tager betaling for eksport eller API-adgang i stor skala)? Hvor lang tid ville en migrering realistisk tage? Og hvad sker der med data efter opsigelse — slettes de, og kan I få dokumentation for det? I ejemodellen er svarene trivielle. I lejemodellen er de en forhandling — og forhandlingen er lettest, mens leverandøren stadig prøver at vinde jer.

Beslutningsramme: spørgsmålene der afgør valget

Her er de dimensioner, valget reelt står på — og de spørgsmål, I bør stille pr. system, ikke én gang for hele virksomheden.

Eje vs. leje: kvalitativ sammenligning på de vigtigste beslutningsdimensioner

Dimension	Leje (SaaS)	Eje / self-host
Tid til at komme i gang	Meget kort — konto samme dag	Længere — opsætning eller udvikling først
Omkostningsprofil	Lav start, vokser med brugere og pakker, leverandørstyrede stigninger	Højere start, flad drift, egenstyret prioritering
Datakontrol	Data hos leverandør, adgang via eksport/API	Data i egen database under egen kontrol
Tilpasning	Inden for leverandørens rammer og roadmap	Frit — begrænset af egen kapacitet
Vedligehold og sikkerhed	Leverandørens ansvar (usynligt for jer)	Jeres ansvar (kræver plan og disciplin)
Exit	Afhænger af eksportmuligheder og aftale — test før køb	Trivielt — I er der allerede
Afhængighed af leverandørens skæbne	Høj — lukning, opkøb eller kursskifte rammer jer direkte	Lav — især med open source / fair source-kode

De syv spørgsmål, I bør stille pr. system

1. Er systemet tæt på kernen? Jo tættere på det, der gør jer til jer — jeres kundedata, jeres proces, jeres prissætning — desto stærkere er argumentet for at eje eller self-hoste. Standardopgaver langt fra kernen (løn, mail) lejes med god samvittighed.
2. Hvor mange skal bruge det om tre år? Pr.-bruger-priser gør vækst dyr. Et system, hele organisationen skal ind i, taler for eje eller for licensmodeller uden brugerbetaling.
3. Hvor unik er jeres proces? Passer standardskabelonen, er leje fint. Skal systemet bøjes meget, betaler I i lejemodellen dobbelt: først for softwaren, så for arbejdet med at omgå den.
4. Hvad er exit-omkostningen — testet, ikke antaget? Lav en prøveeksport, før I skriver under. Hvis svaret er ubehageligt, er det bedre at vide det nu.
5. Hvem tager driftsansvaret, hvis I ejer? Eje uden en navngiven ansvarlig for opdateringer, backup og sikkerhed er ikke en strategi — det er udskudt teknisk gæld.
6. Hvad sker der, hvis leverandøren forsvinder eller ændrer kurs? For SaaS: hvad siger aftalen? For fair source/open source: koden er svaret.
7. Er der en mellemvej? Spørg altid, om systemet findes i en self-host- eller fair source-variant, før I vælger mellem yderpunkterne.

Bemærk, at spørgsmålene ikke handler om teknologi, men om forretning. Det er også derfor, beslutningen ikke bør ligge hos den, der tilfældigvis oprettede prøvekontoen — den hører hjemme samme sted som andre langsigtede aftaler om økonomi og risiko. Hvordan softwarevalg spiller sammen med den bredere kommercielle strategi, har vi skrevet mere om i vores guide til SaaS-salgsstrategi — som i sagens natur ser sagen fra sælgersiden, hvilket i sig selv er lærerigt for enhver køber.

Typiske faldgruber ved begge veje

Begge modeller har velkendte måder at gå galt på. Kend dem, før I vælger.

Faldgruber ved leje

• Skiltpris-beslutningen. At vælge på månedspris pr. bruger uden at regne vækst, pakkeglidning og exit ind. Den reelle sammenligning er totalomkostningen over den periode, I realistisk bliver i systemet — og den periode er næsten altid længere, end man tror, netop på grund af lock-in.
• Prøvekonto-arkitektur. Virksomhedens systemlandskab formes af tilfældige gratis prøver, der blev til vaner, i stedet for af beslutninger. Resultatet er overlappende abonnementer, data spredt over mange leverandører og ingen samlet ejer af landskabet.
• Integrations-limen. Hvert lejet system er en ø, og limen mellem øerne (integrationer, eksporter, dobbeltindtastning) bliver en usynlig, voksende omkostning, ingen faktura viser.
• Exit udskudt til krisen. Eksportmuligheder undersøges først den dag, prisen er steget, eller leverandøren er opkøbt — hvor forhandlingspositionen er dårligst.

Faldgruber ved eje

• At undervurdere drift. Byggeriet er den synlige del; drift, sikkerhed og opdateringer er den lange hale. Uden en plan for halen bliver ejet software til teknisk gæld med jeres navn på.
• Torben-problemet. Systemet, kun én person forstår. AI-agenter mildner problemet — kode kan forklares, dokumenteres og videreføres langt lettere end før — men disciplinen med dokumentation og delt viden er stadig jeres ansvar.
• At bygge det, der kan lejes billigt. Eje giver mening tæt på kernen. At egenudvikle et lønsystem er næsten altid spild — standardvaren er bedre og billigere. Byg det unikke, lej det generiske.
• Alt-på-én-gang-projektet. Det store system, der skal erstatte fem lejede systemer i ét hug, fejler oftere end den gradvise vej: ét system ad gangen, i drift og bevist, før det næste tages.
• Eje uden exit-tænkning den anden vej. Også ejede systemer skal kunne afvikles eller overdrages. Egen kode uden dokumentation og uden versionsstyring er sin egen form for lock-in — bare til fortiden i stedet for til en leverandør.

Konklusion: vælg bevidst, system for system

Eje eller leje er ikke et ideologisk valg, men et porteføljevalg. Lej det generiske, hvor SaaS-modellens bekvemmelighed er hele pointen. Ej eller self-host det, der bærer jeres data og jeres særpræg — og brug mellemformerne (self-host, fair source) hvor de findes, fordi de giver kontrol uden at kræve, at I bygger alt selv. Det nye i regnestykket er, at AI-agenter har gjort eje-siden realistisk for virksomheder, der aldrig har haft en udviklingsafdeling — og det gør det umagen værd at tage beslutningen om igen for de systemer, hvor lejemodellen gennem årene stille og roligt er blevet dyr, stiv eller begge dele.

Uanset hvad I vælger: træf valget med åbne øjne, test exit-vejen før indgangen, og lad ikke en prøvekonto fra tre år siden være jeres softwarestrategi.

Ofte stillede spørgsmål

Er det ikke altid billigst at leje software?

På kort sigt, ja — startomkostningen ved SaaS er lav. Men lejeprisen er koblet til jeres vækst (pr. bruger), til leverandørens pakkelogik og til prisstigninger, I ikke kontrollerer. Over en årrække, og især for systemer hele organisationen bruger, kan eje- eller self-host-modellen samlet set være billigere. Det rigtige svar afhænger af systemtypen: regn på totalomkostningen over den periode, I realistisk bliver i systemet, ikke på månedens skiltpris.

Kan en virksomhed uden IT-afdeling realistisk eje software?

I stigende grad, ja. AI-assisteret udvikling har flyttet flaskehalsen fra "kan vi skrive koden?" til "kan vi beskrive behovet præcist og tage driftsansvaret?". Byggearbejdet kan i dag i vidt omfang udføres af AI-agenter under menneskelig styring. Men driftsansvaret — opdateringer, backup, sikkerhed — forsvinder ikke; det skal placeres hos en navngiven person eller en partner, før eje er forsvarligt.

Hvad er fair source, og hvordan adskiller det sig fra open source?

Fair source er en licensmodel, hvor leverandøren driver produktet kommercielt, men hvor koden er tilgængelig og efter en defineret periode overgår til ægte open source. Forskellen fra klassisk open source er tidsforsinkelsen; forskellen fra klassisk SaaS er, at koden ikke er hemmelig, og at kunderne har en konkret garanti i licensen, hvis leverandøren lukker eller skifter kurs. Agent360 bruger selv modellen med overgang til ægte open source efter to år.

Hvordan tester jeg en SaaS-leverandørs exit-muligheder, før jeg skriver under?

Bed om en fuld dataeksport i prøveperioden og vurdér, hvad I faktisk får: Er relationerne mellem data bevaret, eller er det flade filer? Er formatet struktureret og maskinlæsbart? Koster eksport eller API-adgang ekstra? Spørg også skriftligt, hvad der sker med jeres data efter opsigelse, og om sletning dokumenteres. Svarene hører hjemme i beslutningsgrundlaget — ikke i en fremtidig krise.

Hvad kræver GDPR, når vi lejer software frem for at eje den?

Ansvaret for persondata er jeres i begge modeller. Ved leje er leverandøren typisk databehandler, så I skal have databehandleraftale, overblik over underdatabehandlere og over, hvor data behandles. Ved eje/self-host er kæden kortere og kontrollen mere direkte, men det fulde sikkerhedsansvar er jeres. Registrerede personer har desuden ret til dataportabilitet — at få deres data udleveret i et struktureret, maskinlæsbart format — hvilket i praksis kræver, at jeres system kan eksportere ordentligt, uanset ejerskabsmodel.

Skal vi flytte alle vores systemer til eje-modellen på én gang?

Nej — det er en klassisk faldgrube. Den gradvise vej virker bedst: vælg ét system, hvor lejemodellen gør mest ondt (typisk dér hvor pr.-bruger-prisen, stivheden eller datakontrollen er problemet), flyt eller byg det, få det i stabil drift, og tag så det næste. Generiske systemer som løn og regnskab kan med fordel blive i lejemodellen; det er systemerne tæt på jeres kerneforretning, der er kandidater til eje.