Overstappen naar een nieuwe ICT-partij: welke sleutels je opeist en in welke volgorde

De handtekening onder het contract met je nieuwe IT-partij is het makkelijke deel. Twee weken later stelt iemand de vraag die niemand kan beantwoorden: op wiens naam staat je Microsoft 365-omgeving eigenlijk, en wie kan daar volgende maand nog bij? Een leverancierswissel loopt zelden stuk op techniek. Hij loopt stuk op volgorde, want je zegt op voordat je hebt, en dan sta je buiten je eigen bedrijf.

Dit is de normale, geplande variant. Geen ruzie, geen kort geding, gewoon een contract dat afloopt en een nieuwe partij die het overneemt. De vraag is dan niet hoe je iemand dwingt, maar wat je precies opeist, in welke volgorde je het overzet, en hoe je voorkomt dat je mail, je website of je inloggen een dag plat gaat.

Een sleutel is hier elke vorm van zeggenschap waarmee iemand jouw bedrijf kan laten draaien of stilzetten: het houderschap van je domeinnaam, het globale beheerdersaccount van je tenant, het abonnement waarop je licenties staan, de DNS-zone waar je mail op leunt, het account waaronder je back-ups draaien en de beheerinlog van je firewall. Een sleutel hoort bij een systeem, niet bij een persoon.

Waarom een lijst met wachtwoorden je niet redt

De reflex bij een overstap is een mail met de vraag: stuur je alle wachtwoorden even door? Dat is de verkeerde vraag, om twee redenen.

De eerste is dat je met een wachtwoordenlijst niets in handen hebt. Een wachtwoord dat je krijgt, kent de ander ook nog. Wat je wilt is het uitgiftepunt: de plek waar dat wachtwoord vandaan komt en waar iemand een nieuwe kan aanmaken.

De tweede reden is dat de belangrijkste toegang helemaal niet in een kluis staat. Beheerders van een Microsoft-partner werken via rollen die zijn toegekend aan beveiligingsgroepen in de tenant van die partner, waardoor hun technici geen gebruikersaccount in jouw omgeving nodig hebben om jouw diensten te beheren. Je kunt je hele gebruikerslijst doorlopen zonder ze ooit tegen te komen. Ze staan op de pagina Delegated administration in het Entra-beheercentrum, en nergens anders.

Die relatie verdwijnt ook niet vanzelf. Het oudere model, Delegated Admin Permission, blijft bestaan tot jij of de partner hem intrekt. Het nieuwere model heeft wel een einddatum, maar staat die relatie op automatisch verlengen, dan rolt hij zes maanden door zonder dat de klant opnieuw toestemming hoeft te geven (Partner Center, auto-extend van zes maanden, gecontroleerd augustus 2026). Je oude partij kan dus maanden na de overstap nog steeds beheerder van jouw omgeving zijn, zonder dat iemand iets fout deed.

Inventariseer daarom per uitgiftekanaal, niet per persoon. Niet "wie heeft er nog een inlog", maar: welk systeem hangt aan welke sleutel, en wie kan die sleutel afgeven.

Wat je nodig hebt voordat je iets opeist

Deze klus kost geen nieuwe software. Hij kost je toegang tot je eigen contracten, een paar uur om de nulmeting vast te leggen, en één beslissing die de meeste bedrijven overslaan: wie binnen jouw bedrijf de overdracht bezit en aftekent. Zonder die naam blijft elke sleutel ergens tussen twee leveranciers hangen.

Dit ligt klaar voordat je de eerste mail stuurt:

Twee dingen van die lijst worden bijna altijd overgeslagen. De eerste is die eigen globale beheerder. Microsoft adviseert twee of meer noodaccounts, cloud-only op het *.onmicrosoft.com-domein, uitgezonderd van beleid dat aanmelden blokkeert, en minstens elke 90 dagen getest of ze nog werken. Dat klinkt als beveiligingsbeleid. Het is hier gewoon je verzekering tegen buitengesloten raken op het slechtst denkbare moment.

De tweede is het beheerderscontact. Bij veel MKB'ers staat er een adres van de leverancier bij het tenant-account, bij de registrar en bij de hostingpartij. Elke bevestigingsmail van een verhuizing, elke wachtwoordreset en elke factuur gaat daarheen. Zet die adressen als eerste om naar een postbus die jij beheert, want anders eis je sleutels op waarvan de bevestiging bij de tegenpartij in de inbox valt.

