Vendor lock-in bij maatwerksoftware betekent dat je niet meer zonder grote kosten of risico van leverancier kunt wisselen, omdat de code, de kennis of de omgeving feitelijk bij die leverancier ligt. Je voorkomt het vóór de eerste regel code: leg vast wat van jou is en zorg dat alles vanaf dag één in jouw eigen accounts staat.
Hieronder lees je hoe lock-in eruitziet, wat in het contract en de werkwijze hoort, welke vangnetten werken, aan welke signalen je merkt dat je al vastzit en hoe je overstapt als het zover is.
Hoe vendor lock-in eruitziet bij maatwerksoftware
Bij lock-in denken de meeste mensen aan een cloudprovider. Bij maatwerk zit het vaker in de afspraken en gewoontes rond de code. Een klantportaal kan keurig gebouwd zijn en toch niet te verplaatsen, omdat niemand buiten de leverancier weet hoe je het bouwt en uitrolt.
| Soort lock-in | Hoe het eruitziet | Voorbeeld |
|---|---|---|
| Juridisch | De leverancier houdt de rechten, jij krijgt een beperkt gebruiksrecht | Een ander bureau mag je ERP-koppeling niet aanpassen |
| Technisch | De applicatie draait op een eigen framework van de leverancier | Je planningsapp leunt op een intern basispakket zonder broncode |
| Kennis | Geen documentatie, de kennis zit in een paar hoofden | Niemand anders weet hoe de webshop prijzen berekent |
| Operationeel | Repository, cloud, domein en app-store-account staan op hun naam | Geen update van de field-service-app zonder hun account |
| Data | Data alleen via de leverancier of in hun eigen formaat | Een export uit het klantportaal kost een offerte en drie weken |
Operationele lock-in is vaak het hardnekkigst. Een contract kun je heronderhandelen, een domeinnaam op naam van een leverancier met wie je ruzie hebt niet. Bouw je op een low-code-platform of een eigen platform van de leverancier, dan hangt je applicatie ook aan de runtime en licentie van dat platform. Wanneer dat een goede ruil is, lees je in low code vs maatwerk.
Wat je in het contract vastlegt voordat er code is
Eigendom of licentie op de broncode
De Auteurswet noemt computerprogramma's en het voorbereidend materiaal als beschermde werken (artikel 10). Bij werk in loondienst geldt de werkgever als maker (artikel 7). Bouwt een leverancier je software met eigen ontwikkelaars, dan is de leverancier dus de maker, niet jij. Overdracht van het auteursrecht vraagt een schriftelijke overeenkomst en gebeurt bij een daartoe bestemde akte (artikel 2 lid 3).
Kies je voor een licentie in plaats van overdracht, zorg dan dat die eeuwigdurend is, overdraagbaar bij verkoop van je bedrijf, de broncode omvat en je toestaat de code door een andere partij of je eigen team te laten aanpassen. Wil de leverancier eigen bibliotheken niet overdragen omdat hij ze in meer projecten gebruikt, dan is zo'n licentie voor die onderdelen een redelijke oplossing.
Algemene voorwaarden
Ruim 3.000 IT-bedrijven gebruiken volgens NLdigital de NLdigital Voorwaarden. Die gelden alleen voor zover jullie niets anders schriftelijk hebben afgesproken (artikel 1.2 van de versie 2025). Voor de overgang naar een andere leverancier of naar jou spant de leverancier zich in om mee te werken aan exitwerkzaamheden, tegen zijn gebruikelijke tarieven (artikel 8.5). Dataconversie doet hij alleen als dat uitdrukkelijk schriftelijk is afgesproken (artikel 8.6). Wil je meer, zet het dan in de overeenkomst.
Licenties van derden en exitafspraken
Vraag bij elke oplevering een lijst van alle componenten van derden, zoals bibliotheken, een betaalde pdf-module of een kaartdienst, met hun licentie en de naam waarop ze staan. Een licentie op naam van de leverancier verhuist niet vanzelf mee. Een eigen framework van de leverancier hoort ook op die lijst, met de afspraak wat je ermee mag als de samenwerking stopt. Leg vast hoeveel uur kennisoverdracht je krijgt bij een vertrek en tegen welk tarief. Neem documentatie, scripts en tests op in je acceptatiecriteria, zodat 'af' ook 'overdraagbaar' betekent.
De werkwijze vanaf dag één: alles op jouw naam
Veel lock-in ontstaat in de eerste weken, als iemand 'voorlopig' een repository of cloudaccount aanmaakt onder een account dat hij al had. Spreek af dat jij eigenaar bent van de accounts en dat de leverancier toegang krijgt.
| Onderdeel | Wat je afspreekt | Hoe je het controleert |
|---|---|---|
| Coderepository | In de organisatie van jouw bedrijf op GitHub, GitLab of Azure DevOps | Jij bent beheerder en kunt zelf een kopie maken |
| Build- en deployscripts | De pijplijn staat als code in de repository, zonder handwerk | Iemand buiten het team rolt een testversie uit met alleen de README |
| Testsuite | Geautomatiseerde tests draaien bij elke wijziging | Je ziet de resultaten in de pijplijn |
| Documentatie | Architectuur, installatie, koppelingen en een log van architectuurbeslissingen | Staat in de repository en verandert mee met de code |
| Hosting en cloud | Account en facturatie op naam van jouw bedrijf | Jij kunt rechten intrekken |
| Domeinen en app stores | Registraties en ontwikkelaarsaccounts op jouw naam | Je logt zelf in |
| Diensten van derden | E-mail, betalingen en monitoring op jouw naam | De API-sleutels staan in jouw kluis |
Voor architectuurbeslissingen werkt een kort document per keuze, zoals Michael Nygard het beschreef: context, besluit, status en gevolgen. Een nieuw team leest dan waarom de ERP-koppeling via een wachtrij loopt. Wat de software moet doen, staat in het functioneel ontwerp.
Controleer het elk halfjaar: laat iemand buiten het team de applicatie vanuit de repository bouwen en op een testomgeving zetten. Lukt dat niet zonder de leverancier te bellen, dan weet je wat er ontbreekt.
Vangnetten: data-export, de Data Act en escrow
Data in open formaten
Spreek af dat je op elk moment een volledige export krijgt in open formaten: een dump van een gangbare database, of CSV en JSON met een beschrijving van de velden, plus de bestanden en documenten. Een gedocumenteerde API helpt bij een latere migratie. Zet de export af en toe terug in een lege omgeving. Een export die nooit is teruggezet, is een belofte.
De Data Act voor clouddiensten
De Dataverordening (Data Act) geldt sinds 12 september 2025 en schrapt vanaf 12 januari 2027 alle overstapkosten bij dataverwerkingsdiensten, ook die voor uitgaand dataverkeer, aldus de Europese Commissie. Volgens artikel 25 moet het contract met zo'n aanbieder onder meer een opzegtermijn van hooguit twee maanden noemen om een overstap te starten, een overgangsperiode van in principe maximaal 30 kalenderdagen en daarna minstens 30 kalenderdagen om je data op te halen. Voor een dienst waarvan het merendeel van de hoofdfuncties op maat voor één klant is gebouwd, gelden een paar verplichtingen niet, waaronder die over overstapkosten (artikel 31). Afspraken over het auteursrecht op je broncode maak je in je eigen contract.
Escrow
Bij escrow legt de leverancier de broncode in bewaring bij een onafhankelijke partij, en krijg je die bij een afgesproken gebeurtenis, zoals een faillissement. Dat helpt als de leverancier de code houdt en je voor een bedrijfskritisch systeem van hem afhankelijk bent. Het helpt weinig als:
- niemand het depot na elke release bijwerkt;
- build-scripts en documentatie ontbreken, zodat niemand de code kan bouwen;
- je probleem een trage of dure leverancier is, want dat valt meestal buiten de afgesproken gebeurtenissen;
- de code al in je eigen repository staat.
Kies je voor escrow, laat dan periodiek door een derde controleren of de gedeponeerde code te bouwen is.
Signalen dat je al vastzit
- Alleen de leverancier kan een release uitrollen. De pijplijn draait op hun servers, of er is er geen.
- Je hebt geen eigen kopie van de code. Of een zipbestand van twee jaar geleden.
- Elke vraag over de werking wordt een offerte. Ook de vraag hoe de webshop prijzen berekent.
- De cloudfactuur loopt via de leverancier. Je weet niet wat er draait en wat het los kost.
- Twee ontwikkelaars weten alles. Is er één met vakantie, dan ligt de planning stil.
- Een data-export kost weken. Of hij komt alleen in het formaat van de leverancier.
- Niemand kan inschatten wat een overdracht kost. Dus heeft niemand ooit een alternatief laten prijzen.
Herken je er twee of meer, zet dan de eerste twee stappen van het exitplan hieronder, ook als je niet wilt vertrekken. Met eigen toegang tot code, accounts en data sta je ook sterker in de volgende prijsonderhandeling.
Een exitplan in zes stappen
1. Breng in kaart wat je hebt
Noteer per onderdeel uit de tabel hierboven op wiens naam het staat en wie toegang heeft. Leg je contract ernaast: opzegtermijn, exitafspraken, intellectueel eigendom en licenties van derden.
2. Haal toegang binnen voordat je opzegt
Zet repository, cloudaccounts en domeinen op jouw naam terwijl de samenwerking nog normaal loopt. Dat is gewoon goed beheer. Na een opzegging wordt elk verzoek een onderhandeling.
3. Laat een buitenstaander de applicatie bouwen
Laat een nieuwe partij of je eigen ontwikkelaar de applicatie vanuit de repository bouwen, testen en beoordelen. De lijst met hiaten wordt je agenda voor de overdracht. Kies je een nieuwe leverancier, lees dan ook hoe je een softwarebedrijf kiest.
4. Plan een overdracht met overlap
Zorg voor een periode waarin oude en nieuwe partij allebei aan boord zijn, met opgenomen kennissessies per onderdeel en een overdracht van openstaande issues en bekende fouten. Onder de NLdigital Voorwaarden mag de leverancier voor exitwerk zijn gebruikelijke tarieven rekenen, dus reken op kosten. Neem je de ontwikkeling in huis, laat je eigen ontwikkelaars dan al wijzigingen doen terwijl de oude leverancier meekijkt.
5. Verhuis data en hosting
Maak een volledige export, zet die terug in een testomgeving en vergelijk aantallen met productie. Pas daarna verhuis je de hosting.
6. Vervang stap voor stap wat niet mee kan
Mag je een framework van de vorige leverancier niet houden, vervang het dan in delen met de strangler fig-aanpak: nieuwe onderdelen naast het bestaande systeem, oude delen uit zodra de nieuwe het werk overnemen. Is de applicatie zo oud dat vervangen goedkoper is dan overnemen, lees dan over legacy systemen.
Vendor lock-in voorkomen met Isatis
Isatis bouwt bedrijfssoftware op maat, met teams in Nijmegen en Sarajevo. We doen dat al meer dan 30 jaar, met 30+ engineers en meer dan 100 projecten, en zijn gecertificeerd voor ISO 9001 en ISO 27001. Lees hoe we werken op onze pagina over maatwerksoftware laten ontwikkelen.
Wil je een nieuw project zo inrichten dat je later zelf of met een andere partij verder kunt, of wil je weten hoe vast je zit bij je huidige leverancier? Plan dan een gesprek. We zeggen het ook als overstappen meer kost dan het oplevert.
Veelgestelde vragen
Is de broncode van mij als ik de ontwikkeling betaal?
Niet vanzelf. Volgens de Auteurswet geldt bij werk in loondienst de werkgever als maker, dus bij een leverancier met eigen ontwikkelaars is dat de leverancier. Voor overdracht zijn een schriftelijke overeenkomst en een akte nodig. Een ruime licentie kan ook volstaan.
Is escrow genoeg tegen vendor lock-in?
Meestal niet. Escrow helpt vooral bij een faillissement, en alleen als de gedeponeerde code actueel en te bouwen is. Staat de code vanaf dag één in jouw eigen repository, dan heb je escrow zelden nodig.
Kan ik de ontwikkeling later in eigen huis nemen?
Ja, als code, pijplijn, tests en documentatie op orde zijn en in jouw accounts staan. Plan een overlapperiode met de leverancier. Kies bij de start gangbare talen en frameworks, dan vind je later makkelijker ontwikkelaars.
Geldt de Data Act ook voor mijn maatwerkapplicatie?
De overstapregels gelden voor aanbieders van dataverwerkingsdiensten, zoals clouddiensten. Voor diensten die grotendeels op maat voor één klant zijn gebouwd, gelden een paar verplichtingen niet, waaronder die over overstapkosten. Afspraken over je broncode maak je in je eigen contract.
Moet ik mijn leverancier vertellen dat ik een overstap voorbereid?
Niet bij elke stap. Accounts op je eigen naam zetten en een kopie van de code vragen is gewoon goed beheer. Lees wel eerst je opzegtermijn en kies daarna voor een open gesprek, want je hebt de oude leverancier nog nodig voor de kennisoverdracht.
