Exit-bepalingen in IT-contracten: sluit het contract én de exit

Bij het sluiten van een IT-contract denken partijen zelden aan de beëindiging ervan. De focus ligt op de scope, de prijs, de timing en de implementatieplannen. Plannen maken voor het einde van de samenwerking vooraleer ze begonnen is, voelt contra-intuïtief.  De exit-fase en de noodzakelijke transitie naar een opvolgende oplossing wordt vaak vergeten of beschouwd als iets dat later wel geregeld wordt. In de praktijk leidt dat regelmatig tot problemen: organisaties staan met lege handen wanneer een overstap zich opdringt, of worden gedwongen om langer met dezelfde leverancier verder te gaan dan gewenst (vendor lock-in).

Eén ding is nochtans zeker bij elke IT-samenwerking: ze eindigt ooit. Of het nu gaat om een opzegging, een contractbreuk, een faillissement of een overstap naar een nieuwe oplossing: de exit is onvermijdelijk. Wie de exit-regeling pas op het moment van beëindiging probeert te organiseren, vertrekt vanuit een zwakke positie: de relatie is vaak bekoeld, belangen lopen uiteen en de leverancier heeft weinig incentive om constructief mee te werken. Een goed doordachte exit-clausule is daarom geen luxe, maar een essentieel onderdeel van elk IT-contract.

De uitdagingen bij een IT-exit zijn talrijker dan op het eerste gezicht lijkt. Denk maar aan:

• Data en migratie: Waar bevinden de gegevens zich, in welk formaat zijn ze beschikbaar, en hoe krijgt de klant ze terug? Wie draagt de migratiekosten en hoe worden de rollen bij de migratie verdeeld?
• Kennis en documentatie: Architectuurbeschrijvingen, configuraties en specifieke know-how bevinden zich vaak uitsluitend bij de leverancier, en soms zelfs bij individuele sleutelfiguren. Het is daarom essentieel dat de klant deze informatie contractueel kan opvragen wanneer dat nodig is en dat hij toegang heeft tot de nodige expertise tijdens een transitieperiode, bij voorkeur via een vaste contactpersoon bij de leverancier.
• Broncodes: Bij maatwerkoplossingen is de beschikking over de broncode noodzakelijk voor de klant om autonoom aanpassingen te kunnen aanbrengen aan de software. Voor standaardsoftware is de broncode noodzakelijk om na een faillissement van de leverancier (licentiegever) gedurende een overgangsperiode verder te kunnen werken met de software en de nodige aanpassingen uit te voeren. Voor maatwerkoplossingen waarbij de intellectuele rechten overgaan op de klant/opdrachtgever, wordt de broncode gewoonlijk afgegeven als een deliverable. Voor standaardsoftware is dat niet het geval, maar is de broncode mogelijk op basis van een tripartite escrow-overeenkomst in bewaring gegeven bij een derde (source code escrow) die de broncode zal vrijgeven in geval van een faillissement. Dit kan een oplossing bieden voor on premises-software die de klant fysisch onder zijn controle heeft. Voor SaaS ligt dit anders. Zonder toegang tot de cloudomgeving is de broncode in de praktijk niet bruikbaar . Een SaaS-escrow gaat verder: het omvat de overname van de hosting-omgeving in de cloud met een overdracht van de account, met de configuraties, de management tools en de toegang tot de data. Zulke regeling kan mogelijk zijn wanneer de cloudomgeving single-tenant is, maar zal problematisch zijn in een multi-tenant omgeving waarbij ook andere ondernemingen en mogelijk zelfs concurrenten als klant verbonden zijn aan de cloudomgeving. In de praktijk zal men naar creatieve oplossingen moeten zoeken. Zulke oplossing is noodzakelijk wanneer de leverancier financieel fragiel is.
• Licenties en “background IP”: Wanneer een IT-oplossing afhankelijk is van licenties van derden, rijst de vraag of die licenties noodzakelijk blijven na de beëindiging van het contract. Is dat het geval, dan moet worden nagegaan of zij verder kunnen worden gebruikt en of overdracht mogelijk is naar de klant of een opvolgende leverancier. Daarnaast kan het ook belangrijk zijn dat de klant het recht heeft om zogenaamde “background IP” van de leverancier verder te gebruiken. Het gaat om software van de leverancier waarover de klant een duurzaam gebruiksrecht heeft verkregen, en waarop hij wijzigingsrechten moet hebben om bijvoorbeeld integratie met de software van de nieuwe leverancier mogelijk te maken. Zulke wijzigingsrechten moeten uitdrukkelijk overeengekomen worden bij het aangaan van de overeenkomst, aangezien zij verder gaan dan een louter gebruiksrecht.  
• Opzegtermijnen:  Voor complexe systemen, zoals een ERP, kan een realistische overstap één tot twee jaar in beslag nemen. De klant moet een alternatief selecteren, onderhandelen en vervolgens implementeren, vaak met aanzienlijke aanpassingen. De contractuele opzegtermijnen moeten daarom lang genoeg zijn om een werkbare transitie mogelijk te maken. Het kan aangewezen zijn om een contractuele optie te voorzien waarmee de klant de opzegtermijn kan verlengen indien nodig, bijvoorbeeld met 3 tot 6 maanden.  
• Transitiebegeleiding: De bestaande leverancier moet actief meewerken aan de overstap naar een opvolger. In de praktijk is dat echter niet vanzelfsprekend, zeker wanneer de relatie onder druk staat en een concurrent het systeem overneemt. Bovendien bestaat er vaak terughoudendheid om knowhow en intellectuele rechten te delen. Indien medewerking van de leverancier noodzakelijk is, moet dit uitdrukkelijk en concreet contractueel worden vastgelegd bij de aanvang van het project. Achteraf, en zeker na de beëindiging, is de onderhandelingspositie van de klant aanzienlijk zwakker.
• De financiële kant van de exit: Bij gebrek aan voorafgaande afspraken over de prijs van exitbegeleiding zal de leverancier zijn diensten doorgaans aanrekenen op basis van dagtarieven, vaak vanuit een sterke onderhandelingspositie. Wie dit vooraf contractueel vastlegt, vermijdt heel wat discussie achteraf.

