Wat is vendor lock-in? Betekenis, voorbeelden en hoe je eruit komt

Je werkt al jaren met dezelfde software. De boekhouding staat erin, de klantgegevens, misschien een webshop of een stuk automatisering. Alles loopt, tot je iets wilt veranderen: overstappen naar een goedkoper pakket, een koppeling maken die je leverancier niet biedt, of gewoon je eigen data ergens anders naartoe halen. En dan blijkt het niet te kunnen. Je gegevens zitten vast in een formaat dat alleen dat ene pakket leest, de export levert een onbruikbare puinhoop op, of het contract rekent een fors bedrag om te vertrekken. Dat is vendor lock-in, en het is een van de duurste valkuilen in bedrijfssoftware.

Deze gids is voor de ondernemer, IT-verantwoordelijke of teamleider, van MKB tot een afdeling van een grotere organisatie, die wil begrijpen wat vendor lock-in precies is, hoe het er in de praktijk uitziet, en vooral: hoe je meet hoe vast je zelf zit en wat je eraan kunt doen. Geen paniekverhaal, maar een nuchtere uitleg met herkenbare voorbeelden, een zelftest en een beslisboom naar je volgende stap.

Wat vendor lock-in precies is

Vendor lock-in, in gewoon Nederlands leveranciersafhankelijkheid, is de situatie waarin overstappen naar een andere leverancier zo duur, ingewikkeld of risicovol is dat je in de praktijk vastzit, ook als je ontevreden bent. Je blijft niet omdat het product het beste is, maar omdat weggaan te veel pijn doet. De leverancier weet dat, en dat verschuift de macht in de relatie stilletjes zijn kant op.

Belangrijk om te snappen: lock-in is geen ja of nee. Het is een schaal, en hij heeft meerdere vormen die vaak tegelijk spelen:

• Data-lock-in. Je gegevens staan opgesloten in het platform. Er is geen fatsoenlijke export, of wat eruit komt is onbruikbaar zonder het originele systeem.
• Formaat- of technische lock-in. Je data komt er wel uit, maar in een propriëtair formaat dat geen ander pakket kan lezen. Of je processen leunen op functies en koppelingen die alleen deze leverancier heeft.
• Contractuele lock-in. Lange looptijden, automatische verlengingen, opzegtermijnen of exit-kosten die vertrekken duur maken.
• Kennis-lock-in. De werking van je systeem zit in het hoofd van de leverancier of in ongedocumenteerde maatwerkcode. Niemand anders kan het overnemen.
• Ecosysteem-lock-in. Losse producten die alleen soepel samenwerken binnen één merk (agenda, mail, opslag, documenten), zodat één onderdeel vervangen de rest breekt.

De diepste oorzaak zit bijna altijd onder al die vormen: zolang je software dichtgetimmerd is en je data in een formaat staat dat alleen die ene leverancier leest, heb je geen keuze maar een afhankelijkheid. Daarom is eigenaarschap over je code, data en documentatie je beste bescherming tegen lock-in, niet als ideaal, maar omdat het je de exit-optie geeft die je macht teruggeeft.

Vijf plekken waar lock-in ontstaat

Lock-in is abstract tot je het in je eigen systemen herkent. Hieronder de plekken waar het in het MKB het vaakst ontstaat, met per categorie waar je de uitweg vindt.

Twee categorieën verdienen extra toelichting. Bij de boekhouding zit je vaak minder vast dan je denkt: de Auditfile Financieel is een open standaard die met de Belastingdienst is ontwikkeld en die je in vrijwel elk pakket kunt in- en uitlezen, van Exact Online tot kleinere aanbieders. Een complete auditfile is geen garantie dat alles meeverhuist (koppelingen en historische rapportages niet), maar je grootboek en mutaties zijn niet gegijzeld.

Bij de cloud is de situatie sinds kort structureel verbeterd. De EU Data Act, die sinds 12 september 2025 van kracht is zonder overgangsregeling, verplicht clouddiensten om je data in een gestructureerd, machineleesbaar formaat terug te geven, en overstapkosten (waaronder de beruchte data-uitvoerkosten) mogen alleen nog de directe kosten dekken en zijn vanaf 12 januari 2027 helemaal verboden. Grote aanbieders schrapten hun data-uitvoerkosten bij vertrek al vooruitlopend hierop, al gelden daar vaak voorwaarden zoals goedkeuring vooraf en een migratievenster van zestig dagen. Dat een recht op papier staat, betekent nog niet dat je leverancier het uit zichzelf komt brengen: de rechten op je cloud moet je zelf in je architectuur inbouwen en opeisen.

Bij AI sluipt lock-in er het onopvallendst in, omdat automatiseringen en agents vaak op de specifieke API van één aanbieder leunen. Wie zijn AI-stack leverancier-onafhankelijk opzet met een abstractielaag en open-weight uitwijk, houdt de vrijheid om te wisselen als prijzen of voorwaarden veranderen.

Wat je nodig hebt

Voor de zelftest hierna heb je weinig nodig, maar wel dit:

• Een lijst van je kernsystemen: boekhouding, CRM, webshop, cloud en werkplek, maatwerk en de AI-tools die je echt gebruikt.
• Toegang tot je contracten of algemene voorwaarden, zodat je looptijd, opzegtermijn en exit-bepalingen kunt nakijken.
• Vijf minuten per systeem om de export-knop echt te testen, in plaats van aan te nemen dat hij werkt.
• Waar mogelijk iemand die technisch kan beoordelen of een export ook bruikbaar is, en niet alleen bestaat.

Zelftest: hoe vast zit je?

