Vendor lock-in voorkomen: waar moet u op letten?
Vendor lock-in is de situatie waarin overstappen naar een andere leverancier zo duur, tijdrovend of technisch lastig wordt dat u er in de praktijk niet meer voor kiest, ook als een alternatief beter of goedkoper is. Het risico speelt bij SaaS-pakketten en cloud-platforms, maar ook, vaak onderschat, bij maatwerk software. Deze pagina laat zien welke vormen van lock-in er zijn, hoe u ze herkent voordat u tekent, en welke maatregelen uw keuzevrijheid daadwerkelijk beschermen. Twijfelt u tussen een pakket en een eigen platform? Bekijk ook onze build-vs-buy-afweging.
Bespreek uw situatie Naar de checklistWat vendor lock-in precies is en waarom het meetelt
Vendor lock-in ontstaat niet op de dag dat u een contract tekent, maar in de jaren daarna, wanneer data, processen en teamkennis zich ophopen binnen één leverancier. Op dat moment verschuift de balans: niet u kiest meer of u blijft, de kosten en risico's van vertrek doen dat voor u. Dat speelt het duidelijkst bij SaaS-pakketten (CRM, ERP, HR-systemen) en cloud-infrastructuur, maar minstens zo vaak bij maatwerk software waarvan alleen de bouwer de architectuur begrijpt.
Waarom is dit meer dan een theoretisch risico? Drie redenen komen in de praktijk het vaakst terug. Ten eerste onderhandelingspositie: een leverancier die weet dat overstappen onrealistisch is, heeft weinig prikkel om prijzen scherp te houden. Ten tweede wendbaarheid: als een nieuw bedrijfsproces of integratie niet past binnen de grenzen van uw huidige systeem, kunt u niet zomaar switchen om het wel mogelijk te maken. Ten derde continuiteit: leveranciers worden overgenomen, stoppen met een productlijn of veranderen hun roadmap; zonder uitwijkmogelijkheid draagt u dat risico volledig.
Vier vormen van vendor lock-in
Lock-in is geen eenduidig risico. Het ontstaat op vier verschillende lagen, en elke laag vraagt om een andere maatregel.
Data-lock-in
Jarenlange administratie, rapportages en klantrecords raken opgeslagen in een systeem dat geen bruikbare export biedt, of alleen in een eigen, ongedocumenteerd bestandsformaat. Zonder die data opnieuw handmatig in te voeren kunt u niet weg.
Technisch lock-in
Propriëtaire architecturen en gesloten formaten maken integratie met andere systemen lastig. Een tegenvoorbeeld laat zien hoe het anders kan: de Amazon S3 API is inmiddels de facto standaard voor objectopslag geworden, waardoor S3-compatibele opslag bij andere aanbieders mogelijk is zonder alles opnieuw te bouwen.
Contractueel lock-in
Lange looptijden, hoge opzegvergoedingen of het ontbreken van een clausule over dataoverdracht bij contractbeëindiging. Dit lock-in zit niet in de techniek maar puur in de juridische afspraken.
Kennis-lock-in bij één partij
De architectuur, code en werking van een systeem zitten alleen in het hoofd van één leverancier of ontwikkelpartner. Dit speelt het sterkst bij maatwerk software zonder overgedragen documentatie, hieronder gaan we hier dieper op in.
Signalen dat u al vastzit
Vier vragen die in de praktijk het snelst duidelijk maken hoe vast u zit bij uw huidige leverancier.
Geen bruikbare export
U kunt data alleen bekijken binnen het systeem zelf, niet exporteren in een standaardformaat zoals CSV of JSON.
Eenzijdige prijsstijgingen
De leverancier verhoogt tarieven zonder dat u binnen een redelijke termijn een realistisch alternatief heeft.
Niemand anders begrijpt het
Er bestaat geen actuele documentatie en de kennis over hoe het systeem werkt zit bij één persoon of partij.
Boetes bij vertrek
Opzegvergoedingen of kosten voor dataoverdracht die geen relatie hebben met de daadwerkelijke inspanning.
Ook maatwerk software kan lock-in geven
Maatwerk wordt vaak gepresenteerd als het antwoord op vendor lock-in: geen pakket, dus geen afhankelijkheid. Dat klopt niet automatisch. Als de broncode niet aan u toebehoort, als er geen actuele architectuurdocumentatie bestaat, of als slechts één klein ontwikkelbureau de applicatie daadwerkelijk begrijpt, zit u net zo vast als bij een SaaS-pakket. Alleen heet uw leverancier dan een ontwikkelpartner in plaats van een softwareverkoper, en is de afhankelijkheid vaak minder zichtbaar omdat er geen jaarlijkse licentiefactuur is die u eraan herinnert.
Stel daarom bij elke partij die voor u bouwt, of dat nu wij zijn of een andere partner, dezelfde vragen die u ook aan een SaaS-leverancier zou stellen: wie is eigenaar van de broncode en documentatie, gebruikt de codebase gangbare en veelgebruikte technologie in plaats van een uniek zelfgebouwd framework, is er een actuele technische documentatie die een andere partij zou kunnen overnemen, en wat gebeurt er concreet als de samenwerking stopt. Bij low-code-platformen speelt een vergelijkbaar risico op platformniveau: Mendix, OutSystems en Power Apps bieden snelheid, maar de gebouwde applicatie draait wel binnen hun runtime en licentiemodel. Twijfelt u of low-code of maatwerk beter past? Lees onze vergelijking tussen low-code en maatwerk development.
Praktische maatregelen om lock-in te voorkomen
Geen van deze maatregelen is een garantie, maar samen verkleinen ze de kans dat u ooit vastzit zonder alternatief.
Kies open standaarden
Waar mogelijk systemen met open, gedocumenteerde API's. De S3 API is hier een goed voorbeeld van: doordat deze de facto standaard werd voor objectopslag, kunt u bij meerdere aanbieders S3-compatibele opslag afnemen zonder alles opnieuw te bouwen.
Eis dataportabiliteit
Vraag om export in gangbare formaten zoals CSV, JSON of Parquet in plaats van een propriëtair formaat. Voor persoonsgegevens die op basis van toestemming of overeenkomst geautomatiseerd worden verwerkt, heeft u in de EU bovendien het recht op dataportabiliteit onder artikel 20 AVG.
Leg exit-afspraken vast
Redelijke opzegtermijnen, en waar de impact van vertrek groot is een source-code-escrow-overeenkomst: de broncode wordt bij een onafhankelijke derde gedeponeerd en vrijgegeven als de leverancier stopt of niet meer aan verplichtingen voldoet.
Vraag documentatie als opleverpunt
Architectuurdocumentatie, datamodel en API-specificatie horen bij de oplevering, niet als losse bijlage die er later wel bij komt. Zonder die documentatie is elke overstap duurder dan nodig.
Checklist bij een nieuwe softwarepartner of pakket
Vijf vragen om te stellen voordat u tekent, ongeacht of het om een pakket, een SaaS-abonnement of een maatwerktraject gaat.
Export zonder tussenkomst?
Kunt u data exporteren in een standaardformaat zonder afhankelijk te zijn van medewerking van de leverancier?
Wie is eigenaar?
Bent u bij maatwerk eigenaar van de broncode en documentatie, of alleen gebruiksgerechtigd op het resultaat?
Wat kost vertrek?
Wat zijn de opzegtermijnen, en welke kosten staan er tegenover een overstap naar een andere partij?
Bestaat er documentatie?
Is er actuele technische documentatie die een andere partij daadwerkelijk zou kunnen overnemen?
Krijgt u op een van deze vragen geen bevredigend antwoord, dan is dat geen reden om per definitie af te zien van de samenwerking, maar wel een signaal om de afspraken vooraf scherper vast te leggen in plaats van erop te vertrouwen dat het goed komt.
Veelgestelde vragen over vendor lock-in
Een onafhankelijke blik op uw softwarearchitectuur
Wij bouwen maatwerk software en koppelingen met bestaande pakketten, en denken vanaf het ontwerp mee over open standaarden en dataportabiliteit zodat u niet vastloopt bij een toekomstige overstap.
Plan een vrijblijvend gesprek