De acht kanalen waar je bedrijf aan hangt

Elk bedrijf heeft dezelfde acht kanalen, ongeacht de branche. Loop ze in deze volgorde na en noteer per kanaal wie de sleutel nu heeft, waar je dat kunt zien, en hoe lang het duurt om hem over te zetten.

Dit zijn ze, met de controle die je vandaag zelf kunt doen:

• Domeinnaam en DNS. De sleutel is het houderschap plus de toegang tot de zone. Check je houder via Whois of RDAP en je nameservers met dig +short NS jouwbedrijf.nl.
• Tenant en globaal beheer. De sleutel is het globale beheerdersaccount en de beheerrelatie met de partner. Zichtbaar op Delegated administration in Entra en op Partner relationships in het Microsoft 365-beheercentrum.
• Licenties en abonnementen. De sleutel is de partij die de abonnementen bij Microsoft of Google afneemt. Kijk op de factuur wie de leverancier is en in het beheercentrum of je abonnementen zelf kunt opzeggen.
• Mailrouting en e-mailauthenticatie. De sleutel is de DNS-zone waar MX, SPF, DKIM en DMARC in staan. Controleer met dig +short MX jouwbedrijf.nl en dig +short TXT _dmarc.jouwbedrijf.nl.
• Hosting, website en certificaten. De sleutel is het hostingaccount, de code en de uitgifteroute van je certificaat. Vraag wie de hostingfactuur betaalt en waar de broncode staat.
• Back-ups en herstelsleutels. De sleutel is het back-upaccount plus de encryptie- en herstelsleutels. Zoek de BitLocker-herstelsleutels op bij je apparaten in Entra ID en vraag waar de sleutel van de back-upset ligt.
• Netwerk en apparatuur. De sleutel is de beheerinlog van firewall, switches en accesspoints, plus het supportcontract op naam. Controleer op wiens account het apparaat geregistreerd staat.
• Vakapplicaties, SaaS en koppelingen. De sleutel is het eigenaarschap van elk abonnement plus de API-tokens en OAuth-toestemmingen die erop draaien, want die werken op eigen tokens, los van het wachtwoord en de tweede factor van de gebruiker die ze ooit goedkeurde.

De doorlooptijden verschillen sterk, en dat bepaalt je planning meer dan wat dan ook:

Het draaiboek: tien stappen in deze volgorde

De volgorde is het hele punt. Alles wat je binnenhaalt, haal je binnen terwijl de oude partij nog toegang heeft en nog meewerkt. Pas als het laatste kanaal van jou is, ga je dichtzetten.

1. Leg de nulmeting vast voordat er iets verandert. Maak één document met de datum erop en zet daarin: je nameservers, je MX-records, je SPF-regel, je DMARC-beleid, je DKIM-selectors, de houder uit Whois of RDAP, een export van je licentielijst en een screenshot van je partnerrelaties. Vijf regels op de commandline geven je het grootste deel:

dig +short NS jouwbedrijf.nl
dig +short MX jouwbedrijf.nl
dig +short TXT jouwbedrijf.nl
dig +short TXT _dmarc.jouwbedrijf.nl
dig +short CNAME selector1._domainkey.jouwbedrijf.nl

Dit is je terugrolpunt. Gaat er tijdens de wissel iets stuk, dan is de vraag altijd: wat stond hier gisteren?

2. Zet je eigen globale beheerder erin en bewijs dat hij werkt. Log in met een account dat van jouw bedrijf is, ken de rol Global Administrator toe, en test hem in een privévenster met MFA erop. Maak daarnaast de twee noodaccounts aan. Doe dit voordat je een enkele opzegging verstuurt, want elke stap hierna leunt erop.

