Kunder bliver på den gamle version, fordi den virker, fordi de har bygget arbejdsgange på den, og fordi flytningen koster dem tid. Det løses af en plan med fire dele: et overblik over, hvorfor hver kundegruppe bliver, en tydelig besked med en dato, en flytning, hvor gammelt og nyt kører parallelt, indtil data er kontrolleret, og en beslutning om, hvornår den gamle version lukker. Uden en dato bliver den gamle version aldrig tom, og softwarehuset skal imens passe to produkter med det samme team.
Hvorfor de bliver
Spørg, før I presser. Årsagerne er forskellige, og de kræver forskellige svar.
- Det virker. Kunden ser ingen grund til at skifte, så gevinsten skal gøres konkret.
- Der mangler noget. Det nye produkt kan ikke alt det, det gamle kunne. Her er det jer, der skal handle.
- Integrationer. Kundens andre systemer taler med den gamle version, og nogen hos kunden skal bruge tid på at ændre det.
- Kendskab. Medarbejderne kender skærmbillederne, og oplæring tager tid.
- Timing. Kunden har årsafslutning, sæson eller et andet projekt i gang.
- Ingen ejer. Den, der købte produktet, er stoppet, og ingen hos kunden føler sig ansvarlig.
Lav en enkel oversigt over alle kunder med version, størrelse, tilpasninger, integrationer og årsag. Gruppér dem. Der er sikkert en stor gruppe, der kan flytte let, og en lille, der er svær. Mange af de svære har særlige aftaler, se artiklen om kundetilpasninger.
Planen for udfasning
Udfasning betyder, at en version trækkes tilbage i kontrollerede trin. En brugbar plan har tre datoer, som meldes ud samtidig.
- Slut på nyt salg. Den gamle version sælges ikke længere.
- Slut på nye funktioner. Der kommer kun fejlrettelser og sikkerhedsrettelser.
- Lukning. Den gamle version holder op med at blive understøttet, eller lukker helt, hvis I selv driver den.
Afstanden mellem datoerne skal give kunderne reel tid og passe til deres årshjul. Tjek aftalerne, før noget meldes ud. Nogle kunder kan have aftaler om bestemte versioner eller opsigelsesvarsler, og det spørgsmål hører hjemme hos en advokat.
Reglerne om støtte til ældre versioner
Falder produktet ind under Cyber Resilience Act, hænger planen sammen med jeres supportperiode. Slutdatoen for perioden skal oplyses ved køb, og hver væsentligt ændret version skal have en erklæret supportperiode. Hovedkravene gælder fra 11. december 2027. For software giver art. 13, stk. 10, ifølge Kommissionens vejledning en lempelse: rettelser kan samles i seneste version, når ældre versioner kan opgraderes uden ekstra omkostninger. Vejledningen er ikke bindende. Hvad det betyder for jeres produkt, er et spørgsmål til advokat, og emnet er uddybet i supportperiode for software. Indberetning af aktivt udnyttede sårbarheder er allerede påkrævet, også for versioner bragt i omsætning før den dato.
Kommunikationen
Skriv beskeden fra kundens side. Hvad ændrer sig for jer, hvad får I, hvad skal I gøre, hvornår, og hvem hjælper? Beskeden går både til den tekniske kontakt og til den, der ejer kundeforholdet, og de største kunder skal have en personlig samtale, før brevet kommer.
Gentag den løbende, med en status på, hvor langt kunden er. Vær ærlig om det, der mangler i det nye, og hvornår det kommer. Kan I gøre det lettere, så gør det: hjælp til flytning af data, en kontaktperson, oplæring. Det er billigere end at holde den gamle version kørende.
Selve flytningen
Flyt i bølger. Begynd med dem, der er villige og enkle, og lær af dem. Hver bølge giver bedre værktøj, færre overraskelser og et eksempel, I kan fortælle andre.
For hver kunde gælder samme forløb. En prøveflytning af en kopi af data, så kunden kan teste det nye med sine egne oplysninger. Parallel drift i en aftalt periode, hvor begge versioner er tilgængelige, og hvor kunden kan vende tilbage. Kontrol af data, hvor I afstemmer antal og summer, som kunden kan genkende, og hvor kunden bekræfter, at det ser rigtigt ud. Derefter lukning af kundens adgang til det gamle.
Afstem flytningen med de skift i teknologien, der foregår imens, se gradvis udskiftning i praksis og, for installerede produkter, fra installeret software til SaaS.
De sidste kunder
Når de fleste er flyttet, står I tilbage med en lille gruppe, og de er de dyreste. Tag hver af dem op enkeltvis med en direkte samtale. Tre udfald er mulige: De flytter med ekstra hjælp. De bliver i en aftalt, tidsbegrænset periode under særlige vilkår. Eller I skilles på ordentlig vis, med udlevering af deres data.
Det sidste er en ledelsesbeslutning, og den kan være den rigtige. En kunde, der holder et helt gammelt produkt i live, kan binde mere af teamet, end kunden giver tilbage. Hold fast i datoen, når den først er meldt ud. Flytter I den for de sidste, lærer alle de næste, at datoer kan flyttes.
Det skal I lade være med
- At melde en lukkedato ud, før det nye kan det vigtigste · så vender kunderne sig mod konkurrenterne.
- At flytte kunden uden kontrol af data · en enkelt forkert saldo kan koste mere tillid, end hele flytningen giver.
- At lade den største kunde afgøre tidsplanen alene · tag samtalen tidligt og særskilt.
Det skal I kræve af den eksterne
- ☐ En oversigt over kunderne med årsag og sværhedsgrad.
- ☐ En plan med datoer, der er afstemt med aftaler og supportperiode.
- ☐ Et forløb for flytning med prøve, parallel drift og datakontrol.
- ☐ En beslutningsmodel for de sidste kunder.
Kilder
- Europa-Kommissionen: vejledning om Cyber Resilience Act, C(2026) 5252: nr. 125 til 129 om supportperiode og rettelser. Vejledningen er ikke bindende.
- Europa-Kommissionen: FAQ om Cyber Resilience Act: FAQ 1.4 om produkter bragt i omsætning før 11. december 2027.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Supportperiode for software · Fra installeret software til SaaS
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
