Microsoft Fabric brengt verschillende gegevensactiviteiten samen, waaronder data-integratie, opslag, engineering, analytics en Power BI. Voor organisaties die al Power BI gebruiken, kan dat mogelijkheden bieden om bronnen en rapportages dichter bij elkaar te organiseren. Toch is ‘van Power BI naar Fabric migreren’ niet hetzelfde als een klassieke productvervanging. Power BI blijft een belangrijk onderdeel van Fabric, en veel bestaande rapporten hoeven niet opnieuw gebouwd te worden. De werkelijke verandering zit vaak in de architectuur, het beheer van data en de beschikbare capaciteit.
Een goede migratiestrategie begint daarom met de vraag welk probleem wordt opgelost. Moeten bronsystemen beter worden geïntegreerd? Is er behoefte aan één datafundament voor meerdere afdelingen? Worden bestaande dataflows en semantische modellen moeilijk te onderhouden? Of speelt vooral de wens om nieuwe functies uit te proberen? Elk doel leidt tot een ander stappenplan, andere kosten en andere technische risico’s.
Eerst vaststellen wat er al is
Breng het huidige Power BI-landschap in kaart: workspaces, apps, rapporten, semantische modellen, gateways, geplande verversingen, dataflows, RLS-regels en verbindingen met databronnen. Noteer per onderdeel de eigenaar, zakelijke prioriteit, huidige licentie en eventuele afhankelijkheden. Vergeet niet de rapporten die op het eerste gezicht nauwelijks gebruikt worden, maar aan het einde van elk kwartaal essentieel zijn voor de administratie.
Maak onderscheid tussen opslag, verwerking en presentatie. Een Power BI-rapport dat een centraal SQL-model gebruikt, heeft andere migratiemogelijkheden dan een rapport met lokale Excel-bestanden en complexe Power Query-transformaties. Wie alleen naar het aantal dashboards kijkt, mist de werkelijke architectuur. Breng daarom een lineage-overzicht in beeld: welke databron levert welke transformatie en welk semantisch model, en welke rapporten hangen daarvan af?
Power BI blijft bestaan binnen het landschap
Fabric is geen reden om alle bestaande Power BI-content onmiddellijk om te bouwen. Rapporten, semantische modellen en apps kunnen een bruikbare presentatie- en analyzelaag blijven. Voor sommige organisaties is de eerste stap zelfs uitsluitend het toevoegen van een centrale lakehouse- of warehousevoorziening aan bestaande rapportstromen. Andere organisaties beginnen met governance of het verplaatsen van een specifieke dataflow.
Bepaal daarom welke onderdelen intact blijven, welke opnieuw ontworpen moeten worden en welke experimenteel mogen veranderen. Een volledig nieuw semantisch model kan waardevol zijn bij inconsistenties, maar veroorzaakt ook risico’s voor gevestigde KPI-definities. Maak expliciet onderscheid tussen technische vernieuwing en inhoudelijke wijziging. Tijdens een technische migratie zouden definities van omzet, marge en actieve klanten in beginsel gelijk moeten blijven, tenzij daar afzonderlijk besluitvorming over plaatsvindt.
Begrijp OneLake, lakehouse en warehouse
OneLake is de overkoepelende opslaglaag in Fabric. Een lakehouse biedt mogelijkheden om bestanden en gestructureerde data in een analyticsomgeving te combineren. Een warehouse sluit aan bij relationele, SQL-georiënteerde analyses. Welke variant past, hangt af van bronnen, expertise, transformaties en de beoogde gebruikers. Een organisatie met veel relationele SQL-kennis kan een andere voorkeur hebben dan een data-engineeringteam dat met notebooks en grote hoeveelheden ongestructureerde gegevens werkt.
De keuze moet ook rekening houden met eigenaarschap van ruwe en bewerkte data. Een overzichtelijke architectuur onderscheidt doorgaans brongetrouwe gegevens, gevalideerde bedrijfsgegevens en publicatieklare datasets. Gebruik herkenbare namen en definieer wie wijzigingen mag doen. Het enkele opslaan van bestanden in OneLake levert nog geen herbruikbare informatiearchitectuur op. Zonder governance kan een centrale opslag juist meer tegenstrijdige datasets opleveren.
Capaciteit en licenties vooraf toetsen
Fabric maakt gebruik van capaciteit en daarbij horende verwerkings- en opslagkosten. Een licentie voor een individuele rapportmaker vervangt niet automatisch de benodigde capaciteit voor alle Fabric-workloads of AI-functies. De gekozen SKU, workloadmix, regio, opslag, belasting en distributierechten bepalen de kosten en mogelijkheden. Controleer actuele voorwaarden direct bij Microsoft en maak een kostenmodel op basis van meetbare aannames.
Meet niet alleen het dagelijkse gemiddelde. Rapportverversing, data-ingestie, notebooks en analytische vragen kunnen op hetzelfde moment capaciteit gebruiken. Een rustige proefomgeving geeft daarom niet vanzelf een realistische voorspelling voor productie. Plan testvensters voor piekbelasting en documenteer welke taken de meeste resources vragen. Leg tevens vast wie de capaciteit mag aanpassen of pauzeren en wat dat betekent voor bedrijfskritische processen.
Kies een beperkte eerste usecase
De eerste Fabric-pilot moet zakelijk waardevol zijn maar begrensd blijven. Een geschikte casus kan het combineren van verkoopdata en voorraaddata zijn voor een dagelijkse rapportage. Het bestaande Power BI-dashboard blijft dan voorlopig ongewijzigd, terwijl de onderliggende gegevensstroom naar een nieuw lakehouse of warehouse wordt gebracht. Zo kan de organisatie prestaties, volledigheid en kosten vergelijken zonder tegelijkertijd alle gebruikers te laten overstappen.
Definieer de referentie-uitkomsten vooraf. Leg voor een volledige maand vast hoeveel orders, voorraadregels en retouren verwacht worden en welke controles tussen bron en rapport bestaan. Geef de pilot ook een duidelijke beëindigingsvoorwaarde. Als de nieuwe architectuur aantoonbaar trager, duurder of moeilijker te beheren blijkt dan het huidige proces, moet terugkeer naar de oude route mogelijk blijven. Een pilot is bedoeld om aannames te testen, niet om een vooraf gekozen oplossing achteraf te rechtvaardigen.
Praktijkcasus: van losse Excel-exports naar een datafundament
Een groothandel heeft twintig Power BI-rapporten. Drie afdelingen leveren iedere week eigen Excel-exports aan en onderhouden afzonderlijke Power Query-stappen. Daardoor worden productcodes anders geïnterpreteerd en ontstaan uiteenlopende marges. De organisatie kiest één productenlijst als centrale dimensie en richt in Fabric een gecontroleerde gegevensstroom in voor verkoop-, voorraad- en kostprijsinformatie.
De migratie begint met het vastleggen van de bestaande berekeningen. Vervolgens laden de data-engineers de bronbestanden in een afgebakend werkgebied en bouwen ze validatieregels voor productcodes, valuta, datums en ontbrekende kostprijzen. De Power BI-analist maakt een semantisch model dat verwijst naar de gevalideerde gegevens. De financiële controller vergelijkt de uitkomsten per maand met de goedgekeurde oude rapportage. Verschillen worden in een log vastgelegd en eerst verklaard voordat de nieuwe rapportage wordt vrijgegeven.
Pas na drie consistente verversingscycli wordt de nieuwe route voor de pilotafdeling leidend. Andere afdelingen volgen later, wanneer hun eigen bronproblemen zijn opgelost. Dit voorkomt een big-bangmigratie waarbij veel dashboards tegelijk onbetrouwbaar worden.
Direct Lake, Import en DirectQuery afwegen
De manier waarop een semantisch model data benadert heeft invloed op actualiteit en prestaties. Import laadt een kopie van gegevens in het model en heeft voorspelbare analysemogelijkheden, met een benodigde verversingscyclus. DirectQuery vraagt gegevens doorgaans bij de onderliggende bron op, wat prestaties en beschikbaarheid afhankelijk maakt van die bron. Direct Lake is voor geschikte Fabric-opslagscenario’s ontworpen om gegevens efficiënt te analyseren zonder traditionele volledige imports, maar kent specifieke vereisten en beperkingen.
Kies geen opslagmodus uitsluitend omdat deze technisch modern klinkt. Vergelijk op datavolume, vereiste actualiteit, kosten, capaciteit, modellering, beveiliging en gedrag bij storingen. Test dezelfde representatieve vragen met een afgesproken dataset. Wanneer een Direct Lake-scenario door specifieke modelkenmerken terugvalt op een andere uitvoeringsroute, kan dat de verwachte prestaties beïnvloeden. Documenteer dus het werkelijke gedrag, niet alleen de ingestelde modus.
Migratie van pipelines en transformaties
Bestaande Power Query-stappen, dataflows, gateways en geplande verversingen vormen een cruciale afhankelijkheidsketen. Niet elke transformatie kan zonder aanpassing worden verplaatst naar een Fabric-pipeline, notebook of dataflow. Sommige stappen worden beter in SQL uitgevoerd, andere blijven prima in Power Query. Beoordeel onderhoudbaarheid en foutdiagnose, niet alleen technische uitvoerbaarheid.
Documenteer voor ieder proces de bron, eigenaar, verwachte uitvoerfrequentie, afhankelijkheden, controlegetallen en herstelmethode. Een gegevensstroom die gedeeltelijk mislukt, mag niet stilzwijgend verouderde en nieuwe data combineren zonder signalering. Richt monitoring in voor doorlooptijd, foutmeldingen, datavolume en laatste succesvolle run. Het beheerteam moet weten hoe een mislukte run veilig opnieuw gestart kan worden en of dat dubbele gegevens kan veroorzaken.
Beveiliging opnieuw valideren
Een bestaande Power BI-RLS-configuratie biedt niet automatisch dezelfde bescherming voor alle nieuwe Fabric-items. Lakehouses, warehouses, notebooks, workspaces en semantische modellen hebben verschillende toegangspaden en machtigingen. Ontwerp rechten per laag: wie mag ruwe data openen, wie mag transformaties wijzigen en wie mag alleen rapporten bekijken? Test het verschil tussen lezen, bouwen, exporteren en beheerrechten.
Voer negatieve tests uit met accounts die geen toegang horen te hebben. Controleer ook serviceprincipals, gateways en geautomatiseerde verbindingen. Een oplossing kan functioneel werken dankzij een te machtig technisch account, terwijl dat strijdig is met least privilege. Leg tijdelijke uitzonderingen vast met een einddatum en verantwoordelijke. Betrek waar nodig de privacy- of securityfunctionaris bij gegevens die onder bijzondere regelgeving vallen.
Releasebeheer en terugvalscenario
Maak ontwikkel-, test- en productieafspraken voordat meerdere teams afhankelijk worden van Fabric. Gebruik ondersteunde broncode- en deploymentmogelijkheden waar passend, maar controleer welke itemtypen en eigenschappen daadwerkelijk ondersteund worden. Een publicatie van een rapport zegt nog niet dat de onderliggende pipeline en capaciteit correct zijn ingericht. Neem daarom infrastructuur, toegangsrechten en datastromen mee in de acceptatie.
Voor bedrijfskritische rapportages is een parallelle periode verstandig. Laat oud en nieuw gedurende een afgesproken aantal cycli dezelfde cijfers produceren. Registreer afwijkingen per definitie en bronperiode. Maak duidelijk welke bron leidend is als er tijdens de pilot verschillen optreden. Pas na formele goedkeuring wordt de oude keten uitgefaseerd. Bewaar daarbij relevante audit- en migratiedocumentatie.
Beheer na de migratie
Een moderne dataomgeving vraagt blijvend eigenaarschap. Benoem wie broncontracten onderhoudt, wie nieuwe datasets mag aanmaken, wie KPI’s definieert en wie capaciteitskosten volgt. Voorkom dat ieder team een eigen kopie van dezelfde gegevensstroom bouwt. Stel een aanvraagproces in voor nieuwe rapportages en houd een overzicht bij van gecertificeerde of ondersteunde datasets. Hergebruik moet gemakkelijker zijn dan ongecontroleerde duplicatie.
Meet het resultaat op meerdere assen: sneller beschikbaar gestelde betrouwbare gegevens, minder handmatige exports, minder verschillen tussen afdelingsrapportages, voorspelbare capaciteit en beheersbaar aantal incidenten. Wanneer alleen nieuwe technische functies worden geteld, verdwijnt het oorspronkelijke bedrijfsdoel uit beeld. Fabric is waardevol wanneer de dataketen aantoonbaar beter wordt, niet alleen wanneer het aantal gebruikte Microsoft-producten toeneemt.
Training en eerste projectstap
Een Power BI-verdiepingstraining helpt bij semantische modellen, meetdefinities, beveiliging en rapportkwaliteit. Voor de Fabric-specifieke opslag en data-engineering is aanvullende deskundigheid of maatwerk nodig; een niet-bestaande Fabric-cursus hoeft niet als standaardopleiding te worden gepresenteerd. Start met één betrouwbare dataketen, een eigenaar en een meetbare zakelijke doelstelling.
De eerste praktische opdracht is een diagram van één bestaande Power BI-rapportage: bron, transformatie, model, rapport, gebruikers en rechten. Zoek daarna het onderdeel met de meeste fouten of handmatige handelingen en toets of Fabric juist dáár verbetering kan brengen. Die route voorkomt een technisch gedreven migratie zonder aantoonbaar nut.
Relevante documentatie
- Microsoft Learn: Microsoft Fabric overview — https://learn.microsoft.com/en-us/fabric/fundamentals/microsoft-fabric-overview
- Microsoft Learn: OneLake overview — https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview
- Microsoft Learn: Direct Lake overview — https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-create-lakehouse