Egen instans vs. multi-tenant SaaS: hvad betyder det for jeres data?

Hvad er forskellen på egen instans og multi-tenant SaaS?

Egen instans og multi-tenant SaaS handler grundlæggende om hvor data ligger: multi-tenant deler software og drift mellem alle kunder, mens egen instans giver hver virksomhed sin egen kørende kopi.

Egen instans vs. multi-tenant SaaS handler i bund og grund om ét spørgsmål: ligger jeres data i jeres egen database, eller deler I infrastruktur med andre kunder på samme system? Multi-tenant deler software og drift mellem alle kunder; egen instans giver hver virksomhed sin egen kørende kopi. Hos Agent360 er egen instans ikke et bureau-tilkøb ved siden af — det er en kerneegenskab i selve OS'et, som al funktionalitet bygger ovenpå.

Forskellen på egen instans og multi-tenant SaaS er kort fortalt: i en multi-tenant-løsning deler alle kunder den samme kørende software og den samme underliggende infrastruktur, mens jeres data adskilles logisk fra andre kunders. Med en egen instans får jeres virksomhed sin egen kørende kopi af systemet med sin egen database — ingen andre kunder deler den. Valget lyder teknisk, men det er i virkeligheden et forretningsvalg: det afgør, hvor jeres data fysisk og juridisk bor, hvor afhængige I er af leverandøren, og hvor nemt I kan komme ud af aftalen igen den dag, I vil videre.

Multi-tenant betyder, at én softwareinstallation betjener mange kunder ("tenants") på delt infrastruktur, hvor hver kundes data adskilles logisk — mens en egen instans (også kaldet single-tenant) er en dedikeret installation af softwaren, hvor både applikation og database kun tilhører én kunde.

I denne guide gennemgår vi forskellen i praksis: hvorfor næsten al moderne SaaS er multi-tenant, hvad egen instans betyder for GDPR og databehandleraftaler, hvordan de to modeller adskiller sig på dataejerskab og exit — og hvilke spørgsmål I bør stille enhver leverandør, før I lægger virksomhedens data i deres system.

Hvad er forskellen — helt konkret?

Forestil jer en kontorbygning. Multi-tenant SaaS svarer til at leje et kontor i et kontorfællesskab: I har jeres eget aflåste rum, men bygningen, gangene, ventilationen og elevatoren deles med alle de andre lejere. Egen instans svarer til at have hele huset selv: samme type hus som naboens, men jeres eget — med egen lås, egen kælder og eget elmålerskab.

Multi-tenant: én maskine, mange kunder

I en multi-tenant-arkitektur kører leverandøren én (eller få) store installationer af deres software, og alle kunder logger ind på det samme system. Jeres data ligger i samme databaser som tusindvis af andre virksomheders data, adskilt af logiske skel — typisk et kunde-id på hver eneste række i databasen. Det er sådan, langt de fleste kendte SaaS-produkter fungerer, fra CRM-systemer til regnskabsprogrammer.

Den logiske adskillelse er ikke i sig selv usikker. Store SaaS-leverandører bruger betydelige ressourcer på at vedligeholde den. Men adskillelsen er et løfte i software — ikke en fysisk kendsgerning. Jeres data og naboens data bor på de samme diske og flyder gennem de samme systemer.

Egen instans: jeres egen kørende kopi

Med en egen instans får virksomheden sin egen installation: applikationen kører for jer alene, og databasen indeholder kun jeres data. Ingen andre kunders trafik rører jeres system. Instansen kan hostes af leverandøren for jer, eller — hvis løsningen understøtter self-host — køre på jeres egen infrastruktur.

Det betyder ikke, at hver instans er sin egen ø af specialkode. Veldrevne instans-baserede platforme holder alle instanser på samme standardiserede softwareversion og samme datamodel — det er dataene og driften, der er adskilt, ikke produktet. Man kan kalde princippet standardisering uden centralisering: alle kunder får det samme system, men ingen deler data.

