Et produkt, der er vokset fra sin teknologi

Produktet har tjent penge i mange år. Kunderne er loyale, og koden bærer præg af alt det, der er sket undervejs. Nye udviklere er svære at finde, de erfarne tør ikke røre visse dele, og hver kunde har sin særlige udgave. Det er en anden situation end startuppens, og de fleste råd på nettet passer dårligt til den. Her findes der en forretning, der skal holdes kørende, mens grundlaget ændres. Siden her samler artiklerne til det etablerede softwarehus.

Det, der går igen

Valget står oftest mellem tre veje: at vedligeholde og leve med det, at udskifte produktet gradvist eller at skrive det om. Selve afvejningen har sin egen artikel, og valget bør træffes, før nogen går i gang. To ting afgør meget. Hvor længe kan I skaffe folk og support til teknologien? Og hvad vil kunderne være med til? En plan, der ser godt ud teknisk, hjælper ikke, hvis de største kunder bliver stående på den gamle version.

Teknologien

• Produktet er skrevet i en teknologi, få vil arbejde med Rekrutteringsrisiko og teknologirisiko set fra ledelsen, og hvilke muligheder der findes før en omskrivning.
• Ingen tør røre den del af koden Test rundt om det eksisterende først og små ændringer bagefter, skrevet til ledelsen.
• Gradvis udskiftning i praksis: hvad flytter I først? Hvilken del I tager først, hvordan gammelt og nyt kører samtidig, og hvornår det gamle kan lukke.

Kunderne

• Fra installeret software til SaaS: den tekniske omstilling Drift, flytning af data og de kunder, I allerede har, i en overgang, der sker i etaper.
• Når hver kunde har sin version af produktet Hvordan særaftaler bliver til teknisk gæld, og vejen tilbage til ét produkt.
• Kunderne vil ikke over på den nye version Plan for udfasning, kommunikation, trinvis flytning og hvornår den gamle version lukker.

Personen bag produktet

• Softwarehusets stifter stopper: koden, kunderne og overgangen Når én person har båret produktet i årevis, og overgangen skal planlægges over år.

Sådan kommer I i gang

Begynd med at beskrive, hvad produktet består af, og hvor det gør ondt. Hvilke dele ændres ofte? Hvilke dele må ingen røre? Hvem kender dem? Hvilke kunder står på hvilke versioner? Det overblik kan laves på kort tid af folk, der allerede kender produktet, og det gør samtalen med ledelsen meget lettere. Herefter kommer prioriteringen ind i den almindelige tekniske køreplan, så arbejdet med grundlaget får en plads ved siden af de nye funktioner.

Der er også nye krav at tage højde for. Sælger I produkter med digitale elementer, kan en væsentlig ændring betyde, at et ældre produkt kommer under kravene i Cyber Resilience Act. Det er beskrevet i Hvornår er en opdatering en væsentlig ændring?. Hænger jeres omstilling sammen med, at kunder stiller nye krav, er Når kunderne stiller krav til produktet næste sted at læse. I softwarehuse, hvor én erfaren person bærer det meste, er tidspunktet ofte vigtigere end metoden, for overgangen skal ske, mens den person stadig er der til at svare på spørgsmål.

Det skal I lade være med

• At love kunderne en ny version, før I kender vejen derhen · løftet bliver en dato, I ikke styrer.
• At stoppe al udvikling af det gamle produkt, mens det nye bygges · kunderne betaler for det, de har i dag.
• At sende den eneste, der kender koden, på det nye projekt alene · så står den gamle version uden svar.
• At vente, til teknologien har mistet support · så er det tidspunktet, der vælger for jer.

Det skal I kræve af den eksterne

• ☐ Respekt for det, produktet har båret, og for dem, der har bygget det.
• ☐ Erfaring med at ændre software, der er i drift hos kunder.
• ☐ Et grundlag for valget mellem de tre veje, som ledelsen kan læse.
• ☐ En plan, der tager højde for kunderne på de gamle versioner.

Senest gennemgået: november 2026.

Næste skridt

• Skal produktet skrives om?
• Gennemgang af produktet som første skridt

Læs også: Artikler om CTO as a Service · Teknisk køreplan og teknisk gæld

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT