Et produkt i ældre teknologi rummer to forskellige risici for ledelsen. Den ene handler om mennesker: hvem kan vedligeholde det om nogle år? Den anden handler om teknologien selv: hvad sker der, når den mister support og sikkerhedsopdateringer? Hverken Delphi, Visual Basic 6 eller en gammel webramme er i sig selv et problem, så længe begge risici er kendte og styrede. Der findes flere muligheder før en omskrivning, og tidspunktet bør afgøres af konkrete datoer og personer. Ledelsen skal tage spørgsmålet op, før noget går i stykker.
Rekrutteringsrisikoen
Få unge udviklere vælger en gammel teknologi, og dem, der kan den, nærmer sig ofte pensionsalderen eller er bundet andre steder. Risikoen samler sig derfor gerne om ganske få navne. Spørg konkret: Hvem kan rette en kritisk fejl i dag, og hvor længe regner de med at blive? Hvor lang tid tog det sidst at finde en ny udvikler, og hvor længe var vedkommende om at blive selvstændig?
Svaret afgør, hvor presset I er. To erfarne udviklere, der gerne bliver i ti år, er en anden situation end én, der har nævnt pension. Spredning af viden har sin egen artikel.
Teknologirisikoen
Et produkt består af lag, som ældes hver for sig: programmeringssprog, udviklingsværktøj, database, styresystem, webserver og de komponenter, I har bygget ind. Bed teamet om en enkel oversigt med tre kolonner for hvert lag: hvilken version bruger vi, støtter producenten den stadig, og hvornår ophører det?
End of support betyder, at producenten holder op med at rette fejl og sikkerhedshuller. Produktet stopper ikke den dag. Nye sårbarheder forbliver dog åbne, nye styresystemer og browsere kan holde op med at fungere sammen med det, og kunder med krav om understøttede versioner kan begynde at stille spørgsmål. Et lag uden support er det stærkeste argument for at handle, og det er langt mere konkret end en fornemmelse af, at teknologien er gammeldags.
Muligheder før en omskrivning
Der er flere veje, og de kan kombineres.
- Opgradér inden for samme familie. Mange ældre teknologier har nyere versioner. Det er ofte kedeligt, overkommeligt og fjerner en stor del af risikoen.
- Fryse og afskærme. Dele, der næsten aldrig ændres, kan stå, så længe de er pakket ind, så de ikke rører internettet direkte.
- Bygge nyt rundt om det gamle. Nye funktioner og brugerflader laves i moderne teknologi og taler med den gamle kerne gennem en grænseflade. Det skifter retning uden at skifte alt, se gradvis udskiftning i praksis.
- Automatisk konvertering. Der findes værktøjer og leverandører, der oversætter gammel kode til nyere sprog, og AI kan hjælpe med at læse og forklare den. Resultatet skal stadig testes og forstås af nogen.
- Oplære egne folk. En erfaren udvikler kan lære en ny kollega teknologien, hvis tiden afsættes, og produktet er interessant nok.
- Aftale med en specialist. En fast aftale med en person eller et firma, der kan teknologien, kan dække risikoen i en årrække.
Først når disse er vurderet, er det tid til spørgsmålet skal produktet skrives om?.
Hvad der afgør tidspunktet
Fire ting sætter uret. Den dato, hvor vigtige lag mister support. De planer, nøglepersonerne har. Kundernes krav i aftaler og spørgeskemaer. Og regler, der gælder fra en bestemt dato. Læg dem på en tidslinje, og læs baglæns: Hvis det skal være på plads inden da, hvornår skal vi så begynde? En større ændring tager længere tid, end nogen tror, så begynd, mens der stadig er folk og overskud.
Cyber Resilience Act og det gamle produkt
For installeret software er Cyber Resilience Act, EU’s forordning om cybersikkerhed i produkter, et af de konkrete ure. Hovedkravene gælder fra 11. december 2027, og produkter bragt i omsætning før den dato er kun omfattet af dem, hvis de væsentligt ændres fra den dato. Indberetning af aktivt udnyttede sårbarheder og alvorlige hændelser er derimod påkrævet siden 11. september 2026, også for ældre produkter. Forordningen kræver desuden omhu ved valg af komponenter, og Kommissionens FAQ nævner kontrol af komponentens supportperiode.
Et lag uden support er derfor også et spørgsmål om, hvad I kan love. Læs Cyber Resilience Act for softwareproducenter, og spørg en advokat, hvis der er tvivl om jeres produkt. Kommissionens materiale er ikke bindende, og teksten her er ikke juridisk rådgivning.
Sådan kommer I videre
Begynd med oversigten over lag og navne. Den tager få dage og giver ledelsen det, der manglede: en konkret risiko med datoer på. Bagefter kan I vælge blandt mulighederne ovenfor og lægge det ind på den tekniske køreplan.
Vil I have hjælp til valget, kan Nielco IT som ekstern CTO lede det. Ydelsen dækker teknologivalg, team, ledelse og leverandører, og koden forbliver hos de udviklere, der kender produktet.
Det skal I lade være med
- At vælge ny teknologi, fordi den er populær i år · den skal stadig være til at drive om femten år.
- At vente på, at nøglepersonen selv tager emnet op · samtalen er ledelsens at åbne.
- At kalde al gammel teknologi et sikkerhedsproblem · det er de lag uden opdateringer, der er det.
Det skal I kræve af den eksterne
- ☐ En oversigt over alle lag med version og supportstatus.
- ☐ Et kort over, hvem der kan hvad, og hvad deres planer er.
- ☐ En vurdering af mulighederne, også de kedelige.
- ☐ En tidslinje, som ledelsen kan tage beslutninger ud fra.
Kilder
- Europa-Kommissionen: Cyber Resilience Act: datoer for underretning og hovedforpligtelser.
- Europa-Kommissionen: FAQ om Cyber Resilience Act: FAQ 1.4 om ældre produkter og 4.4 om komponenter.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Ingen tør røre den del af koden · Supportperiode for software
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