Hvorfor er næsten al SaaS multi-tenant?

Svaret er økonomi og drift — set fra leverandørens side.

Stordriftsfordele for leverandøren

Én stor installation er billigere at drive end tusind små. Leverandøren skal kun opdatere ét system, overvåge ét system og skalere ét system. Hver ny kunde koster i praksis kun marginalt mere infrastruktur. Det er en væsentlig del af forklaringen på, at SaaS-forretningsmodellen er blevet så udbredt: omkostningen pr. kunde falder, jo flere kunder der deles om maskinen.

Hurtigere udrulning af nye funktioner

Når alle kunder kører på samme installation, får alle nye funktioner samtidig. Leverandøren slipper for at vedligeholde mange versioner i drift. Det er en reel fordel — også for kunderne, som altid er på nyeste version.

Men fordelene tilfalder primært leverandøren

Det er værd at være ærlig om: multi-tenant er først og fremmest optimeret for leverandørens omkostninger og udviklingshastighed. Kunden får typisk en lavere pris og hurtige opdateringer — men betaler med mindre kontrol: over data, over opgraderingstidspunkter, over integrationer og over exit. Om det bytte er godt eller dårligt afhænger af, hvor kritisk systemet og dets data er for jeres forretning.

GDPR og databehandleraftaler: hvad ændrer en egen instans?

Uanset model gælder databeskyttelsesforordningen. Når en leverandør behandler personoplysninger på jeres vegne, er jeres virksomhed dataansvarlig og leverandøren databehandler — og så kræver reglerne en databehandleraftale. Datatilsynet forklarer rollefordelingen mellem dataansvarlig og databehandler i deres vejledning om rollefordeling, og EU's samlede krav til virksomheders håndtering af persondata er beskrevet i EU's GDPR-gennemgang for virksomheder.

GDPR stiller ikke krav om den ene eller anden arkitektur. Men arkitekturen påvirker, hvor let det er at leve op til kravene — og hvor let det er at dokumentere det:

Overblik over hvor data bor

Som dataansvarlig skal I kunne redegøre for, hvor personoplysninger behandles, og hvem der har adgang. Med en egen instans er svaret kort: i jeres instans, i jeres database, på en navngiven infrastruktur. I en multi-tenant-løsning er svaret typisk længere og mere abstrakt — data ligger i leverandørens delte systemer, ofte fordelt over flere lag af underdatabehandlere, som I skal have styr på via aftalekæden.

Sletning og indsigt

Registreredes rettigheder — indsigt, berigtigelse, sletning — skal kunne efterleves i praksis. I en egen instans med egen database er en fuldstændig sletning noget, der kan verificeres konkret. I delte systemer er I afhængige af leverandørens processer for logisk sletning på tværs af delte lagre, sikkerhedskopier og afledte systemer.

Adgangsbegrænsning

Jo færre systemer og personer der kan tilgå jeres data, desto lettere er det at holde adgangen på et minimum. En dedikeret instans reducerer den flade, hvor jeres data overhovedet kan eksponeres — der er simpelthen færre veje ind.

Det betyder ikke, at multi-tenant er uforenelig med GDPR — tusindvis af europæiske virksomheder bruger multi-tenant SaaS fuldt lovligt. Pointen er, at egen instans gør flere af svarene korte og efterprøvelige i stedet for lange og tillidsbaserede.

Dataejerskab og exit: hvad sker der, når I vil ud?

Det mest oversete spørgsmål ved ethvert softwarevalg stilles først den dag, man vil skifte: hvordan kommer vi ud — med alt vores?

Exit fra multi-tenant SaaS

I de fleste SaaS-løsninger kan I eksportere jeres data — men typisk i det format og det omfang, leverandøren har valgt at understøtte. Ofte får I rådata i CSV- eller JSON-filer, mens sammenhænge, historik, automatiseringer og opsætning ikke følger med. Selve softwaren har I aldrig haft; den forbliver hos leverandøren, og adgangen slukkes, når abonnementet stopper. Det reelle produkt af flere års arbejde — jeres strukturerede, sammenhængende data i et kørende system — kan sjældent flyttes som en helhed.

