Et skift af udviklingsleverandør lykkes, når rækkefølgen er rigtig: først sikrer I adgangene, så kortlægger I den viden, der skal flyttes, derefter finder I den nye og lader de to overlappe, og til sidst gennemfører I overdragelsen med en prøve på, at den nye kan arbejde selv. Den dyreste fejl er at sige op først. Så mister I både velviljen og tiden, mens produktet stadig skal køre for kunderne.
Trin 1: Sikr adgange, før nogen hører om skiftet
Så længe samarbejdet kører, er det normalt at bede om orden i konti og adgange. Gør det nu, som en almindelig oprydning. Kontrollér, at I står som ejer af kodelager, cloudkonto, domæne og app-butikker, og gennemgå dem med ejer I selv koden og kontiene.
Hent en fuld kopi af koden med historik, og læg den et sted, I selv råder over. Tag også en kopi af databasen, hvis I kan gøre det forsvarligt. Lav en liste over de eksterne tjenester, produktet er afhængigt af. Læs aftalen om opsigelsesvarsel, rettigheder og overdragelsesbistand, og lad en advokat se på den, hvis der er tvivl. Det tekniske grundlag bør stå i aftalen, se kravene til udviklingsaftalen. Mangler de, forhandler I med mindre i hånden.
Trin 2: Kortlæg den viden, der skal flyttes
Koden er kun en del af produktet. Resten ligger i folks hoveder og i små opsætninger, som ingen tænker på. Skriv ned:
- Hvordan produktet bygges og sættes i drift, og hvem der gør det i dag.
- Hvilke kundeaftaler, særlige opsætninger og midlertidige løsninger der findes.
- Hvad der overvåges, og hvem der får besked, når noget går galt.
- Hvilke kendte fejl og svage steder der ligger gemt.
- Hvilke kørsler der sker med faste mellemrum, fx om natten eller ved månedsskift.
Spørg også efter de personer, der kender produktet bedst. Ofte er det én eller to udviklere, og det er dem, I skal have tid med, når overdragelsen kommer. Læs når én udvikler kender hele koden, hvis det billede virker bekendt.
Trin 3: Find den nye, før I siger op
Vælg den nye ud fra det, der gik galt hos den gamle. Var problemet kvalitet, kommunikation eller blot manglende kapacitet? Vis koden til de kandidater, der kommer tæt på, under fortrolighed, så tilbuddet bygger på virkeligheden. Bed om en plan for de første uger og en prøve på, at de kan bygge og køre produktet selv.
Vær på vagt, når den nye vurderer den gamles arbejde. De fleste nye leverandører vil finde meget at kritisere, og nogle vil foreslå at begynde forfra. Hvordan I håndterer det, står i artiklen om forslaget om at lave alt om.
Overvej samtidig, om I skal have en leverandør igen, eller om tiden er kommet til at tage udviklingen hjem.
Trin 4: Overlappet
Læg en periode ind, hvor begge leverandører er på, og hvor den gamle betales for at overdrage. Længden afhænger af produktets størrelse, så lad den nye sige, hvad der skal til. Fokusér overlappet på det praktiske:
- Den nye sætter produktet op fra bunden ud fra dokumentationen.
- Den nye laver en udgivelse med den gamle ved siden af.
- Den nye retter et par rigtige fejl.
- Den gamle gennemgår de steder, der gør ondt.
Sæt ord på det over for den gamle leverandør. En rolig og saglig besked virker bedst: I vælger at gå en anden vej, I respekterer aftalen, og I vil gerne have en ordentlig overdragelse, som bliver betalt. Mange leverandører opfører sig ordentligt, når de bliver behandlet ordentligt. Afgør på forhånd, hvad I gør, hvis overlappet ikke er muligt.
Trin 5: Overdragelsen
Overdragelsen er færdig, når den nye har kørt en udgivelse selv og håndteret en fejl uden hjælp. Først da lukker I den gamles adgange. Skift adgangskoder og nøgler, og fjern brugere overalt, herunder i de små tjenester. Gør det planlagt, med den nye klar til at rette, hvis noget stopper.
Fortæl kunderne det, de skal vide, og ikke mere. Kommer der ikke ændringer for dem, er der som regel ingen grund til en stor udmelding. Hold øje med driften i nogle uger efter skiftet, og hold plads i planen. Der kommer til at gå noget tid, før den nye er på fuld fart, så lav ikke store løfter til kunder i den periode.
Skal nogen lede forløbet på jeres side, kan Nielco IT gøre det som fractional CTO: plan, valg af ny leverandør, styring af overlappet og løbende status til ledelsen. Udviklingen bliver hos leverandørerne.
Det skal I lade være med
- At sige op, før adgangene er sikret · så har I intet at forhandle med.
- At lade den nye starte forfra uden begrundelse · se først, hvad der kan genbruges.
- At lukke den gamles adgange for tidligt · I kan få brug for hjælp, indtil den nye har bevist, at det kører.
- At love kunderne ny funktionalitet i overgangen · der går tid, før farten er tilbage.
Det skal I kræve af den eksterne
- ☐ En tjekliste for adgange og konti, kontrolleret med jeres egne logins.
- ☐ En skriftlig plan med rækkefølge, overlap og beslutningspunkter.
- ☐ Kriterier for, hvornår den nye er klar til at stå alene.
- ☐ Løbende status til ledelsen om risiko og tidsplan.
- ☐ Valg af ny leverandør uden økonomisk interesse i udfaldet.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Brændt af et udviklingshus: hvad gør I nu? · Hvornår er en leverance færdig?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
