Et installeret produkt bliver sjældent til SaaS i ét spring. Den sikre vej går over tre trin: Først kører I det eksisterende produkt for kunderne i jeres egen drift, derefter gør I installationerne ens og lette at opdatere, og til sidst samler I kunderne på en fælles platform, hvor det giver mening. Undervejs ændrer virksomheden sig mere end koden. I overtager driften, som før lå hos kunden, og I får ansvaret for alle kunders data på én gang. Artiklen tager de tekniske og organisatoriske valg. Forretningsmodel og prisstruktur er ledelsens eget spor og holdes ude her.
Det, der ændrer sig
SaaS betyder, at kunden bruger produktet som en tjeneste, som I driver. Hvad SaaS betyder for den, der bygger softwaren, er forklaret særskilt. For et softwarehus med et installeret produkt er der fire skift, der fylder.
- Drift bliver jeres fag. Når produktet står stille, ringer kunden til jer, også om natten. Overvågning, vagt og backup skal bygges op, før første kunde flytter, se hvem ejer driften.
- Alle kører samme version. Tidligere bestemte kunden, hvornår der blev opdateret. Nu bestemmer I, og kunderne skal kunne stole på det.
- Tilpasninger kan ikke gemmes væk. Kundespecifik kode kan ikke længere leve i den enkelte installation. Det er den største enkeltsag, se kundetilpasninger i standardproduktet.
- Integrationerne flytter ud af huset. Et lokalt produkt taler ofte direkte med kundens andre systemer. Fra jeres drift skal det ske over sikre, veldefinerede forbindelser.
Tre trin i overgangen
Trin 1: Samme produkt i jeres drift. I kører den eksisterende software i cloud med én installation pr. kunde. Koden ændrer sig kun lidt, og I lærer driften at kende på rigtige kunder. Det er endnu et stykke fra rigtig SaaS, og det flytter ansvaret og giver erfaring. Nogle produkter skal have en webbrugerflade for at kunne bruges på afstand, og det kan være den første større opgave.
Trin 2: Ens installationer. Alle kører samme version, opsætningen sker automatisk, og tilpasninger flyttes over i konfiguration. Her viser det sig, hvor forskellige kunderne er blevet. Når I kan opdatere alle kunder på samme dag med et par tryk, er det meste af gevinsten hentet.
Trin 3: Fælles platform. Kunderne deler kode og eventuelt database, og adskillelsen bliver en del af produktet. Valget har sin egen artikel om multi-tenant. Nogle softwarehuse stopper med god grund på trin 2 for en del af kunderne, fordi deres krav gør fælles drift umulig. Ved et større skift af kerne kan valget i stedet være et nyt produkt, se skal produktet skrives om?.
Datamigrering og det gamle produkt
Kundernes data ligger ofte i mange versioner og med mange særheder. Skriv flytningen som et program, der kan køres igen og igen, og afprøv det på kopier af rigtige data, inden en kunde flytter. Kontrollér resultatet med tal, begge parter kan genkende, for eksempel antal poster og saldi.
Gammelt og nyt skal leve side om side, sandsynligvis i årevis. Det kræver en plan for support, fejlrettelser og hvad der ikke længere udvikles til den installerede udgave. Tag de mest villige kunder først, og lad dem være med til at finde fejlene. Læs også om kunder, der bliver på den gamle version.
Teamet og organisationen
Udviklere i et installeret produkt er vant til store, sjældne udgivelser. SaaS kræver små, hyppige ændringer, automatiske test og en vagtordning. Det er en ny måde at arbejde på, og den skal aftales med teamet, før den kræves. Supporten skifter også karakter, fra at hjælpe med installationer til at følge driften sammen med udviklerne. Tag dem med i planen tidligt, for det er ofte dér, kunderne mærker skiftet først.
Omstillingen kører ved siden af det eksisterende produkt, som fortsat skal betale regningerne. Afsæt derfor en navngiven leder til den, og gør den til fast punkt i den tekniske køreplan.
Reglerne flytter sig med
Et skift til SaaS ændrer, hvilke regler produktet møder. To punkter bør afklares tidligt med advokat.
Som udbyder af en cloudtjeneste bliver I omfattet af dataforordningens regler om skift, der har gældt siden 12. september 2025. Kunden skal kunne komme ud med sine data, og aftalen skal beskrive hvordan. Lempelser er foreslået i Digital Omnibus, og intet er vedtaget. Se jeres SaaS skal kunne forlades.
Det kan også ændre vurderingen efter Cyber Resilience Act. Kommissionen anser i sin vejledning, som ikke er bindende, en webapplikation, der alene tilgås i en browser, for som udgangspunkt at falde uden for begrebet produkt med digitale elementer, mens en lokal klient er omfattet. Beholder I en installeret klient, kan produktet altså stadig være omfattet, se artiklen om webapps og CRA.
Det skal I lade være med
- At flytte kunder, før driften er klar · den første lange nedetid husker kunden længere end alle nye funktioner.
- At tage kundetilpasningerne med uden stillingtagen · så får I mange små produkter i cloud.
- At love en dato for lukning af det gamle produkt, før de første kunder er flyttet · datoen skal bygge på erfaring.
- At lade det gamle team stå alene med det gamle produkt · viden og stolthed forsvinder, mens I stadig er afhængige af begge.
Det skal I kræve af den eksterne
- ☐ En trinvis plan med et brugbart resultat for hvert trin.
- ☐ Et overblik over tilpasninger, integrationer og data pr. kundegruppe.
- ☐ Krav til drift, vagt og backup, før første kunde flytter.
- ☐ En plan for, hvordan det gamle og det nye produkt deler teamet.
Kilder
- Digitaliseringsstyrelsen: databehandlingstjenester og cloudtjenester: reglerne om skift efter dataforordningen.
- Europa-Kommissionen: vejledning om Cyber Resilience Act, C(2026) 5252: afsnit 2 om, hvad der er omfattet. Vejledningen er ikke bindende.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Multi-tenant eller én installation pr. kunde · Hvem ejer driften?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