Exit fra en egen instans

Med en egen instans er udgangspunktet omvendt: databasen er jeres, i sin helhed. En exit betyder i praksis at tage en fuld kopi af egen database — skema, indhold, historik — og enten drive systemet videre selv (hvis licensmodellen tillader det) eller migrere fra en komplet og velbeskrevet kilde. Er løsningen self-hostet, står systemet allerede på jeres egen infrastruktur, og "exit" handler mest om at stoppe samarbejdet om vedligehold.

Licensen afgør, hvor reel friheden er

Arkitektur er kun halvdelen af exit-spørgsmålet — licensen er den anden halvdel. En egen instans i en lukket, proprietær løsning kan stadig efterlade jer uden ret til at køre videre. Derfor er det værd at se efter leverandører med åbne eller tidsforsinkede åbne licenser. Agent360 har for eksempel valgt en fair source-licens — ægte open source efter 2 år — netop for at gøre exit-løftet troværdigt: koden kan læses i dag, og friheden vokser med tiden i stedet for at skrumpe.

Sikkerhed: isolation vs. delt infrastruktur

Sikkerhedsdiskussionen mellem de to modeller er mere nuanceret, end begge lejre normalt fremstiller den.

Argumentet for egen instans

Isolation reducerer konsekvensen af fejl. I delte systemer er den klassiske fejlklasse, at en brist i den logiske adskillelse eksponerer én kundes data for en anden — en fejl, der pr. definition ikke kan ramme systemer, hvor kunderne slet ikke deler applikation og database. En dedikeret instans gør også "blast radius" ved kompromittering mindre: et angreb på én instans er ikke automatisk et angreb på alle kunder.

Argumentet for multi-tenant

Store SaaS-leverandører har sikkerhedsteams, døgnovervågning og hurtige patch-processer, som de færreste SMV'er selv kan matche. En velfungerende multi-tenant-platform kan derfor i praksis være bedre beskyttet end en dårligt vedligeholdt egen instans. Isolation hjælper ikke, hvis instansen kører glemt software uden opdateringer.

Den ærlige konklusion

Sikkerhed afgøres mindre af arkitekturen og mere af driftsdisciplinen. Egen instans giver strukturelle fordele — mindre angrebsflade pr. kunde, verificerbar adskillelse — men kun hvis instanserne holdes opdaterede og drives professionelt. Det taler for instans-modeller, hvor leverandøren standardiserer og vedligeholder alle instanser centralt, frem for modeller hvor hver installation sander til i sin egen version.

Self-host: hvornår giver det mening?

Self-host — at køre softwaren på egen infrastruktur — er den mest vidtgående form for egen instans. Det giver maksimal kontrol: data forlader aldrig jeres miljø, og I bestemmer selv over drift, adgang og sikkerhedskopier.

Til gengæld overtager I også ansvaret. Self-host giver mest mening, når:

Data er særligt følsomme eller underlagt interne/eksterne krav om, at de ikke må forlade eget miljø.
I har driftskompetence — nogen skal kunne opdatere, overvåge og sikkerhedskopiere systemet.
Uafhængighed er et strategisk mål — I vil kunne køre videre uanset hvad der sker hos leverandøren.

For virksomheder uden egen driftskapacitet er en leverandør-hostet egen instans ofte det bedre kompromis: dedikeret data-adskillelse uden selv at skulle stå med driften. Og bemærk: multi-tenant-løsninger kan pr. definition sjældent self-hostes — muligheden findes stort set kun i instans-baserede produkter. Alene tilstedeværelsen af en self-host-mulighed siger derfor noget om, hvor meget kontrol leverandørens arkitektur reelt kan aflevere.

Standardisering uden centralisering