Sinds de inwerkingtreding van de Europese Data Act (Verordening (EU) 2023/2854) op 12 september 2025 zijn cloudleveranciers  (waaronder SaaS-, PaaS- en IaaS-aanbieders) verplicht om klanten te ondersteunen bij een overstap naar een andere aanbieder.

Klanten kunnen het overstapproces initiëren met een opzegtermijn van maximaal twee maanden. Vervolgens moet de leverancier de overdracht van alle exporteerbare data en digitale activa onverwijld uitvoeren, en in elk geval binnen dertig dagen na afloop van die opzegtermijn. In de praktijk bedraagt de maximale overstapperiode dus ongeveer drie maanden. De data moeten worden aangeleverd in een gestructureerd, gangbaar en machineleesbaar formaat, of in overeenstemming met open interoperabiliteitsspecificaties en geharmoniseerde Europese normen. Leveranciers zijn bovendien verplicht om kosteloos open interfaces ter beschikking te stellen die gegevensoverdraagbaarheid en interoperabiliteit met een nieuwe aanbieder mogelijk maken. Zolang de data nog niet zijn overgedragen of gewist, moet de klant voldoende tijd krijgen om zijn gegevens op te halen of te exporteren.

Artikel 29 van de verordening verplicht cloudleveranciers bovendien om overstapkosten geleidelijk af te schaffen. Tot 12 januari 2027 mogen enkel kosten worden aangerekend die rechtstreeks verband houden met het overstapproces; daarna zijn overstapkosten volledig verboden (tenzij er sprake is van echte consultancy of uitgebreide migratiebijstand). Deze regels gelden ook voor bestaande contracten.

Voor financiële entiteiten is een exitstrategie geen optie, maar een wettelijke verplichting. Artikel 28, lid 8 van de Digital Operational Resilience Act (DORA), van toepassing sinds 17 januari 2025, verplicht financiële entiteiten om exitstrategieën uit te werken voor alle ICT-diensten die kritieke of belangrijke functies ondersteunen. Die strategieën moeten worden gedocumenteerd, periodiek worden getest en concrete transitieplannen bevatten. De financiële entiteit moet kunnen aantonen dat de beëindiging van een IT-contract geen verstoring veroorzaakt van de bedrijfsactiviteiten, geen schending van wettelijke verplichtingen meebrengt en geen negatieve impact heeft op de dienstverlening aan cliënten. Financiële entiteiten die hun IT-contracten hier nog niet op hebben afgestemd, lopen vandaag al een reëel compliance-risico.

Wanneer er weinig of niets contractueel is geregeld over de exit, kan het Belgisch recht een mogelijke bescherming bieden. Artikel IV.2/1 van het Wetboek van Economisch Recht verbiedt misbruik van economische afhankelijkheid. Daarvan is sprake wanneer een leverancier misbruik maakt van het feit dat de klant geen redelijk equivalent alternatief heeft, en eenzijdig voorwaarden oplegt (zoals buitensporige exitvergoedingen of een weigering om mee te werken) die onder normale marktomstandigheden niet aanvaardbaar zouden zijn.

Deze regeling is in werking getreden op 1 december 2020 als onderdeel van de B2B-wetgeving. De toepassingsdrempel ligt echter hoog: er moet sprake zijn van een positie van relatieve dominantie én van een misbruik dat de mededinging kan aantasten. Dit wettelijk vangnet ontslaat partijen dan ook niet van de noodzaak om exitclausules van bij het begin contractueel te regelen. Het kan hoogstens een remedie bieden wanneer die voorbereiding ontbreekt, geen alternatief ervoor.

Een doordachte exitregeling in een IT-contract bevat minstens de volgende elementen:

• Exitplan: opgesteld bij contractsluiting, niet bij de beëindiging, met een duidelijk stappenplan en verdeling van verantwoordelijkheden;
• Datateruggave en -verwijdering: afspraken over formaat, timing, migratieondersteuning, maximale bewaartermijnen bij de leverancier in lijn met de Data Act;
• Prijsafspraken voor transitiebegeleiding: vaste of geplafonneerde tarieven voor bijkomende dienstverlening tijdens de exitfase;
• Opzegtermijnen op maat: afgestemd op de realistische overstaptermijn, eventueel met een contractuele verlengingsoptie;
• Broncode-escrow of SaaS-escrow: afhankelijk van het type leveringsmodel;
• IP-clearing: afspraken over het verdere gebruik van background-IP van de leverancier, inclusief eventuele wijzigingsrechten;
• Medewerking van key personeel: verplichting voor de leverancier om specifieke medewerkers beschikbaar te stellen voor kennisoverdracht;
• Voor financiële entiteiten: een formeel exitplan conform artikel 28 DORA, met documentatie, testen en alternatieven.
• Conclusie

Een IT-contract zonder exitregeling kan prima werken zolang alles goed gaat, maar op het moment dat de klant de relatie wil of moet beëindigen staat hij met lege handen en moet hij onderhandelen vanuit een afhankelijke positie. Het is dus zeker van belang om bij elke contractsluiting stil te staan bij de aspecten die belangrijk kunnen zijn wanneer later een transitie naar een nieuwe leverancier nodig is.

Auteurs

Stefan Van Camp en Edwin Jacobs, Timelex