3. Vraag één document op, geen wachtwoordlijst. Stuur de vertrekkende partij een verzoek per kanaal: op wiens naam staat het, welk account is het, welk e-mailadres hangt eraan, wanneer verloopt het, en welke partijen zitten er nog onder als subleverancier. Het NCSC noemt dit een exitplan en adviseert het al aan het begin van het contract op te stellen en jaarlijks bij te werken, met de verantwoordelijkheden per partij erin. Heb je dat niet, dan maak je het nu alsnog, en je hebt een prima onderhandelingspositie: de laatste factuur staat nog open. Gaat je leverancier tijdens dit traject failliet, dan verandert de route volledig: je data ligt dan bij een curator, en dan begin je met het Centraal Insolventieregister en een sommatie aan de curator in plaats van met een overdrachtsdocument.

4. Haal het houderschap van je domeinnaam binnen. Staat jouw bedrijfsnaam als houder geregistreerd, dan hoef je alleen het verhuistoken te vragen; je huidige registrar is verplicht dat binnen vijf dagen af te geven (SIDN-verhuisprocedure, gecontroleerd augustus 2026). Zet de zone bij je nieuwe registrar record voor record klaar vóór de verhuizing landt, want een nieuwe registrar zet standaard zijn eigen DNS-instellingen aan en dan valt je mail weg. Staat het bureau zelf als houder geregistreerd, dan is dat een aparte klus met een eigen route langs sommatie, de geschillenregeling voor .nl-domeinnamen of een kort geding.

5. Zet de licenties over, en begin daar zes weken van tevoren mee. Dit is de stap die het vaakst te laat begint, omdat bijna niemand weet hoe hij werkt. Bij Microsoft kun je als klant een overdracht niet zelf starten: je accepteert eerst de relatieaanvraag van je nieuwe partner, waarna die het overdrachtsverzoek stuurt en je oude partner het moet goedkeuren, met een verzoek dat na 30 dagen verloopt en een uitvoering die tot 72 uur duurt (Partner Center-procedure, gecontroleerd augustus 2026). Bij Google ligt de knop wel bij jou: je superbeheerder genereert de machtiging onder Account, Reseller management, waarbij geldt dat de nieuwe reseller daarna toegang heeft tot je Admin console tenzij je die toegang weghaalt (menupad en toegangsregel gecontroleerd augustus 2026).

Controleer hier ook iets fundamentelers: staat je omgeving wel in je eigen tenant? Zit je mail in een gedeelde omgeving van je leverancier, dan is dit geen overdracht maar een migratie, met een heel ander tijdpad en een echte kans op dataverlies.

6. Neem DNS en mailrouting over, in twee bewegingen. Verlaag eerst de TTL van je belangrijkste records naar 300 seconden en wacht een dag. Zet daarna pas de nameservers om. Controleer meteen erna je MX, SPF, DKIM en DMARC met dezelfde commando's uit stap 1, en vergelijk regel voor regel met je nulmeting. De DKIM-records van Microsoft 365 zijn twee CNAME's, selector1._domainkey en selector2._domainkey, en hun waarde is tenant-specifiek: er zit het voorvoegsel van jouw eigen onmicrosoft.com-domein in. Haal de exacte waarden op met Get-DkimSigningConfig -Identity jouwbedrijf.nl | Format-List Selector1CNAME,Selector2CNAME en tik ze letterlijk over. Blijf je in dezelfde tenant, dan blijven ze werken zolang ze mee verhuizen naar de nieuwe zone. Scherp je DMARC-beleid niet aan tijdens de verhuizing, want dan weet je bij de eerste afgekeurde mail niet of het aan je beleid ligt of aan een record dat je vergat over te tikken.

7. Neem hosting, site en certificaten over. Vraag een volledige back-up van het hostingaccount inclusief databases en mailboxen, plus de broncode, de deploy-route en de omgevingsvariabelen. Vraag niet om de private sleutel van je TLS-certificaat. Die vraag je opnieuw uit, want certificaten worden juist steeds kortlevender: het CA/Browser Forum besloot in april 2025 de maximale geldigheid van 398 dagen stapsgewijs terug te brengen naar 47 dagen tussen maart 2026 en maart 2029. Wat je nodig hebt is dus niet het oude bestand maar de uitgifteroute: wie de vernieuwing draait, op welk account, en of je CAA-record dat toelaat.