En almindelig indvending mod egen instans lyder: "Bliver det ikke et vedligeholdelsesmareridt med tusind forskellige installationer?" Det er en berettiget bekymring — og svaret er den model, moderne instans-platforme bruger: alle instanser fødes fra samme standardsystem og samme datamodel og opdateres samlet.

Princippet er værd at forstå, fordi det opløser det klassiske valg mellem kontrol og skala:

Produktet er fælles: alle kunder kører samme kode og samme standard-skema. Forbedringer rulles ud til alle.
Dataene er adskilte: hver kunde har sin egen database. Ingen deling, ingen logiske skel der skal holde tæt.
Driften er ensartet: fordi instanserne er identiske i struktur, kan de vedligeholdes næsten lige så effektivt som ét system.

Det er denne model, Agent360 er bygget på: hver virksomhed får sin egen instans med egen database — self-host muligt — mens platformen selv er fælles og standardiseret. Kombinationen giver multi-tenant-modellens skalafordele på produktsiden uden at give afkald på data-adskillelsen.

Egen instans og multi-tenant SaaS sammenlignet dimension for dimension
Dimension	Multi-tenant SaaS	Egen instans
Hvor bor data?	I leverandørens delte systemer, logisk adskilt	I jeres egen database, fysisk adskilt fra andre kunder
GDPR-dokumentation	Afhænger af leverandørens processer og aftalekæde	Kort og efterprøvelig: én instans, én database
Exit	Eksport i leverandørens formater; systemet forbliver hos leverandøren	Fuld databasekopi; mulighed for at drive videre afhængigt af licens
Sikkerhedsprofil	Professionel storskala-drift, men delt angrebsflade	Isoleret pr. kunde; kræver disciplineret vedligehold
Opdateringer	Alle kunder samtidig, styret af leverandøren	Standardiseret udrulning på tværs af instanser
Self-host muligt?	Stort set aldrig	Ofte — arkitekturen tillader det
Typisk prisprofil	Lav indgangspris, pris pr. bruger	Varierer; dedikerede ressourcer pr. kunde

Gråzoner og hybridformer: når etiketten snyder

Virkeligheden er sjældent så ren som de to modeller ovenfor. Markedet er fuldt af mellemformer, og etiketterne bruges løst — så det er værd at kende de mest almindelige gråzoner, før I tager en leverandørs ord for pålydende.

"Dedikeret skema" i en delt database

Nogle leverandører markedsfører "egen instans", men mener i praksis, at jeres data ligger i et separat skema eller separate tabeller i den samme fysiske database som alle andres. Det er bedre end ren rækkebaseret adskillelse, men det er ikke en egen instans: applikationen er stadig delt, databasen er stadig delt, og jeres exit er stadig en eksport — ikke en databasekopi. Spørg altid: er det en separat kørende applikation og en separat database, eller et logisk skel i noget delt?

Dedikeret applikation, delt datalag

Den omvendte mellemform findes også: hver kunde får sin egen kørende applikation, men alle applikationer skriver til et fælles datalag. Her får I isolationens driftsfordele, men ikke dens datafordele — og det er datafordelene, GDPR-dokumentationen og exit-scenariet handler om.

Enterprise-tiers med "single tenant"-tilkøb

Flere store SaaS-leverandører tilbyder dedikerede miljøer som dyrt enterprise-tilkøb. Det kan være et fint valg for store organisationer, men bemærk to ting: prisen afspejler, at det er en undtagelse fra leverandørens normale drift — og licensen er stadig lukket, så exit-spørgsmålet (kan vi køre videre uden jer?) er uændret besvaret med nej.

Sådan skærer I igennem

Gråzonerne betyder ikke, at etiketterne er ubrugelige — kun at de skal efterprøves. De tre spørgsmål, der skærer igennem enhver marketingformulering: Har vi vores egen database (ja/nej)? Kan løsningen self-hostes (ja/nej)? Får vi en fuld databasekopi ved exit (ja/nej)? Tre gange ja er en ægte egen instans. Alt andet er varianter af delt drift — hvilket kan være helt fint, så længe I ved, hvad I køber.

