Overtagelse af eksisterende software: Sådan får I kontrollen

At overtage en eksisterende softwareløsning er sjældent bare et spørgsmål om at få adgang til Git-repositoriet. Den reelle løsning består også af drift, databaser, integrationer, domæner, cloud-konti, deployment, tredjepartstjenester – og viden, som måske kun findes i hovedet på den tidligere udvikler.

Vi overtager jævnligt løsninger, vi ikke selv har bygget. Den vigtigste erfaring er enkel: Man skal ikke starte med at omskrive. Man skal først skabe overblik, stabilitet og mulighed for at ændre sikkert.

Fase 1: Sørg for, at virksomheden faktisk ejer og kontrollerer løsningen

Før vi vurderer kodekvalitet, gennemgår vi adgange og ejerskab. Det omfatter typisk repositories, cloud- og hostingkonti, domæner og DNS, databaser, CI/CD, backup, overvågning, certifikater, app stores, mailtjenester og tredjepartslicenser.

Det lyder banalt, men manglende adgang er en af de største risici ved en overtagelse. En kritisk integration kan eksempelvis ligge på en tidligere leverandørs konto, eller deployment kan afhænge af credentials, ingen hos kunden har.

Fase 2: Få løsningen til at bygge og køre

Næste mål er ikke at forbedre arkitekturen. Det er at bevise, at det nye team kan hente koden, bygge den, konfigurere et miljø og gennemføre en deployment uden hjælp fra den tidligere udvikler.

Samtidig dokumenterer vi de dele, der ikke kan reproduceres. Det skaber en konkret risikoliste i stedet for en diffus fornemmelse af, at systemet er gammelt eller kompliceret.

Technical due diligence skal ende i beslutninger

Vi gennemgår arkitektur, frameworks, dependencies, databaser, integrationer, sikkerhed, test, deployment og dokumentation. Men værdien ligger ikke i en 80-siders rapport. Den ligger i prioriteringen bagefter.

Vi vil typisk kunne placere fund i tre bunker: noget der skal sikres nu, noget der bør forbedres, når vi alligevel arbejder i området, og noget der godt kan få lov at være grimt, fordi det fungerer og ikke udgør en reel risiko.

Drift fortæller ofte mere end kodekvalitet

En gammel kodebase kan være ganske driftssikker. En flot kodebase kan være farlig, hvis ingen ved, hvordan den deployes eller gendannes. Derfor kigger vi på backups, alarmer, logs, performance, fejlmønstre og tidligere incidents.

Kan en konkret fejl spores fra brugerens handling gennem integrationerne? Ved vi, hvornår backup sidst er testet? Kan løsningen rulles tilbage efter en fejlet release? Det er spørgsmål, der hurtigt afslører den operationelle modenhed.

Viden er også en dependency

Dokumentation er sjældent komplet. Derfor er overlevering fra de mennesker, der kender systemet, værdifuld. Vi spørger især efter de mærkelige ting: særregler, manuelle jobs, kunder med undtagelser og integrationer, der kun fejler under bestemte forhold.

Hvis den tidligere leverandør stadig er tilgængelig, er nogle få fokuserede workshops ofte mere værd end generelle arkitekturgennemgange.

De første 30 dage: stabilitet

Få styr på adgange, backup, deployment, overvågning og kritiske fejl. Undgå store refactorings. Teamet har endnu ikke nok kontekst til at vide, hvilke mærkelige dele af koden der faktisk beskytter en vigtig forretningsregel.

Dag 31–60: gør den næste ændring tryggere

Tilføj tests omkring de vigtigste flows, forbedr logging og automatisér de mest skrøbelige manuelle trin. Dokumentér arkitektur og integrationer på et niveau, som en ny udvikler faktisk kan bruge.

Dag 61–90: lav planen på baggrund af erfaring

Efter et par måneder har teamet både set kodebasen og oplevet den i drift. Nu giver det mening at beslutte, hvilke områder der skal moderniseres, og hvilke der kan blive stående.

En rewrite bør kun vælges, hvis den løser et konkret problem, som ikke kan håndteres forsvarligt trinvis. Ellers er risikoen ofte lavere ved løbende at forbedre systemet, mens det fortsat skaber værdi.

En god overtagelse skal hurtigt blive kedelig

Målet er ikke at imponere med en ny arkitektur. Målet er, at kunden efter kort tid ved, hvem der har ansvaret, at releases kan gennemføres sikkert, og at nye ønsker kan estimeres og udvikles uden frygt for, hvad der går i stykker.

Uptime overtager og videreudvikler eksisterende software – også løsninger bygget af andre leverandører. Vi kan starte med en teknisk gennemgang og en konkret plan for de første forbedringer.

En kodebase skal ikke forstås 100 %, før man kan skabe værdi. Få først styr på adgang, drift, risici og test – og skab derefter fremdrift uden at miste kontrollen.