Wat is een applicatie?

Een applicatie is software waarmee gebruikers een taak uitvoeren, zoals een klantportaal, een planningssysteem of een webshop-backoffice. Bij een webapplicatie draait die software op een server en gebruik je hem via de browser. Overnemen betekent dat een nieuwe partij de code, de hosting en het beheer ervan op zich neemt.

Kun je zomaar een applicatie overnemen?

Alleen als je de rechten en de toegang hebt. Controleer in je contracten of de broncode van jou is en zorg dat je beheerdersrechten hebt op de repository, de hosting en het domein. Zonder die toegang ben je afhankelijk van de goede wil van je vorige leverancier.

Wat kost het om een applicatie over te nemen?

Dat hangt af van de staat van de code, de documentatie, de gebruikte versies en hoeveel kennis er nog beschikbaar is. Een codebase scan geeft je vooraf inzicht in de risico's en het werk, zodat je een inschatting op maat krijgt in plaats van een gok.

Wat als de vorige developer niet meer bereikbaar is?

Dan begin je bij wat je wél hebt: de draaiende applicatie, de server en eventueel een kopie van de code. Een ervaren team kan de code vanaf de server veiligstellen, een werkende ontwikkelomgeving opbouwen en de ontbrekende documentatie stap voor stap aanvullen.

Wat zijn de mogelijkheden om een applicatie over te nemen?

Grofweg drie: je eigen team neemt het over, je schakelt een freelancer in, of een bureau neemt beheer en doorontwikkeling over. Bij een overname van een bedrijf komt daar technische due diligence bij, zodat je weet wat je koopt.

Applicatie overnemen checklist: code, toegang en kennis

Een applicatie overnemen gebeurt zelden op een rustig moment. Meestal vertrekt een developer, stopt een bureau of koop je een bedrijf waar de software een belangrijk onderdeel van is. Met deze applicatie overnemen checklist zorg je dat je eigenaar blijft van je code, toegang hebt tot alles wat nodig is en de kennis niet met de vorige partij de deur uit loopt.

We nemen al jaren bedrijfskritische webapplicaties over, waaronder meerdere Symfony-applicaties die eerder door anderen zijn gebouwd. Deze checklist is gebaseerd op wat we in die overnames tegenkomen.

Twee situaties: beheer overnemen of software kopen

Er zijn twee situaties waarin je een applicatie overneemt:

Het beheer gaat over. De applicatie blijft van jouw bedrijf, maar een andere partij gaat hem onderhouden en doorontwikkelen. Bijvoorbeeld omdat je developer vertrekt of je huidige leverancier stopt.
De applicatie wisselt van eigenaar. Je koopt een bedrijf, webshop of SaaS-platform, en daarmee de software. Dan ben je de koper en wil je weten wat de verkoper je precies overdraagt.

De technische checklist is in beide gevallen hetzelfde. Bij een overname van een bedrijf komen er afspraken in het overnametraject bij, die we verderop behandelen.

Wanneer begin je?

Het beste moment om te beginnen is vóórdat de vorige partij vertrekt. Zolang de developer of het bureau nog bereikbaar is, kun je vragen stellen, toegang laten overzetten en kennis vastleggen. Wacht je tot er iets misgaat, dan zoek je onder tijdsdruk naar wachtwoorden en uitleg.

De applicatie overnemen checklist in vijf onderdelen

De checklist hieronder bestaat uit vijf onderdelen. Loop ze in deze volgorde door, want iedere stap bouwt voort op de vorige: eerst toegang, dan de code, dan hosting, beveiliging en tot slot de kennis.

Checklist 1: eigendom en toegang

Begin hier. Zonder toegang is elke volgende stap afhankelijk van je oude leverancier.

De broncode staat in een repository (bijvoorbeeld GitHub of GitLab) waar jouw bedrijf eigenaar van is.
In het contract staat dat de code en het intellectueel eigendom van jou zijn.
Je hebt beheerdersrechten op de hosting, de server en de database.
Het domein en de DNS staan op naam van je bedrijf.
Je hebt toegang tot alle externe diensten: e-mail, betalingen in de webshop, API’s, opslag en monitoring.
Licenties en abonnementen staan op jouw naam of zijn over te zetten.
Wachtwoorden en API-sleutels zijn overgedragen via een wachtwoordmanager en daarna vervangen.

Checklist 2: de codebase overnemen

Als de toegang geregeld is, kijk je naar de code zelf. Hier zie je hoeveel werk de overname wordt.

Welke taal, welk framework en welke versies worden gebruikt, en worden die nog ondersteund?
Zijn de dependencies (bijvoorbeeld via Composer) bij te werken zonder conflicten?
Kan een nieuwe developer de applicatie lokaal draaien met een beschreven stappenplan?
Zijn er automatische tests, en draaien die?
Hoe gaat een release van test naar productie? Is dat vastgelegd of zit het in iemands hoofd?
Is er documentatie over de architectuur, de databases en de koppelingen?
Welke bekende bugs en openstaande wensen zijn er?

