Wat als Azure stopt? Over dataportabiliteit en digitale afhankelijkheid

Afgelopen week las ik een artikel op Appletips.nl over Google dat in Europa stopt met de verkoop en ondersteuning van de Nest-thermostaten. Vanaf 25 oktober 2025 vervalt de app-bediening van oudere modellen en blijft alleen lokale bediening over. Voor consumenten betekent dat een kastje dat ooit ‘slim’ was, weer dom wordt. Het is een klein bericht in de stroom van tech-nieuws, maar het zegt veel over onze afhankelijkheid van leveranciers die op afstand de regels bepalen.

Voor particulieren is het vooral vervelend. Een duur apparaat verliest functies terwijl het technisch nog prima werkt. Voor organisaties is het een waarschuwing. Want wat gebeurt er als een grote leverancier – Microsoft, Google of Amazon – besluit om een product of regio niet meer te ondersteunen?

Van slimme thermostaat naar slimme cloud

Het Nest-voorbeeld lijkt ver weg van de wereld van enterprise-IT. Toch draait het om hetzelfde principe: een dienst die in de cloud leeft en afhankelijk is van servers, licenties en API’s buiten je controle. Zodra de leverancier de stekker eruit trekt, houdt de functionaliteit op.

Voor consumenten is dat een ongemak. Voor organisaties kan het operationeel of financieel ontwrichtend zijn. Denk aan het stopzetten van een API waarop processen zijn gebouwd, of het verdwijnen van een cloudservice waarop honderden workloads draaien.

Wat als de knop omgaat

Stel dat Azure morgen stopt met een specifieke dienst – bijvoorbeeld een Identity-provider, een Message Queue of een Storage-variant die als fundering dient voor je applicatielandschap. Niet omdat je iets verkeerd doet, maar omdat Microsoft kiest voor consolidatie, nieuwe licentiemodellen of simpelweg omdat een productlijn niet meer past in de strategie.

Dat klinkt theoretisch, maar voorbeelden zijn er genoeg. Google stopte eerder met Google Cloud IoT Core, waardoor organisaties wereldwijd binnen maanden moesten migreren. Amazon wijzigde API’s waardoor bestaande integraties faalden. Microsoft beëindigde de ondersteuning van oudere versies van Cognitive Services, wat ontwikkelteams dwong tot herbouw.

En vorige week nog lag een groot deel van AWS in delen van Europa urenlang plat door een storing in de netwerklaag. Niet door misbruik of cyberaanval, maar een menselijke fout in de infrastructuur. Honderden bedrijven konden tijdelijk geen transacties verwerken of data opslaan. Een storing die snel werd opgelost, maar genoeg om te laten zien hoe kwetsbaar digitale afhankelijkheid is.

Van datasoevereiniteit naar dataportabiliteit

In een eerdere blog (Data-soevereiniteit: risico of realiteit) schreef ik over de vraag waar onze data zich bevindt en wie er toegang toe heeft. Deze nieuwe ontwikkeling raakt aan een verwant thema: dataportabiliteit. Niet alleen waar je data staat, maar of je ze nog kunt meenemen als je leverancier verdwijnt of van koers verandert.

De Europese regelgeving biedt daar theoretisch bescherming voor. Artikel 20 van de GDPR (AVG) geeft burgers recht op dataportabiliteit: het recht om hun persoonsgegevens in een gestructureerd, machine-leesbaar formaat te ontvangen en door te geven aan een andere verwerkingsverantwoordelijke. Maar voor organisaties geldt die garantie zelden in de praktijk. Data zitten verspreid over SaaS-platforms, PaaS-diensten en propriëtaire formaten die niet zomaar overdraagbaar zijn.

De aankomende Data Act probeert dat te verbeteren. Die wet verplicht leveranciers om data-toegang en overdraagbaarheid beter te faciliteren, ook tussen cloudaanbieders. In theorie zou dat moeten leiden tot minder lock-in en meer keuzemogelijkheden. Maar de uitvoerbaarheid blijft lastig zolang elk platform zijn eigen API’s, protocollen en prijsmodellen hanteert.

De schijn van keuze

Veel organisaties geloven dat ze keuzevrijheid hebben zolang ze kunnen overstappen. In werkelijkheid is die overstap vaak economisch of technisch onhaalbaar. Migraties zijn duur, complex en risicovol. Applicaties zijn ontworpen rond specifieke services, authenticatie-mechanismen en security-modellen. Een databasemigratie van Azure SQL naar AWS RDS lijkt op papier mogelijk, maar in de praktijk betekent het herbouw van koppelingen, hercertificering en nieuwe beveiligingsinstellingen.

Zo ontstaat een subtiele vorm van lock-in. Niet door expliciete beperkingen, maar door de afhankelijkheid van de manier waarop een platform werkt. Zodra een leverancier voorwaarden wijzigt of toegang beperkt, blijft er weinig manoeuvreerruimte over.