8. Neem de back-ups over en doe één echte hersteltest. Zoek uit op wiens account het back-upplatform draait, waar de encryptiesleutel ligt en wie de herstelsleutels van je laptops heeft. Ligt die encryptiesleutel in de kluis van je leverancier, dan heb je twee eerlijke routes en geen derde. Route één: je krijgt de sleutel én de historische back-upset mee, en zet allebei onder een account op naam van je eigen bedrijf. Route twee: je accepteert dat je historie bij de oude partij achterblijft, start op je eigen account een nieuwe retentieketen vanaf de overdrachtsdatum, en legt contractueel vast dat de oude set daar nog een afgesproken aantal maanden terugzetbaar blijft, met een contactpersoon en een hersteltermijn erbij. Route twee is vaker realistisch dan bedrijven denken, want een export van jaren aan versleutelde back-ups is echt werk waar iemand voor moet betalen. Wat je niet moet doen is de vraag open laten: dan denk je zeven jaar historie te hebben en heb je zes weken. Het NCSC vat het kort samen: maak duidelijk wie eigenaar is van de data en vergeet daarbij je back-ups niet. Zet daarna één bestand en één postbus echt terug, uit de back-up die jij beheert. Een back-up die je nooit hebt teruggezet is een aanname, geen sleutel.

9. Zet netwerk en apparatuur op jouw naam. Haal de beheerinlogs en een configuratie-export van je firewall, switches en accesspoints op, en verhuis het supportcontract. Bij Fortinet gaat dat via een token dat de huidige eigenaar aanmaakt en dat vijf dagen geldig is of tot het handmatig wordt uitgezet (FortiCloud Asset Management, gecontroleerd augustus 2026). Regel in dezelfde week je internetcontract, je vaste IP-adressen en de wifi-sleutel van kantoor, want die staan verrassend vaak op naam van je beheerpartij.

10. Teken de overdracht af, en zet dan pas dicht. Hier komt alles samen in één document: het overdrachtsdocument. Het is geen mail met "bij dezen overgedragen", maar een tabel met acht regels, die je pas ondertekent als elke regel gevuld is. Dezelfde acht kanalen, in dezelfde volgorde, met per regel wie het gaf en wie het controleerde. De kolom die het verschil maakt is de laatste: zonder bewijs is een afgevinkte regel een belofte.

Onder die tabel horen vier afspraken die niet per kanaal lopen maar over de hele overdracht, en die je in dezelfde ondertekening meeneemt:

1. De termijn waarop de oude partij je gegevens verwijdert. Noem een datum, geen "na afloop". Dat mag je vragen: na afloop van de dienstverlening verwijdert de verwerker de gegevens of bezorgt hij ze aan je terug, inclusief de kopieën, tenzij hij ze wettelijk moet bewaren. Laat de partij schriftelijk bevestigen dát het is gebeurd.
2. Wat er met de kopieën en de laatste back-upset gebeurt. Dit is de uitzondering op punt 1 en meestal de enige. Kies expliciet: alles weg op de genoemde datum, of de laatste set blijft nog een afgesproken aantal maanden terugzetbaar bij de oude partij, met een hersteltermijn en een contactpersoon erbij. Die bewaartermijn loopt bijna altijd langer door dan de nazorg hieronder, dus schrijf hem apart op.
3. Een contactpersoon voor 30 dagen nazorg. Eén naam, één mailadres, één telefoonnummer bij de vertrekkende partij, met een afgesproken reactietermijn. In die eerste maand komt het vergeten verificatierecord boven, of het scriptje dat op een servicetoken draaide. Zonder naam op papier praat je met een algemene inbox van een leverancier die je net hebt opgezegd.
4. De datum waarop je afrekent. Koppel de laatste betaling aan de ondertekening van deze tabel, niet aan de contractdatum. Dat is je enige echte hefboom, en hij werkt alleen zolang je hem nog niet hebt gebruikt.

Sluit daarnaast een verwerkersovereenkomst met je nieuwe partij vóór de go-live. Pas als de tabel is afgetekend, trek je de toegang van de oude partij in: beheerrelatie beëindigen, sessies en OAuth-tokens intrekken, gedeelde geheimen roteren, in die volgorde en per kanaal.

Waar het misgaat

De faalmodi bij een overstap zijn opvallend voorspelbaar. Dit zijn de zes die ik het vaakst zie, met wat je ertegen doet.

