De meeste Entra ID-migraties lopen niet vast op techniek. Na jaren van IAM-projecten bij uiteenlopende organisaties kan ik dat met zekerheid zeggen. De technologie van Microsoft Entra ID is volwassen, goed gedocumenteerd en in de meeste gevallen betrouwbaar. Toch zien we keer op keer dat migratieprojecten uitlopen, vastlopen of een fractie opleveren van wat ze beloofden.

De oorzaak ligt vrijwel altijd elders: in governance, data-kwaliteit en organisatorische besluitvorming. Dit zijn de vijf kritieke valkuilen die ik het meest tegenkom, en hoe je ze voorkomt.

Valkuil 1: Niemand is eigenaar van de identity data

Voordat je één account migreert, moet je weten: kloppen de gegevens die je migreert eigenlijk wel? In de meeste organisaties is het antwoord: nee, niet echt.

Accounts van medewerkers die al lang vertrokken zijn, staan nog actief. Groepen zijn ooit aangemaakt voor een project dat nooit doorging. Rollen zijn over de jaren heen gekopieerd zonder dat iemand heeft nagedacht of ze nog kloppen.

De technische migratie pakt dit niet op. Die verplaatst wat er is, inclusief alle rommel.

Wat je nodig hebt, is een data-eigenaar: iemand die verantwoordelijkheid neemt voor de kwaliteit van accounts, groepen en rollen vóórdat de migratie begint. Dat is geen technische rol, maar een business-rol. En dat maakt het lastig, want de business vindt identity management doorgaans een IT-probleem.

Maak het vroeg in het project bespreekbaar. Anders betaal je de prijs later.

Valkuil 2: De legacy-applicaties waar niemand aan wil

Elke organisatie heeft er minstens één: de applicatie die al tien jaar draait, waar de helft van de kritieke processen op steunt, en waarvan niemand meer precies weet hoe hij werkt. Geen recente documentatie. Geen actieve leverancier. Soms niet eens een eigenaar meer binnen de organisatie.

En die applicatie is afhankelijk van het identity-systeem dat je wilt vervangen.

Dit soort applicaties worden vaak bewust buiten de scope van een migratie gehouden, "we pakken dat later op" , maar dat moment komt zelden. Ze worden een blokkade die het volledige traject vertraagt.

De aanpak: inventariseer alle applicaties met een identity-afhankelijkheid vóór de start van de migratie. Niet alleen de moderne applicaties met nette API's, maar juist de oude, onbekende, vergeten systemen. Categoriseer ze op risico en plan ze expliciet in, óf als onderdeel van de migratie, óf als bewuste uitzondering met een duidelijke einddatum.

Wat je niet wilt, is halverwege ontdekken dat je een applicatie bent vergeten die drie afdelingen dagelijks gebruiken.

Valkuil 3: Geen governance-structuur voor besluitvorming

Een migratie brengt tientallen beslissingen met zich mee. Wie krijgt welke rol? Welke groepen worden gemigreerd en welke worden opgeheven? Wie mag conditional access policies goedkeuren? Wat is het beleid voor gastaccounts?

Als die beslissingen niet belegd zijn, belanden ze in een mailthread. Die thread wordt doorgestuurd. Er wordt om input gevraagd bij mensen die er geen tijd voor hebben. En het project staat stil.

Wat werkt: stel een stuurgroep in vóór de kick-off, met duidelijk mandaat. Bepaal per categorie beslissing wie het laatste woord heeft. Maak een RACI die niet vijf mensen op responsible zet voor dezelfde keuze.

Governance klinkt zwaar. Maar het alternatief is erger: een project dat wekenlang wacht op een beslissing die in vijf minuten genomen had kunnen worden.

Valkuil 4: HR en IT praten niet met elkaar

Joiner-mover-leaver processen zijn de ruggengraat van elk identity systeem. Iemand komt in dienst, krijgt een account. Iemand wisselt van rol, krijgt andere rechten. Iemand vertrekt, account wordt geblokkeerd.

Simpel in theorie. Een nachtmerrie in de praktijk als HR en IT niet op dezelfde lijn zitten.

Wat ik vaak zie: HR werkt met een eigen systeem (of Excel), IT heeft een eigen registratie, en de synchronisatie daartussen is handmatig en inconsistent. Medewerkers hebben soms al twee weken gewerkt voordat hun account aangemaakt is. Vertrokken medewerkers hebben soms nog weken na hun laatste werkdag actieve toegang.

Een Entra ID-migratie is het ideale moment om dit te repareren, maar dan moet je HR vroeg betrekken. Niet als informatieverstrekker, maar als procespartner. De kwaliteit van hun data bepaalt de kwaliteit van je identity omgeving.

Investeer in de koppeling tussen HR-systeem en Entra ID. Automatiseer de triggers. En maak afspraken over wie verantwoordelijk is als er iets niet klopt.

Valkuil 5: Scope-creep zonder bewaking

"Kunnen we gelijk ook...?"

Die zin is de gevaarlijkste in elk migratieproject. En hij wordt altijd uitgesproken door iemand met goede bedoelingen.

Kunnen we gelijk ook de MFA-uitrol meenemen? Kunnen we ook de conditional access policies herzien? Kunnen we ook die oude on-premises Active Directory opruimen?

Elk van die vragen is legitiem. Maar als je ze allemaal gelijk meeneemt, verdubbel je de scope zonder dat je het budget en de doorlooptijd aanpast.

De oplossing is geen harde nee, het is een gecontroleerd ja. Houd een backlog bij van alle scope-uitbreidingen die worden aangedragen. Beoordeel ze per sprint of per kwartaal. Neem alleen mee wat past binnen de planning en de resources.

En wees transparant: als iets de opleverdatum beïnvloedt, zeg dat dan meteen. Niet achteraf.

De rode draad

Entra ID is een krachtig platform. Maar het lost geen organisatorische problemen op, het maakt ze zichtbaarder.

De organisaties die het beste uit hun migratie halen, zijn niet de organisaties met het grootste budget of de meest ervaren technische teams. Het zijn de organisaties die governance, data en communicatie serieus nemen vóórdat de eerste lijn code wordt geschreven.

Bezig met een Entra ID-traject? Of heb je er eentje achter de rug? Ik ben benieuwd welke van deze valkuilen je het meest herkent, of welke ik vergeten ben.