Tilbage til Blog
Handover efter launch: Tjeklisten du bør kræve for dit website eller din app

Handover efter launch: Tjeklisten du bør kræve for dit website eller din app

En konkret handover-tjekliste efter launch: ejerskab/adgang, kildekode, infrastruktur-dokumentation, overvågning, backups, sikkerhed, analytics, træning og supportvilkår-så du undgår leverandørlåsning og dyre overraskelser efter 3–6 måneder.

Handover efter launch: Tjeklisten du bør kræve

De fleste websites og apps fejler ikke ved launch - de fejler tre til seks måneder senere.

Ikke fordi arbejdet nødvendigvis er “dårligt”, men fordi overdragelsen (handover) er mangelfuld: manglende logins, uklart ejerskab, ingen overvågning, ingen backups og for lidt dokumentation. Resultatet er langsommere fejlrettelser, uforudsete omkostninger og risiko for leverandørlåsning.

Hos Jensen Technologies har vi været webbureau i mange år, og vi ser det igen og igen: en god handover reducerer risiko mere end næsten ethvert valg af framework eller platform. Her er tjeklisten, vi anbefaler, at du som kunde insisterer på efter launch.

1) Ejerskab og adgang (ikke til forhandling)

Hvis du ikke kontrollerer kontiene, kontrollerer du ikke produktet. Bed om ét dokument, der lister alle konti og hvem der ejer dem.

  • Kontooversigt: domæne/registrar, DNS-udbyder, hosting/cloud, CDN, e-mail/SMS, analytics, tag manager, betalingsudbyder, CRM, helpdesk, app store-konti og automatiseringsværktøjer.
  • Admin-adgang overført til virksomhedens e-mails (ikke private adresser).
  • 2FA aktiveret og recovery-metoder dokumenteret.
  • Ejerskabskort: en enkel tabel over hvad I ejer, hvad bureauet ejer, og hvad tredjepart ejer.
Praktisk tip: Hvis en konto ikke kan overdrages, så kræv dokumenteret delt adgang og en tydelig exit-plan.

2) Kildekode og build artifacts

Selv hvis du ikke planlægger at skifte leverandør, bør du kunne fortsætte udviklingen i morgen med et andet team, hvis det bliver nødvendigt.

  • Adgang til repository (GitHub/GitLab/Bitbucket) eller en fuld eksport af kildekoden.
  • Production-version tagget (release-tag/commit-hash der matcher det, der kører live).
  • Build- og deploy-instruktion: hvordan projektet bygges, hvordan det deployes, og hvordan rollback foregår.
  • Miljøkonfiguration forklaret: hvad der er secrets, hvor de ligger, og hvordan de opdateres.

3) Infrastruktur og arkitektur-dokumentation

Du behøver ikke 40 sider. Du behøver nok klarhed til, at et kompetent team kan drifte og videreudvikle løsningen sikkert.

  • En side arkitektur-oversigt (inkl. centrale services og afhængigheder).
  • Hosting-detaljer: udbyder, region og hvilke tjenester der bruges.
  • Skaleringsantagelser: forventet trafik, baggrundsjobs, rate limits og kendte begrænsninger.
  • Runbook for typiske hændelser: nede, langsom, fejl i betaling, e-mails der ikke sendes, mobile builds der fejler.

4) Overvågning, logning og alarmer

Hvis du ikke kan se problemer, kan du ikke løse dem hurtigt. Overvågning er en del af leverancen.

  • Uptime-overvågning med tærskler og notifikationskanaler.
  • Error tracking (front-end og back-end) med brugbare alarmer.
  • Central logning: hvor logs ligger, hvem der har adgang, og retention-periode.
  • On-call forventninger: hvem får alarmer, og forventet responstid.

5) Backups og gendannelse (testet, ikke antaget)

Backups der aldrig er gendannet, er en betryggende historie - ikke en plan.

  • Hvad der backup’es: database, filuploads, objektlager, konfiguration og relevante tredjeparts-eksporter.
  • Frekvens og retention: dagligt, timebaseret, og hvor længe data gemmes.
  • Restore-proces dokumenteret og testet: hvornår blev der sidst gennemført en succesfuld gendannelse?

6) Sikkerhed og datahåndtering

Du behøver ikke perfektion, men du skal have en baseline: tydelige ansvarsområder og gentagelige rutiner.

  • Plan for dependency-opdateringer: hvordan security patches håndteres og hvor ofte.
  • Rettighedsgennemgang: least privilege for admins, CI/CD og tredjepartstjenester.
  • Secrets management: hvor nøgler ligger, hvordan de roteres, og hvem der har adgang.
  • Privacy-noter: hvilke data indsamles, hvorfor, og hvor de flyder (særligt vigtigt ift. GDPR).

7) Analytics og succeskriterier

Beslutninger efter launch bør være baseret på data, ikke mavefornemmelse.

  • Ejerskab af analytics overført (I skal være konto-ejer, ikke kun “user”).
  • Events/mål dokumenteret: hvad trackes, og hvordan det tolkes.
  • Liste over succeskriterier knyttet til forretning (leads, signups, køb, retention) - ikke kun sidevisninger.

8) Træning og drift-dokumentation

Dit team skal kunne klare det daglige uden at vente på en udvikler.

  • Admin-træning i CMS/backoffice (gerne optaget).
  • Korte “sådan gør du”-guides: redigér sider, administrér produkter, håndtér refunds, opret brugere, eksportér data.
  • Kendte begrænsninger og anbefalede næste forbedringer.

9) Garanti, support og vedligehold

Uklarhed her er ofte dér, budgetter skrider, og samarbejder bliver svære.

  • Bugfix-vindue: hvad tæller som en bug, og hvor længe er det dækket.
  • Proces for ændringer: hvordan nyt arbejde scopes, estimeres og godkendes.
  • Vedligeholdelsesmuligheder: hvad en månedlig aftale inkluderer (opdateringer, overvågning, mindre forbedringer, SLA).

Sådan bruger du tjeklisten

Hvis du står foran en launch, så bed om tjeklisten før endelig godkendelse. Hvis du allerede er live, kan en struktureret handover-audit stadig være pengene værd - ofte første gang noget går galt.

Hvis du vil vende, hvordan en god handover ser ud for jeres website eller app, eller hvis du vil have hjælp til at gennemgå jeres nuværende setup, så tag gerne kontakt til Jensen Technologies. Vi hjælper gerne med at gøre jeres digitale løsning lettere at eje, drifte og videreudvikle.