De prijs van gemak

De kracht van cloudplatforms zit in gemak. Alles werkt samen, de integratie is naadloos, en updates verlopen automatisch. Maar dat gemak heeft een prijs: verlies van controle.

Bij veel SaaS-diensten bepaalt de leverancier hoe lang data worden bewaard, in welk formaat ze beschikbaar zijn en wat er gebeurt bij beëindiging van een contract. Vaak is er wel een exportfunctie, maar zelden volledig of toekomstbestendig. Data zijn technisch overdraagbaar, maar praktisch niet herbruikbaar zonder de originele context.

De juridische illusie

Een veelgehoord argument is dat contracten en SLA’s voldoende bescherming bieden. In de praktijk dekken die vooral beschikbaarheid en support, niet het scenario waarin een leverancier een dienst beëindigt of zijn strategische focus wijzigt. Zelfs met juridisch afdwingbare afspraken blijft er een machtsverschil. Grote aanbieders kunnen voorwaarden eenzijdig aanpassen of diensten herstructureren. Organisaties worden dan voor de keuze gesteld: meegaan of afscheid nemen. En afscheid nemen betekent migreren, herontwerpen en hercertificeren.

Architectuur als vangnet

De enige structurele manier om risico’s te beperken, ligt in de architectuur zelf. Digitale autonomie begint bij bewuste ontwerpkeuzes. Een robuuste architectuur houdt rekening met exit-strategieën. Dat betekent dat je bij de start van een project nadenkt over vragen als: hoe kom ik van deze dienst af als de leverancier stopt, in welk formaat wil ik mijn data opslaan, en hoe zorg ik dat ik afhankelijkheden zichtbaar hou?

Het antwoord hoeft niet altijd technisch te zijn. Soms volstaat een organisatorische maatregel, zoals het contractueel vastleggen van exportrechten of het periodiek testen van data-extracties. Belangrijk is dat architecten en inkopers samenwerken. Te vaak wordt cloudkeuze nog gezien als een kwestie van features en prijs, terwijl de strategische impact groter is: vendor lock-in, compliance, continuïteit.

De waarde van open standaarden

Een deel van de oplossing ligt in standaardisatie. Open API’s, uitwisselbare formaten en federatieve identiteitsmodellen maken overstappen eenvoudiger. Toch kiest de markt vaak voor het tegenovergestelde: propriëtaire uitbreidingen die klanten binden. Elke extra afhankelijkheid vergroot de drempel om te bewegen. En elke integratie zonder standaard verhoogt de kans dat data ooit vastzitten in een doodlopend ecosysteem.

Governance en bewustwording

Naast techniek is governance cruciaal. Organisaties moeten beleid ontwikkelen dat dataportabiliteit en leverancier-afhankelijkheid periodiek beoordeelt. Niet pas bij contractverlenging, maar als vast onderdeel van risicomanagement. Dat vraagt om samenwerking tussen IT, juridische afdelingen en inkoop. Architecten kunnen de risico’s zichtbaar maken, maar bestuurders moeten bereid zijn de gevolgen te accepteren of maatregelen te treffen.

Van reactief naar proactief

De AWS-storing van afgelopen week laat zien hoe snel een incident gevolgen heeft voor honderden organisaties tegelijk. De onderliggende oorzaak werd snel verholpen, maar het toont hoe weinig controle klanten hebben over hun digitale fundament. Proactief risicomanagement betekent niet dat je alles zelf moet hosten. Het betekent dat je bewust kiest wat je uitbesteedt, en dat je voorbereid bent op verandering.

Exitstrategieën in de praktijk

Een praktische maatregel is het periodiek testen van exitprocedures. Kun je je data exporteren binnen 24 uur? Kun je de belangrijkste functionaliteiten overzetten naar een ander platform? Weinig organisaties weten dat met zekerheid. Net zoals je een calamiteitenoefening houdt voor fysieke gebouwen, zou je een digitale exit-oefening moeten houden. Niet om direct te migreren, maar om te weten hoe complex het zou zijn.

Reflectie: digitale autonomie als continu proces

De vraag is niet of een leverancier ooit stopt, maar wanneer. Elk platform evolueert, herstructureert of verdwijnt uiteindelijk. De enige constante is verandering. Digitale autonomie is geen eindpunt, maar een houding. Het vraagt om voortdurende alertheid op waar je data leven, wie de sleutels heeft, en hoe je eruit kunt als het nodig is.

De Nest-thermostaat is slechts een voorbode. Vandaag is het een consumentenproduct dat zijn functionaliteit verliest. Morgen kan het een bedrijfskritische dienst zijn waarop hele organisaties vertrouwen. Bewust omgaan met dataportabiliteit en afhankelijkheid is geen luxe, maar een randvoorwaarde voor continuïteit.

Of, zoals ik eerder schreef: digitale autonomie begint bij bewuste keuzes in de architectuur.