Loopt de applicatie ver achter, bijvoorbeeld op een oude PHP-versie of een framework dat end of life is? Dan is er sprake van technische schuld die je in je planning moet meenemen. Draait hij op Symfony, lees dan ook hoe je een Symfony upgrade aanpakt.

Checklist 3: hosting, back-ups en monitoring

Waar draait de applicatie en wie betaalt de hosting?
Worden er dagelijks back-ups gemaakt, op een andere locatie dan de server zelf?
Is een back-up de afgelopen tijd ook echt teruggezet als test?
Is er monitoring die waarschuwt bij storingen of fouten?
Zijn SSL-certificaten en domeinverlengingen geautomatiseerd?
Is er een test- of stagingomgeving naast productie?

Checklist 4: beveiliging en privacy

Welke persoonsgegevens verwerkt de applicatie, en waar staan die?
Zijn er verwerkersovereenkomsten met de partijen die bij die gegevens kunnen?
Wie heeft er nu toegang? Verwijder accounts van mensen en bedrijven die niet meer betrokken zijn.
Zijn er bekende beveiligingsproblemen of eerdere incidenten?
Worden security-updates van framework en packages bijgehouden?

Checklist 5: kennis en overdracht

De meeste kennis zit niet in de code, maar in de hoofden van mensen. Plan daarom bewust de overdracht.

Plan één of meer overdrachtssessies met de vorige developer of het vorige bureau.
Laat de belangrijkste processen voordoen: een release, een back-up terugzetten, een veelvoorkomend probleem oplossen.
Vraag naar de “rare” plekken in de code: wat is ooit snel opgelost en nooit opgeruimd?
Leg vast wie de vaste gebruikers en contactpersonen zijn bij klanten en leveranciers.
Spreek af hoe lang je oude developer of bureau nog ondersteuning biedt en bereikbaar is voor vragen.

Software overnemen: aandachtspunten voor koper en verkoper

Koop je een bedrijf, webshop of SaaS-product, dan is de software vaak een groot deel van de waarde. Voor veel ondernemers is de applicatie zelfs de bron van de omzet. Naast het boekenonderzoek naar omzet en winst hoort er dan ook een technisch onderzoek bij. Dat doe je in de fase vóór het bod, zodat de uitkomst kan meewegen in de onderhandelingen over de koopprijs. Een paar aandachtspunten:

Geheimhoudingsovereenkomst eerst. De verkoper laat de code pas zien nadat er een geheimhoudingsovereenkomst (NDA) is getekend. Bij ons is een NDA standaard.
Technische due diligence. Laat de codebase onderzoeken voordat je een bod doet of de intentieverklaring tekent. Zo weet je of de applicatie kan groeien met je plannen, of eerst flink moet worden bijgewerkt.
Afspraken in de koopovereenkomst. Leg vast dat de code, de domeinen en de accounts worden overgedragen, en welke garanties de verkoper geeft over eigendom en licenties van de software.
Kennis na de overname. Is de software afhankelijk van één medewerker of de medeoprichter? Spreek dan af dat die na de overdracht nog een periode beschikbaar blijft, bijvoorbeeld als onderdeel van een earn-out, waarbij een deel van de koopprijs afhangt van de resultaten na de overname.

Wil je juist je eigen bedrijf verkopen? Dan helpt een opgeruimde codebase met documentatie. De koper kan de waarde makkelijker bepalen, en je voorkomt dat technische twijfels het overnametraject vertragen. Spreek je een earn-out af, dan heb je als verkoper zelf ook belang bij een applicatie die na de overdracht soepel blijft draaien. Leg ook dat vast in de koopovereenkomst.

Juridische en financiële vragen leg je bij je adviseur neer. De technische vraag, of deze applicatie doet wat je denkt en wat het kost om hem te onderhouden, kunnen wij beantwoorden.

Stappenplan: de eerste 30 dagen na de overname

Is de overdracht rond? Dan doen we in de eerste weken steeds dezelfde stappen:

Stabiliseren: back-ups controleren, monitoring inrichten en kritieke security-updates doorvoeren.
Toegang opschonen: oude accounts en sleutels intrekken.
Ontwikkelomgeving opzetten: zodat elke developer de applicatie kan draaien en testen.
Documenteren: wat we leren, schrijven we op.
Plannen: een lijst met risico’s, upgrades en verbeteringen. Samen bepalen we de prioriteiten, zodat jij de focus houdt op je bedrijf.

Daarna gaat de applicatie over in regulier onderhoud. Een aantal Symfony-applicaties die we zo hebben overgenomen, onderhouden we nu met een vast aantal dagen per maand.

Applicatie laten overnemen door een ervaren team

Heb je zelf geen Symfony- of PHP-expertise in huis, of wil je weten wat je overneemt voordat je ergens aan vastzit? Met een codebase scan krijg je een eerlijk beeld van de code, de versies en de risico’s. Daarna kunnen we het beheer en de doorontwikkeling overnemen: lees hoe we een bestaande applicatie overnemen en onderhouden. De code blijft altijd van jou.

Applicatie overnemen: de checklist voor een soepele overdracht