Je zegt de beheerrelatie op voordat je eigen beheerder werkt. Dit is de klassieker, en de duurste. Je sluit jezelf buiten je eigen tenant en mag daarna de supportafdeling van Microsoft gaan bellen om te bewijzen dat het bedrijf van jou is. Test je eigen inlog in een privévenster voordat je iets beëindigt.

Je inventariseert per persoon. Je loopt de gebruikerslijst na, ziet niemand van je oude leverancier staan en concludeert dat het geregeld is. De beheerrelatie, de API-tokens, de OAuth-toestemmingen en de service-accounts staan niet in die lijst. Loop de kanalen na, niet de mensen.

Je begint te laat aan de licenties. Zes weken klinkt overdreven tot je bedenkt dat het goedkeuringsverzoek bij de oude partner ligt, dat het na 30 dagen verloopt en dat een verlopen abonnement betekent dat je mensen niet meer bij hun mail kunnen. Zet de licentieoverdracht als eerste in de agenda, niet als laatste.

Je verhuist je domein zonder de zone eerst na te bouwen. De verhuizing zelf duurt seconden. Het zijn de vijftien records eronder die je vergeet: de verificatierecords van je CRM, je mailmarketingtool, je videobelplatform. Neem de nulmeting uit stap 1 en tik hem letterlijk over.

Je accepteert een kluis-export als overdracht. Je krijgt een bestand met 140 wachtwoorden en denkt dat je klaar bent. De ander heeft datzelfde bestand nog. Behandel elk wachtwoord dat je zo krijgt als tijdelijk en roteer het binnen twee weken, te beginnen bij de gedeelde beheeraccounts.

Je laat de tweede factor bij de oude partij staan. Bij veel accounts staat de authenticator-app of het herstelnummer nog op de telefoon van een beheerder die je nooit hebt ontmoet. Loop per account de aanmeldmethodes langs en zet ze om naar een sleutel of app die jij beheert, voordat je het wachtwoord wijzigt.

Beslis-kader: hoeveel wil je zelf in handen houden

Na de overstap moet je één ding beslissen dat de volgende jaren bepaalt: wat besteed je uit, en wat blijft van jou. Er zijn drie modellen, en ze verschillen niet in wie de knoppen bedient maar in wie de sleutels bezit.

Voor vrijwel elk MKB is gedeeld eigenaarschap de juiste keuze, en dat is geen compromis maar het enige model dat je een echte exit-optie geeft. Je leverancier doet het werk, jij bent houder van je domein, jij hebt een globale beheerder die je nooit gebruikt, en de licenties staan op je eigen naam. Dat kost je een uur per kwartaal en het scheelt je de volgende keer een maand.

Diezelfde vraag speelt bij de gereedschapskist eromheen. Je nieuwe partij komt met een eigen wachtwoordkluis, een eigen beheertool en een eigen back-upplatform, en dat is meestal prima: kant-en-klaar werkt hier beter dan zelfbouw. Eén uitzondering. Neem je eigen zakelijke kluis, bijvoorbeeld Bitwarden of 1Password, op naam van je bedrijf, en geef je leverancier daar een gedeelde map in. Dan verhuist bij de volgende wissel de toegang, niet de kluis. Maatwerk is hier bijna nooit het antwoord, behalve op één plek: als de vertrekkende partij ook je eigen software of koppelingen bouwde, dan moet iemand die code overnemen, draaiend krijgen en documenteren, en dat is echt werk in plaats van een knop.

De wet schuift trouwens jouw kant op. Sinds 12 september 2025 gelden de regels van de Europese Data Act voor het overstappen tussen dataverwerkingsdiensten, en vanaf 12 januari 2027 mogen aanbieders helemaal geen overstapkosten meer rekenen, inclusief de kosten voor het weghalen van je data. Dat helpt bij cloudleveranciers. Het helpt niet bij een lokale beheerpartij die simpelweg de inlog heeft, dus daar blijft je contract je enige hefboom. Een bredere aanpak om die afhankelijkheid per systeem af te bouwen staat in het draaiboek waarin je elk systeem scoort op vijf lock-in-assen en per systeem een route kiest.

Zo ziet het eruit in de praktijk