Sådan vurderer I en leverandør: 7 spørgsmål om datahåndtering

Uanset hvilken model I hælder til, afslører disse syv spørgsmål hurtigt, hvor gennemtænkt en leverandørs datahåndtering er:

Hvor bor vores data helt konkret — i hvilket system, i hvilket land, hos hvilken infrastrukturleverandør?
Deler vi database med andre kunder? Hvis ja: hvordan er adskillelsen implementeret, og er den nogensinde auditeret?
Hvem kan tilgå vores data hos leverandøren, og logges adgangen?
Hvordan ser en fuld eksport ud? Bed om at se et eksempel — format, omfang, sammenhænge.
Hvad sker der konkret ved opsigelse? Hvor længe ligger data hos jer bagefter, og hvordan dokumenteres sletning?
Kan løsningen self-hostes — nu eller senere? Svaret afslører arkitekturens reelle fleksibilitet.
Hvad siger licensen om vores rettigheder til at køre systemet videre uden leverandøren?

En leverandør, der svarer klart og konkret på alle syv, tager datahåndtering alvorligt. Vage svar på spørgsmål 4-7 er det klassiske varsel om en svær exit.

Vil I dybere ned i det tilgrænsende stof, har vi også skrevet om EU's AI-forordning og hvad den betyder for danske virksomheder, om datakvalitet og CRM-data-hygiejne og om hvad CRM-automatisering egentlig er — alle tre emner støder direkte op til spørgsmålet om, hvor og hvordan virksomhedens data bor. Ser I bredere på softwarestrategien, er guiden til SaaS-salgsstrategi et godt supplement.

Ofte stillede spørgsmål

Er egen instans det samme som on-premise?

Nej. On-premise betyder, at softwaren kører på jeres egne fysiske servere. En egen instans betyder, at I har jeres egen dedikerede installation med egen database — den kan hostes i skyen af leverandøren eller self-hostes. On-premise er altså én måde at drive en egen instans på, men ikke den eneste.

Er multi-tenant SaaS ulovligt eller i strid med GDPR?

Nej. Multi-tenant SaaS kan sagtens drives GDPR-compliant, og det gør tusindvis af leverandører. Forskellen ligger i, hvor let det er for jer som dataansvarlig at dokumentere hvor data bor, hvem der har adgang, og at sletning faktisk er sket — de svar er typisk kortere og mere efterprøvelige med en egen instans.

Bliver egen instans ikke hurtigt forældet software?

Det er risikoen i dårligt drevne setups, hvor hver installation lever sit eget liv. Moderne instans-platforme løser det med standardisering: alle instanser kører samme version og opdateres samlet — det er data, ikke produktet, der er adskilt.

Hvad koster egen instans i forhold til multi-tenant?

Det varierer for meget til et generelt svar: multi-tenant har typisk lav indgangspris og pris pr. bruger, mens instans-baserede løsninger prissættes på andre måder, fordi hver kunde har dedikerede ressourcer. Sammenlign altid totalomkostningen over flere år — inklusive prisen for en eventuel exit — frem for månedsprisen alene.

Kan vi flytte fra multi-tenant SaaS til en egen instans senere?

Ja, men flytningen er et datamigrationsprojekt: I skal eksportere, hvad leverandøren tillader, og genopbygge struktur og sammenhænge i det nye system. Jo længere I har brugt den gamle løsning, desto større er opgaven — endnu en grund til at stille exit-spørgsmålene, før I vælger, ikke efter.

Hvordan ved vi, om en leverandørs "egen instans" er ægte?

Spørg konkret: Har vi vores egen database — ja eller nej? Kan løsningen self-hostes? Kan vi få en fuld databasekopi ved exit? Hvis svarene er vage, eller "egen instans" viser sig at betyde "eget skema i en delt database", er det reelt en multi-tenant-model med nyt navn.