De lock-in-zelftest scoort per kernsysteem hoe afhankelijk je bent, van 0 (volledig vast) tot 10 (vrij). Je beoordeelt vijf assen: data-export, dataformaat, contract, kennis en koppelingen. De optelsom laat per systeem zien hoe kwetsbaar je bent, en welk systeem je als eerste moet aanpakken.

Loop per systeem deze vijf vragen langs en geef elke as 0 punten (vast), 1 punt (deels) of 2 punten (vrij):

1. Data-export (0 tot 2). Kun je met een druk op de knop al je data eruit halen, zonder de leverancier om hulp te vragen? Voor persoonsgegevens heb je sowieso recht op dataportabiliteit: je gegevens in een gestructureerd, veelgebruikt en machineleesbaar formaat, maar dat recht dekt lang niet al je bedrijfsdata.
2. Dataformaat (0 tot 2). Komt de export in een open, gangbaar formaat (CSV, XML, een standaard als de auditfile) dat een ander systeem kan inlezen, of in iets propriëtairs dat alleen dit pakket begrijpt?
3. Contract (0 tot 2). Kun je binnen een redelijke termijn opzeggen, zonder lange verplichte looptijd, automatische verlenging of exit-boete?
4. Kennis en documentatie (0 tot 2). Is vastgelegd hoe je systeem werkt, zodat een ander het kan overnemen, of zit die kennis alleen bij de leverancier?
5. Koppelingen (0 tot 2). Draaien je processen op open koppelingen die je kunt nabouwen, of op unieke functies van deze ene leverancier?

Tel de punten op. 8 tot 10 betekent lage lock-in: je zit ruim in je vrijheid. 4 tot 7 is kwetsbaar: op papier kun je weg, in de praktijk kost het moeite. 0 tot 3 is hoog risico: hier zit je vast, en dit systeem verdient je eerste aandacht. Doe dit voor elk kernsysteem, want de kans is groot dat één of twee systemen je hele bedrijf gijzelen terwijl de rest prima scoort.

Je volgende stap: de beslisboom

De uitkomst van de zelftest bepaalt niet óf je iets moet doen, maar wát. Niet elk systeem met een lage score hoef je te vervangen, soms is het slimmer om je positie te versterken waar je zit.

Concreet komen daar drie routes uit:

• Blijven, maar je risico afdekken. Wil je bij een leverancier blijven waar je vast zit, onderhandel dan een exit-clausule en een gegarandeerde data-export in je contract, het liefst bij de volgende verlenging als je onderhandelingspositie het sterkst is. Dat dit geen theorie is, blijkt zodra een investeerder je softwareleverancier overneemt en je exitrechten ineens goud waard zijn.
• Data-export en documentatie regelen. Bij een matige score is de winst vaak klein en concreet: zet een periodieke export op (maandelijks een auditfile of CSV-dump), en leg de werking van je maatwerk vast zodat de kennis niet bij één partij blijft hangen.
• Overstappen. Loont het niet meer, test dan eerst of de export echt bruikbaar is voordat je een overstap plant. Een gefaseerde migratie van Microsoft 365 naar een soevereine werkplek laat zien hoe je zoiets stap voor stap doet zonder je bedrijf plat te leggen.

Valkuilen

• De export-knop die je nooit test. "Er zit een export in" is geen garantie. Test hem, en laat iemand controleren of het bestand ook echt in een ander systeem valt te laden.
• Data in de cloud verwarren met eigenaarschap. Dat je gegevens ergens veilig staan, betekent niet dat je ze kunt meenemen. Eigendom van data is iets anders dan toegang tot data.
• Alleen op maandprijs kiezen. De goedkoopste tool van nu is de duurste als je er over drie jaar niet uit komt. Reken de overstapkosten mee in de keuze, niet pas als je al vastzit.
• Maatwerk zonder afspraken over code en data. Laat je iets bouwen, leg dan vast dat de broncode, de data en de documentatie van jou zijn en op jouw accounts staan. Anders ruil je één afhankelijkheid in voor een andere.
• Lock-in wegwuiven met "ik stap toch nooit over". Tot je leverancier wordt overgenomen, de prijs verdubbelt of het product een richting op gaat die niet meer bij je past. Vrijheid regel je als het rustig is, niet als het moet.

Kant-en-klaar vs. maatwerk

Lock-in vermijden betekent niet dat je alles zelf moet bouwen of hosten. Vaak is een kant-en-klare SaaS-tool gewoon de slimste keuze, mits de export goed is en het contract redelijk. De afweging op een rij:

De eerlijke conclusie is dat de meeste bedrijven een mix draaien, en dat is prima. Een tientje-per-maand-tool voor iets randgevoeligs met een nette CSV-export is geen probleem. Vast zitten wordt pas gevaarlijk bij je kernsystemen: je boekhouding, je klantdata, de software waar je bedrijf op draait. Of je zo'n onderdeel beter kunt kopen of laten bouwen is een afweging per bedrijfsonderdeel, geen geloofskwestie, en lock-in hoort in die afweging een expliciete factor te zijn, niet iets waar je pas achter komt als je weg wilt.

De vraag die alles simpel maakt

Vendor lock-in is geen technisch detail maar een machtsvraag: wie kan er weg, en wie zit vast? Je hoeft niet alles zelf te bouwen of zelf te hosten om die vraag in je voordeel te beantwoorden. Je moet alleen, bij elk systeem dat je binnenhaalt, één ding zeker weten: als de relatie met deze leverancier morgen eindigt, kan ik dan gewoon door? Kan ik mijn data eruit halen, in een formaat dat een ander leest, zonder afkoopsom? Wie dat vooraf regelt, kiest software omdat die goed is, niet omdat weggaan te veel pijn doet. En dat is precies het verschil tussen software die je vooruithelpt en software die je vasthoudt.