Blogs

Waarom Fabric-migraties stranden: zes valkuilen die wij steeds zien gebeuren

Het oude platform loopt tegen zijn grenzen aan en de organisatie wil meer met data en AI. Dan komt de migratie naar Microsoft Fabric op tafel. Wij zien die migraties steeds op dezelfde zes valkuilen stranden. Bijna altijd beginnen ze met dezelfde geruststellende aanname: we zetten over wat we hebben en bouwen zelf wat we missen. Het klinkt logisch. Toch gaat het juist dáár mis, want de zwaarste keuzes vallen aan het begin.

16/10/2026 Stefan Daelemans

1. Migreren is verhuizen. Wie niet opruimt, neemt de rommel mee

De snelste route lijkt alles één op één naar Fabric overzetten: dezelfde bronnen, dezelfde modellen, dezelfde koppelingen. Maar dan verhuist elke omweg mee, inclusief dat ene script dat niemand meer durft aan te raken. Je krijgt hetzelfde platform op een nieuwe plek. De rapportages blijven even traag en de discussies in het bedrijf even lang. De migratie is juist hét moment om je datamodel opnieuw te ontwerpen. Doe je dat niet aan het begin, dan doe je het nooit meer.

2. Zelf bouwen wordt onderschat

De redenering klinkt logisch: er is een datateam, dus dat team bouwt het platform wel. Maar een platform bouwen is iets anders dan het daarna draaiend houden. We zagen een datateam dat lang met de basis bezig bleef, terwijl de vragen uit de operatie en de planning zich opstapelden. Zes maanden werk. De business wachtte nog op het eerste rapport. Dat team was niet te klein voor het werk, het was te klein om het werk en de ambitie tegelijk waar te maken.

3. Specialisten zijn schaars. En ze vertrekken weer

Kennis van Fabric is nog jong en schaars. Wie zelf bouwt, zoekt dus dezelfde mensen als elke andere organisatie met hetzelfde plan. De specialist die je inhuurt, vertrekt op een dag weer. Wat achterblijft is een platform dat niemand in huis nog helemaal doorgrondt. Daar komt bij dat Fabric doorlopend verandert: nieuwe functies, aangepaste grenzen aan opslag en rekenkracht, en iemand moet dat blijven volgen. Dat is geen project met een einddatum, maar een vaste last die je in de businesscase zelden terugziet.

4. Governance en beheer regel je aan het begin

Wie welke data mag zien, wie er eigenaar van is en hoe je voldoet aan wet- en regelgeving: dat leg je vast voordat je bouwt of je regelt het eigenlijk nooit meer. “We documenteren en beveiligen later wel” klinkt redelijk, maar in de praktijk komt daar weinig van terecht. Governance die je er achteraf in bouwt blijft een inhaalslag en ondertussen ontstaan er onbedoelde datalekken, zoekgeraakte informatie en compliance-risico’s. Groei door overnames maakt dat extra zichtbaar. Elke overname brengt een eigen boekhoudpakket, een eigen urensysteem en eigen rechten mee, terwijl de directie volgende maand de groepscijfers wil zien.

5. Losse bronnen blijven losse bronnen

Een migratie verplaatst je data, maar brengt die niet vanzelf samen. Systemen die nu langs elkaar heen werken, blijven dat na de overstap nog steeds doen. Tenzij je ze samenbrengt in één model, blijft de versnippering bestaan. Die versnippering kan op verschillende plekken ontstaan. Bronsystemen groeien jarenlang door, totdat niemand het overzicht nog heeft. Daarnaast zijn er vaak losse pakketten voor uren, klanten en facturatie die nooit op elkaar zijn afgestemd. Het gevolg? Vijf systemen leveren al snel verschillende definities op. Het MT discussieert daardoor over de cijfers, terwijl het gesprek eigenlijk over de koers zou moeten gaan. Dat is geen rapportageprobleem, maar een fundamentprobleem. Hoe je dat fundament inricht, bepaalt uiteindelijk of je één gedeelde waarheid overhoudt of vijf verschillende.

6. De business herkent de cijfers niet

Je kunt een technisch perfect werkend model bouwen dat de business toch links laat liggen. Simpelweg omdat het model niet de taal van de organisatie spreekt. Neem omzet. Als die in je model TBLORDEXT_3 heet, exporteert finance de data naar Excel en bouwt daar een eigen waarheid op. Daarom is een model in de begrippen van de organisatie zelf zoals omzet, marge en declarabiliteit geen luxe bovenop de migratie. Het bepaalt of je platform straks daadwerkelijk wordt gebruikt of juist wordt omzeild.

De drie vragen die je beantwoordt vóór de start

Wat kost het platform ná livegang? Niet alleen de bouw, maar het onderhoud, de updates en de mensen die het bijhouden.
Hoe snel staat het eerste rapport? Een migratie die pas na een jaar iets oplevert, verliest onderweg zijn draagvlak.
Wat gebeurt er als de bouwer vertrekt? Zit de kennis in hoofden of in het product?

Wie deze drie vragen scherp beantwoordt, haalt de grootste risico’s uit de migratie voordat er één euro is uitgegeven. Meer weten over de meestvoorkomende valkuilen? In ons e-book staan de tien die wij het vaakst tegenkomen, elk met hoe je hem aanpakt en een tip die je direct toepast.