Wat is vendor lock-in en hoe vermijd je het?

Prijsverhogingen die je alleen maar kan slikken. Een licentiemodel dat plots verandert. Een migratieofferte waar niemand aan durft te beginnen. Achter elk van die situaties zit hetzelfde mechanisme: vendor lock-in. Wie het begrijpt, kan het vermijden — en wie het al heeft, kan het stap voor stap afbouwen.

Wat betekent vendor lock-in?

Vendor lock-in betekent dat een organisatie zo afhankelijk is geworden van één leverancier dat overstappen naar een alternatief praktisch of financieel niet meer haalbaar is. Niet omdat de leverancier de beste keuze blijft, maar omdat de overstapkosten — in geld, tijd en risico — te hoog zijn geworden.

Het fenomeen is ouder dan de cloud, maar de cloud heeft het versterkt. Waar je vroeger software kocht die op je eigen servers draaide, huur je vandaag een platform waarop je toepassingen, data en processen steeds dieper verweven raken.

Hoe ontstaat vendor lock-in in de cloud?

Lock-in ontstaat zelden door één beslissing. Het groeit, project na project, langs vier wegen:

• Propriëtaire diensten. Elke hyperscaler biedt handige, platformspecifieke bouwblokken — serverless functies, queues, identity, AI-diensten. Elke keer dat een toepassing er rechtstreeks op leunt, wordt ze een stuk moeilijker verplaatsbaar.
• Data en dataformaten. Hoe meer data in platformspecifieke opslag en formaten zit, hoe zwaarder de migratie. Egress-kosten — betalen om je eigen data uit het platform te halen — maakten dat jarenlang ook letterlijk duur.
• Contracten en commitments. Meerjarige afnameverplichtingen en gebundelde kortingen belonen wie blijft en straffen wie vertrekt.
• Kennis en processen. Teams certificeren zich op één ecosysteem, tooling en monitoring groeien eromheen. Ook dat is lock-in, alleen zie je die niet op een factuur staan.

Wat kost lock-in je echt?

De kost van lock-in is vooral zichtbaar in wat je niet meer kan. Je onderhandelingspositie verdwijnt: bij een prijsverhoging of een gewijzigd licentiemodel is "dan vertrekken we" geen geloofwaardig antwoord meer. Kostenoptimalisatie stopt bij wat het platform toelaat. En elke nieuwe integratie met het platform maakt de uitgang weer een stukje smaller.

Omgekeerd geldt hetzelfde: wie wél kan bewegen, plukt daar direct de vruchten van. In migratietrajecten van hyperscalers naar Europese cloudomgevingen zagen we infrastructuurkosten geregeld sterk dalen — in sommige gevallen tot een factor tien — precies omdat de toepassingen verplaatsbaar genoeg waren om het alternatief ernstig te nemen.

Is vendor lock-in altijd slecht?

Nee — en dat is een belangrijke nuance. Een platformspecifieke dienst gebruiken kan een prima keuze zijn: je wint snelheid, je bespaart bouwwerk en sommige diensten zijn gewoon uitstekend. Het probleem is niet de afhankelijkheid zelf, maar de onbewuste afhankelijkheid: lock-in die niemand ooit als beslissing heeft genomen, en die pas zichtbaar wordt op het moment dat je wil bewegen.

De juiste vraag is dus niet "hoe vermijden we elke afhankelijkheid?", maar: weten we per toepassing welke afhankelijkheden we hebben, en zijn die het waard?

Zo vermijd je onnodige lock-in

Een werkbare aanpak, gegroeid uit onze eigen projecten:

• Bouw cloud-onafhankelijk waar het weinig kost. Containers, open standaarden en infrastructure-as-code houden toepassingen verplaatsbaar zonder dat je er extra voor hoeft te bouwen.
• Isoleer platformspecifieke diensten. Als je een propriëtaire dienst gebruikt, zet er dan een eigen interface voor. Dan blijft de afhankelijkheid één bouwblok groot, niet één applicatie groot.
• Test je data-portabiliteit vooraf. Weet in welk formaat je data eruit kan en wat dat kost — vóór je het nodig hebt.
• Leg een exit-strategie vast voor kritieke systemen. Niet als vertrekplan, maar als onderhandelingspositie en als NIS2-huiswerk: aantoonbare controle over leveranciers hoort bij NIS2- en ISO 27001-readiness.
• Overweeg Europese alternatieven per workload. Niet elke toepassing heeft het volledige hyperscaler-ecosysteem nodig. Voor veel workloads is een Europese, soevereine cloudomgeving eenvoudiger, goedkoper en beter controleerbaar.

De wet helpt voortaan mee

Sinds september 2025 staat de wetgever aan de kant van wie wil kunnen bewegen. De EU Data Act verplicht cloudproviders om overstappen contractueel mogelijk te maken, beperkt de opzegtermijn tot twee maanden en bouwt switchingkosten volledig af tegen januari 2027.

Maar de wet lost alleen het contractuele deel op. De technische kant — hoe verweven je toepassingen met één platform zijn — blijft je eigen verantwoordelijkheid. Vendor lock-in vermijd je niet in een contract; je vermijdt het in je architectuur.