Neem een fictief maar herkenbaar voorbeeld: een installatiebedrijf met 28 medewerkers, 34 Microsoft 365 Business Premium-licenties via een lokale beheerpartij, een FortiGate op kantoor, een WordPress-site bij een hoster die het bureau uitkoos, en een domeinnaam waarvan niemand weet op wiens naam hij staat. Het contract loopt af op 31 oktober. De nieuwe partij begint op 1 november.

Week 1 (begin september). De nulmeting wijst twee dingen uit. De domeinnaam staat op naam van het bedrijf zelf, met de beheerpartij als reseller: goed nieuws. Maar het beheerderscontact bij de registrar is een adres van die beheerpartij, en in Entra staan twee globale beheerders die allebei van de leverancier zijn. Het bedrijf maakt een eigen beheerdersaccount aan, test het, en zet twee noodaccounts klaar.

Week 2. De vraag om een overdrachtsdocument gaat de deur uit, per kanaal. Het antwoord komt binnen vijf werkdagen en levert één verrassing op: de back-ups draaien op een account van de leverancier, met een encryptiesleutel die nergens buiten hun kluis staat.

Week 3 en 4. De nieuwe partij stuurt de relatieaanvraag, het bedrijf accepteert die, en het overdrachtsverzoek voor de 34 licenties gaat naar de oude partner. Die keurt het na acht dagen goed. Zonder die voorsprong was de overdracht pas half oktober rond geweest, en dan wordt het spannend.

Week 5. TTL's omlaag naar 300 seconden. Een dag later verhuist het domein naar de registrar van de nieuwe partij, met een zone die vooraf record voor record is nagebouwd. De controle achteraf vindt één ontbrekend verificatierecord van de urenregistratie-app. Binnen tien minuten hersteld, omdat het in de nulmeting stond.

Week 6. Hosting en site verhuizen, met een volledige back-up plus database. Het certificaat wordt opnieuw uitgegeven in plaats van meegenomen. Het FortiCare-contract gaat over met een token dat de oude partij aanmaakt en dat de nieuwe binnen vijf dagen inwisselt.

En dan de back-up, de knoop uit week 2. De encryptiesleutel blijkt aan het platformaccount van de leverancier te hangen en is niet los overdraagbaar; de historische set losweken en versleuteld exporteren zou de oude partij drie dagen werk kosten, en over die factuur worden ze het niet eens. Het bedrijf kiest daarom bewust route twee uit stap 8. Vanaf 1 november loopt er een nieuwe retentieketen op een back-upaccount op naam van het bedrijf zelf, met de sleutel in de eigen kluis. In de opzegbrief staat dat de oude partij de bestaande set nog twaalf maanden bewaart en op verzoek binnen vijf werkdagen terugzet, met een naam en een telefoonnummer erbij. Dat kost een klein bedrag per maand en het lost de echte vraag op: waar staat mijn historie, en wie kan hem terughalen. De boekhouding van vóór 1 november haalt het bedrijf niet uit de back-up maar uit het boekhoudpakket zelf, dat op eigen naam staat. Uit het nieuwe account wordt één postbus echt teruggezet voordat iemand iets aftekent.

31 oktober. De kanalenlijst is afgetekend, de verwerkersovereenkomst met de nieuwe partij is getekend, en de oude partij heeft schriftelijk bevestigd wat er verwijderd wordt. Dan pas gaat de beheerrelatie eruit, worden de sessies ingetrokken en gaan de gedeelde wachtwoorden op de rotatielijst. Totale downtime: nul minuten.

De volgorde is wat dit voorbeeld saai maakt. En saai is precies wat je wilt.

Wat je hieraan overhoudt

Een leverancierswissel voelt als een project over techniek, maar hij test iets anders: of je bedrijf weet waar het aan hangt. De meeste ondernemers ontdekken pas tijdens zo'n overstap dat hun domeinnaam, hun mail en hun back-ups alle drie aan een ander account hangen dan ze dachten, en dat het geen kwade opzet was maar tien jaar gemak.

Dat is te repareren, en het blijft daarna gerepareerd. De sleutels die je nu binnenhaalt, geef je niet opnieuw weg: je nieuwe partij werkt straks in jouw tenant, met jouw domein, onder jouw licenties. De volgende keer dat je wisselt, is dit geen project meer maar een middag werk. Dat is de echte opbrengst, niet dat je van je oude leverancier af bent.