Bedrijfssoftware overdragen: wat moet een andere partner kunnen?

Met toegang tot de broncode kan een ontwikkelaar zien hoe een toepassing is geschreven. Daarmee is nog niet duidelijk hoe je haar bouwt, welke externe diensten nodig zijn, welke instellingen bij de omgeving horen of waarom een bedrijfsregel zo is ingericht.

Maak daarom een overzicht van de onderdelen waarop het platform steunt. Leg per onderdeel vast wie het beheert, wie het overneemt en hoe de ontvangende partij controleert of de overdracht bruikbaar is.

Onderdeel	Wat de ontvangende partij moet kunnen aantonen
Broncode en versie	De versie vinden die werkelijk gebruikt wordt en die kunnen bouwen
Accounts en diensten	Toegang tot de benodigde cloudomgeving, domeinen en koppelingen volgens de afgesproken rechten
Bedrijfskennis	De belangrijkste regels, uitzonderingen en gegevensbetekenis kunnen uitleggen
Opleveren	Een wijziging testen en in een afgescheiden omgeving installeren
Beheer	Meldingen onderzoeken, ondersteuning vinden en de herstelprocedure beproeven
Openstaand werk	Weten welke problemen, afhankelijkheden en besluiten nog niet zijn opgelost

Wachtwoorden of geheime sleutels horen niet in een algemeen overdrachtsdocument. Beschrijf waar ze veilig beheerd worden en hoe toegang wordt toegekend en ingetrokken.

Een partner kan het dagelijkse beheer verzorgen terwijl jullie organisatie zeggenschap houdt over de omgeving en de samenwerking. Dat vraagt om passende accounts, rechten en herstelmogelijkheden.

Voor Google Cloud kan dat betekenen dat projecten onder de organisatie vallen in plaats van afhankelijk te zijn van een individueel account. Controleer naast de inrichting ook welke beheerders toegang hebben en wie facturatie en accountherstel beheert. De Google Cloud-documentatie legt uit hoe die organisatiehiërarchie werkt.

Cloudtoegang en rechten op maatwerk zijn verschillende onderwerpen. Leg ook de afspraken over gebruik, aanpassing, documentatie, componenten van derden en ondersteuning bij overdracht expliciet vast met de betrokken partijen.

De moeilijkste kennis zit niet altijd in de techniek. Waarom wordt een opdracht na deze status vastgezet? Waarom mag een medewerker dit gegeven wel zien maar niet veranderen? Waarom krijgt een bepaald type klant een andere route?

Zonder die context kan een technisch nette wijziging een belangrijke bedrijfsafspraak beschadigen. Documenteer daarom de betekenis van centrale begrippen, belangrijke beslissingen en uitzonderingen.

Koppel die uitleg waar mogelijk aan tests en herkenbare situaties. Een nieuwe ontwikkelaar moet kunnen begrijpen welk gedrag behouden moet blijven, niet alleen welk bestand moet worden aangepast.

Laat een tweede ontwikkelaar met de documentatie een afgescheiden testomgeving opzetten. Gebruik fictieve of daarvoor geschikt gemaakte gegevens, geen onnodige kopie van productiegegevens. Laat die persoon daarna een kleine wijziging uitvoeren, testen en in de testomgeving opleveren.

Beoordeel wat zelfstandig lukte en waar mondelinge uitleg nodig was. Kan de ontwikkelaar uitleggen hoe een belangrijke klantafspraak door de toepassing loopt? Is duidelijk hoe een mislukte oplevering wordt hersteld? Zijn de benodigde afhankelijkheden en instellingen beschreven?

Deze proef is geen examen voor de huidige partner. Ze maakt zichtbaar welke kennis nog bij één persoon zit en waar je de documentatie kunt verbeteren.

Leg met de oude en nieuwe verantwoordelijken vast wanneer het beheer overgaat, welke ondersteuning beschikbaar blijft en wie openstaande problemen behandelt. Controleer toegang en verwijder oude rechten op het afgesproken moment, zonder noodzakelijke ondersteuning voortijdig af te sluiten.

Een overdracht hoeft niet meteen een volledige herbouw te worden. Bij een Amerikaanse bouwmaterialenleverancier werken we aan onderhoud en modernisering van bestaande toepassingen en ondersteunen we interne ontwikkelaars. Verder bouwen op aanwezige kennis is daar onderdeel van het werk.

Ontbreken code, toegang of uitleg? Laat eerst vaststellen wat beschikbaar is en welke onderdelen nog bij de huidige partner moeten worden opgevraagd. Zeg noodzakelijke diensten niet op voordat duidelijk is hoe het platform kan blijven functioneren. Maak ontbrekende onderdelen en hun verantwoordelijken onderdeel van het overdrachtsplan.

Software overnemen beschrijft hoe we een nieuwe verantwoordelijkheid beoordelen en voorbereiden. Een goede samenwerking geeft je redenen om te blijven én de mogelijkheid om later anders te kiezen.