Sådan overtager man en eksisterende kodebase uden at miste kontrollen

En praktisk guide til technical due diligence, adgang, test og de første 90 dage, når I overtager eller videreudvikler eksisterende software.

Start med adgang og ejerskab

Før I vurderer kode, skal I have kontrolleret ejerskab og adgang til kildekode, domæner, cloud-konti, CI/CD, overvågning, databaser, tredjepartslicenser og nøglepersoner. Manglende adgang er ofte den største tidlige risiko.

Lav en technical due diligence, der hjælper beslutningen

Kortlæg arkitektur, afhængigheder, sikkerhed, test, deployment, data og dokumentation. Målet er ikke en perfekt revisionsrapport, men at kunne prioritere: Hvad kan fortsætte, hvad skal sikres nu, og hvad kan vente?

Se efter driftssignaler, ikke kun kodekvalitet

Undersøg om løsningen kan bygges og deployes reproducerbart, om fejl kan spores, og om der findes backup, alarmer og en ejer af driften. En pæn kodebase uden driftsoverblik er stadig en risikofyldt overtagelse.

Testdækning og videnstab

Test er værdifulde, fordi de beskriver forventet adfærd. Når tests mangler, så begynd med kritiske flows frem for at forsøge at dække hele systemet. Interview også de mennesker, der kender undtagelserne i forretningen.

De første 30 dage

Stabilisér adgang, backups, deployment og de mest kritiske fejl. Aftal en fælles liste over kendte risici og undgå store omskrivninger, før teamet har set løsningen i drift.

Dag 31 til 60

Etabler basale test omkring vigtige flows, forbedr logging og overvågning, og dokumentér centrale afhængigheder. Prioritér små forbedringer, der gør den næste ændring tryggere.

Dag 61 til 90

Lav en moderniseringsplan med tydelige forretningsmål. En rewrite er kun relevant, hvis den reducerer en konkret risiko eller åbner en nødvendig mulighed; den er sjældent det rigtige første skridt.