Agentic development: sneller bouwen, maar niet zonder ontwikkelaar

Een van de interessantste ontwikkelingen is de verdere ondersteuning voor agentic development in Power BI. Dankzij MCP-servers en andere AI-integraties kunnen ontwikkelaars steeds meer werkzaamheden aan AI-assistenten overlaten. Denk aan het opzetten van datamodellen, schrijven van DAX-measures en bouwen en opmaken van rapporten.

In oktober is de Power BI Report Authoring Skill uitgebreid met ondersteuning voor custom visuals en algemeen beschikbaar gemaakt. AI-agents kunnen hiermee ook aangepaste visualisaties toevoegen, koppelen aan gegevens, opmaken en controleren. Daarmee wordt het mogelijk om steeds meer onderdelen van een rapport automatisch te ontwikkelen.

Bij Bitmetric gebruiken we Claude via een MCP-koppeling om eerste versies van Power BI-oplossingen te bouwen.

Dat levert behoorlijk wat tijdwinst op. Zoals een van onze consultants het omschrijft: “Geen twee dagen werk meer alleen om padding goed te krijgen op elke pagina.”

Vooral voor het snel bouwen van een proof of concept zijn de resultaten indrukwekkend. Tegelijkertijd merken we dat het verfijnen van een eerste versie soms verrassend veel tijd kost.

We schreven eerder al over de mogelijkheden van MCP-servers voor Power BI. Inmiddels zien we hoe deze technologie het dagelijkse ontwikkelwerk verandert.

Onze kijk: AI neemt steeds meer uitvoerend ontwikkelwerk over. De rol van de ontwikkelaar verschuift daardoor naar het begrijpen van de informatiebehoefte, het ontwerpen van goede datamodellen en het beoordelen van resultaten. Juist daar zit de toegevoegde waarde.

Meer informatie: Power BI October 2026 Feature Summary.

Fabric Data Agents: betere antwoorden beginnen bij betere definities

Microsoft heeft de geavanceerde SQL- en DAX-generatie voor Fabric Data Agents algemeen beschikbaar gemaakt. Hierdoor kunnen agents beter bepalen welke tabellen, relaties en berekeningen nodig zijn om vragen over bedrijfsdata te beantwoorden.

Dat is een belangrijke verbetering, want een technisch correcte query levert niet automatisch een inhoudelijk correct antwoord op.

Stel dat iemand vraagt naar de omzet in Duitsland. Welke omzet bedoelen we precies? Inclusief retouren? Exclusief bepaalde leveranciers? En welke datum bepaalt de rapportageperiode?

Met de verbeterde querygeneratie kan een agent dergelijke context beter meenemen, mits die informatie beschikbaar is.

Onze kijk: de semantische laag wordt alleen maar belangrijker. Bedrijfsdefinities moeten duidelijk zijn vastgelegd en goed worden onderhouden. Daarnaast adviseren we om agents te testen met historische gegevens waarvan de juiste antwoorden bekend zijn. Zo controleer je of een agent niet alleen overtuigend antwoordt, maar ook de juiste cijfers oplevert.

Meer informatie: Advanced NL2SQL and advanced DAX generation.

Project Osmos: AI gaat ook data engineering uitvoeren

Met Project Osmos introduceert Microsoft een nieuwe AI-agent voor data engineering in Fabric. Tijdens FabCon Europe 2026 zagen we al hoe Microsoft steeds sterker inzet op AI binnen het dataplatform. Project Osmos is een volgende stap in die ontwikkeling.

In plaats van zelf alle stappen uit te werken, beschrijf je het gewenste resultaat. De agent kan vervolgens de data onderzoeken, code genereren, pipelines voorbereiden en controles uitvoeren.

Dat biedt mogelijkheden om ontwikkelwerk aanzienlijk te versnellen, maar vraagt ook om duidelijke afspraken.

Een van onze consultants formuleert daarvoor een helder uitgangspunt:

“De agent mag voorbereiden, maar voert de wijziging pas uit na expliciete goedkeuring.”

Die goedkeuring moet gebaseerd zijn op een beoordeling van de gegenereerde code en validatieresultaten. Daarnaast zijn afspraken nodig over toegangsrechten, ontwikkel- en productieomgevingen, schemawijzigingen, monitoring en foutafhandeling.

Onze kijk: hoe zelfstandiger agents worden, hoe belangrijker het wordt om vooraf vast te leggen wat ze wel en niet mogen doen. Automatisering zonder controle is geen vooruitgang.

Meer informatie: Introducing the data engineering agent for Fabric.

Capaciteitsbeheer: liever een geweigerde refresh dan onverwachte kosten

Niet alle interessante updates draaien om AI.

Microsoft heeft de surge protection voor Power BI semantic models verbeterd. Hierdoor wordt eerder ingegrepen wanneer verwerkingen ingestelde capaciteitsgrenzen dreigen te overschrijden. De verbetering wordt automatisch toegepast. Je hoeft hiervoor geen instellingen aan te passen.

Dat kan betekenen dat een refresh eerder wordt geweigerd. Maar dat hoeft geen nadeel te zijn.

Een mislukte refresh is zichtbaar en kan worden onderzocht. Onverwacht hoog capaciteitsverbruik kan daarentegen financiële gevolgen hebben.

We zien frequente weigeringen bovendien als een nuttig signaal: misschien is het tijd om het datamodel of de verwerking te optimaliseren.

Onze kijk: goede capaciteitsbewaking gaat niet alleen over prestaties, maar ook over voorspelbare kosten. Uiteraard blijft het belangrijk om refreshes actief te monitoren.

Meer informatie: Power BI October 2026 Feature Summary.

Twee technische wijzigingen om rekening mee te houden

Naast deze ontwikkelingen zijn er twee wijzigingen die voor sommige organisaties directe gevolgen hebben.

Databricks: van ODBC naar ADBC. De nieuwe connector voor Power BI en Fabric is algemeen beschikbaar. Microsoft verwacht dat bestaande functionaliteit behouden blijft, maar organisaties met Databricks als databron doen er verstandig aan de overstap tijdig te testen.

Meer informatie: Databricks ADBC connector for Power BI and Microsoft Fabric

Fabric Data Agents in Microsoft Foundry. De bestaande integratie via een custom tool is per 6 november 2026 uitgefaseerd. Ontwikkelaars die deze koppeling gebruiken, moeten overstappen naar de nieuwe integratie via Fabric IQ.

Meer informatie: Retiring the Fabric data agent custom tool in Microsoft Foundry

Onze conclusie: de waarde verschuift van bouwen naar begrijpen

De ontwikkelingen van oktober laten zien hoe snel Microsoft AI integreert in Fabric en Power BI. Wat voorheen handmatig ontwikkelwerk was, kan steeds vaker door een agent worden voorbereid of uitgevoerd.

Dat verandert ook waar de waarde van een BI-specialist ligt.

Een agent kan een DAX-measure schrijven. Maar begrijpt hij waarom een organisatie omzet op een bepaalde manier berekent? Weet hij welke gegevens betrouwbaar zijn? En kan hij beoordelen of een dashboard daadwerkelijk helpt om betere beslissingen te nemen?

Die vragen worden alleen maar belangrijker.

Ons advies: zorg dat het fundament klopt voordat je AI breed inzet. Leg bedrijfsdefinities vast, organiseer het beheer en maak duidelijke afspraken over het gebruik van data en AI.

Dan wordt AI niet alleen een manier om sneller te bouwen, maar vooral om betere oplossingen te realiseren.

Meer uit je data halen met Power BI en Fabric?

Power BI Consultancy & Implementatie

Van slimme dashboards en betrouwbare datamodellen tot geavanceerde analyses. Onze Power BI-consultants helpen je om informatie toegankelijk te maken en inzichten te vertalen naar betere beslissingen.

Bekijk Power BI Consulting

Microsoft Fabric Consultancy & Implementatie

Wil je databronnen samenbrengen, processen automatiseren of een toekomstbestendig dataplatform ontwikkelen? Onze Fabric-consultants helpen je van architectuur en implementatie tot optimalisatie.

Bekijk Fabric Consulting

The post Microsoft Fabric en Power BI: de belangrijkste updates van oktober 2026 appeared first on Bitmetric.

Die lijst is te lang om helemaal te bespreken, en niet alles is voor elke organisatie even relevant. We hebben hem doorgelopen met één vraag in ons achterhoofd: wat verandert er voor de mensen die maandag gewoon weer met hun semantic models, pipelines en capaciteit aan de slag gaan? Dit is onze selectie.

De rode draad: je semantic model is nu je AI-interface

De grootste aankondiging is wat ons betreft niet één feature, maar de richting. Fabric IQ is nu algemeen beschikbaar (GA, Generally Available) in Microsoft Copilot Chat en Cowork, en dus niet meer alleen als preview. Gebruikers kunnen daar zakelijke vragen stellen, en de antwoorden zijn gebaseerd op je bestaande Power BI-rapporten en semantic models. Zonder extra kosten voor AI-tokens. Dat sluit precies aan op een ontwikkeling waar we eerder over schreven: je semantische laag wordt de API voor AI.

Daarnaast zijn de Fabric IQ MCP server en Fabric data agents in Copilot Studio GA, inclusief visualisaties in data agents. Ontologies, semantic views en het meenemen van DAX-measures naar ontologies volgen in preview.

Ook IQ sharing komt in preview. Daarmee kun je niet alleen governed data delen, maar ook businesscontext zoals agent instructions en ontologies beschikbaar maken voor andere teams, partners en ecosystemen. Ondersteuning voor Fabric IQ-ontologies en Power BI semantic models staat op de roadmap. Daarmee wordt semantische context binnen Microsoft Fabric steeds meer iets wat je kunt hergebruiken en delen, in plaats van iets dat alleen binnen één workspace of toepassing leeft.

Klinkt mooi. Maar het betekent ook dat elk rommelig model ineens een veel groter publiek krijgt. Die measure die “Measure 3” heet, de kolom zonder beschrijving, de relatie die alleen de oorspronkelijke ontwikkelaar begreep: Copilot gaat er net zo vrolijk mee aan de slag als met je best gedocumenteerde model. Een AI-assistent is zo goed als het model waar hij op leunt.

Voor iedereen die al jaren hamert op naamgeving en documentatie: dit is je moment. Geniet ervan

Governance: eindelijk grip op wat Copilot mag zien

Goed nieuws, want met het vorige punt in gedachten is dit precies wat je nodig hebt. Microsoft introduceert twee lagen controle:

• Restrict from Copilot: beheerders bepalen welke semantic models überhaupt meedoen in AI-ervaringen.
• Een instelling per semantic model die read-only toegang via Power BI Copilot, Microsoft 365 Copilot Chat, Cowork, data agents en remote MCP servers aan- of uitzet.

Let op: die tweede instelling staat standaard aan. Gebruikers met bestaande leesrechten kunnen het model dus via ondersteunde Copilot- en MCP-ervaringen gebruiken, tenzij je dit expliciet beperkt.

Verder lopen sensitivity labels, DLP-policies en information protection nu door naar Copilot. Met DLP restrict access kan Purview de toegang tot een Fabric-item beperken zodra er gevoelige data wordt gedetecteerd. Ook nieuw: de Govern-ervaring in de OneLake catalog, outbound access protection voor OneLake shortcuts en, in preview, Policies in Fabric met attribute-based controls.

Capaciteit: meer flexibiliteit, maar lees de kleine lettertjes

Capacity overage is GA. Loopt je capaciteit vol, dan koop je automatisch extra compute bij in plaats van gethrottled te worden. Handig, alleen is de prijs drie keer het pay-as-you-go-tarief, met een configureerbare rollende 24-uurslimiet voor overage in CU-uren. Bij nieuw aangemaakte capacities staat deze standaard aan. Controleer dus even welke drempel er bij jou ingesteld staat, voordat de eerste factuur dat voor je doet. Dit soort instellingen nemen wij standaard mee in ons Fabric-beheer.

Workspace-level surge protection is nu beschikbaar in preview en wordt verder uitgerold: daarmee isoleer je een op hol geslagen workspace, terwijl bedrijfskritische workspaces buiten schot blijven. Dat lost een probleem op dat we in de praktijk regelmatig tegenkomen, waarbij één experimentele notebook de rapportages van de hele organisatie meesleept.

Aan de andere kant van het spectrum komt de F0 SKU met on-demand billing: geen vooraf ingekochte compute, je betaalt per CU-uur zonder smoothing, met een rollende 24-uurs limiet. Interessant voor kleine omgevingen en ontwikkelwerk. Maar de prijzen zijn nog niet bekend, dus ik zou nog geen capaciteitsstrategie omgooien. Voor wie juist de andere kant op wil: F4096 en F8192 zijn er nu ook.

Fabric apps in Power BI

Fabric apps in Power BI komen de komende weken in preview voor Power BI Pro en Premium Per User, met tot 1 GB Fabric Database per app zonder extra kosten. In Power BI Desktop kun je straks een Fabric app laten bouwen vanuit een semantic model door in gewone taal te beschrijven wat je wilt, en die vervolgens bekijken, aanpassen en publiceren.

We zijn benieuwd hoe dit zich in de praktijk houdt. De drempel om iets te bouwen wordt een stuk lager, en dat is precies waarom het slim is om vooraf na te denken over wie wat mag publiceren. Anders heb je over een jaar vijftig Fabric apps waarvan niemand meer weet wie ze beheert.

Voor de data engineers

Minder in de spotlight, maar voor het dagelijkse werk misschien wel de nuttigste categorie:

• Copy job ondersteunt nu change data capture en audit columns. SCD Type 2 is nu algemeen beschikbaar. Dat scheelt een hoop zelfgeschreven boilerplate.
• Mirroring voor Google BigQuery en SharePoint Lists is GA. Dynamics 365 Business Central en een bidirectionele koppeling met Salesforce Data Cloud 360 volgen in preview.
• Git en CI/CD: compare and commit, selective branching en bulk import/export-API’s zijn GA. Deployment plans en file-level commits komen in preview.
• Warehouse: custom SQL pools zijn GA. GPU-accelerated query execution en een node-based billing model (prijs nog onbekend) zitten in preview.
• Data engineering agent (Project Osmos), in preview, helpt bij migraties, schema harmonization en ETL op Fabric Spark, en is aan te sturen vanuit onder andere GitHub Copilot, VS Code en Claude Code.
• Observability: unified workspace monitoring, een vernieuwde Monitor Hub, job alerts via Activator en een operations agent die als eerste pipeline failures onderzoekt.

In oktober heeft Microsoft meer details over Project Osmos bekendgemaakt. In onze Power BI en Fabric-update van oktober 2026 bespreken we wat deze ontwikkeling betekent voor data engineering en welke aandachtspunten wij daarbij zien.

Migreren vanuit Azure Data Factory of Synapse

Zit je nog op ADF of Synapse? Met View in Fabric haal je je bestaande omgeving naar een Fabric-workspace, terwijl ADF de bron van waarheid blijft. Een nieuwe assessment tool laat per pipeline zien hoe klaar hij is voor migratie. En de Migration Assistant ondersteunt Teradata nu in preview.

Dat is een verstandige insteek: eerst zien wat je hebt, dan pas verhuizen.

Planning, Copilot en database-updates

• Een Native Planning Engine in preview, waarvoor Microsoft tot 10x betere performance en schaal claimt. Daar ben ik benieuwd naar in een echte omgeving. Daarnaast kunnen planners via Fabric IQ met hun eigen identiteit op semantic models werken.
• Microsoft 365 Copilot in Power BI in preview, standaard uitgeschakeld en los van de bestaande Power BI Copilot-instelling.
• Aan de SQL-kant: DiskANN vector indexes, SQL Server op Azure Local, een Database Hub in Fabric (public preview) met één overzicht over Azure SQL, PostgreSQL, Cosmos DB en SQL database in Fabric, en database agents die performanceproblemen analyseren.
• Microsoft herhaalde zijn steun voor Apache Ossie, een open standaard voor het uitwisselen van semantische metadata. Klein nieuwtje, maar wel een goed teken.
  
  

Wat we je aanraden

1. Breng je semantic models op orde. Duidelijke namen, beschrijvingen, gecertificeerde measures en een security-model dat klopt. En bepaal per model bewust of het naar Copilot mag, in plaats van de standaardinstelling te laten beslissen.
2. Check je capacity overage-instelling. Hij staat standaard aan, tegen drie keer het normale tarief.
3. Verzamel nu je capaciteitsmetrics. Zodra de prijzen voor F0 en on-demand bekend zijn, wil je kunnen vergelijken met echte cijfers in plaats van een onderbuikgevoel.
4. Draai de assessment op je ADF- of Synapse-omgeving, ook als migreren nog niet op de planning staat. Dan weet je tenminste waar je staat.

Wil je sparren over wat dit voor jouw omgeving betekent? Laat het ons weten, we denken graag mee.

Barry Harmsen

Barry is oprichter van Bitmetric. Hij werkt al meer dan twintig jaar in data & analytics, in rollen die variëren van hands-on ontwikkeling tot architectuur en strategie. Hij houdt van oplossingen die passen bij de context van de organisatie en die mensen ook echt gebruiken. Lang geleden schreef hij QlikView for Developers.

Buiten zijn werk besteedt Barry zijn tijd aan zijn gezin, roeien, klussen en hobbyprojecten waar zijn gezin in wisselende mate enthousiast over is.

The post FabCon Europe 2026: de Fabric-updates die er echt toe doen appeared first on Bitmetric.

Geef een taalmodel toegang tot een database, vertel welke tabellen erin staan en vraag wat de omzet vorige maand was. De kans is groot dat er binnen enkele seconden een keurige query en een overtuigend antwoord uit komen.

Maar daarmee weet AI nog niet wat jullie onder omzet verstaan.

Gaat het om geboekte omzet, gefactureerde omzet of geleverde omzet? Tellen creditnota’s mee? Intercompany-omzet? Welke datum bepaalt de maand? En als iemand vraagt naar omzet in Nederland, bedoelen we dan het land van de klant, het afleveradres of de verkooporganisatie?

Dat is geen SQL-probleem. Het is een semantisch probleem.

En juist daarom krijgt een concept dat al decennia in Business Intelligence rondzingt ineens opnieuw veel aandacht: de semantic layer.

Sterker nog, ik denk dat de rol ervan fundamenteel verandert.

Tot nu toe bouwden we semantic models vooral om dashboards en rapportages van consistente businesslogica te voorzien. Straks gebruiken AI-agents diezelfde laag om onze organisaties te begrijpen.

Van BI-laag naar interface voor AI

De semantic layer is niet nieuw

Wie al wat langer in Business Intelligence rondloopt, zal het idee herkennen. In de klassieke BI-wereld was een semantic layer heel normaal. Een bekend voorbeeld is de BusinessObjects Universe. Een Universe plaatste een businessvriendelijke laag over de technische databasestructuur. Gebruikers werkten met herkenbare begrippen, dimensies, measures en hiërarchieën, zonder te hoeven weten hoe de tabellen en joins daaronder precies in elkaar zaten.

SAP omschrijft een Universe nog steeds als een verzameling metadata-objecten waarmee gebruikers data kunnen analyseren in niet-technische, begrijpelijke bedrijfstaal. (SAP Help Portal)

Cognos had met Framework Manager een vergelijkbaar concept.

Het idee was simpel en eigenlijk heel verstandig:

De database vertelt hoe data is opgeslagen, de semantic layer vertelt wat die data betekent.

Daar zat natuurlijk ook een keerzijde aan.

Deze klassieke BI-omgevingen konden behoorlijk zwaar worden. Voordat een gebruiker een rapport kon bouwen, moest er vaak eerst een datawarehouse zijn ontworpen, een centraal model zijn gebouwd, een Universe zijn ingericht en iemand toestemming hebben gegeven om ermee te werken.

Dat was niet bepaald agile.

Toen kwam self-service BI

Vanaf grofweg de tweede helft van de jaren 2000 veranderde het speelveld.

Producten zoals QlikView, later Qlik Sense en Tableau maakten het veel makkelijker om snel met data te werken. In plaats van maandenlang een centrale BI-laag te ontwerpen, kon een analyst of developer data laden, modelleren, visualiseren en vrijwel meteen iets bruikbaars opleveren.

Dat was een enorme vooruitgang.

Ik heb zelf jarenlang met Qlik gewerkt en juist die snelheid en vrijheid waren een groot deel van de aantrekkingskracht.

Maar er zat ook een consequentie aan die beweging: de expliciete, centraal beheerde semantic layer raakte wat uit beeld.

Dat wil niet zeggen dat Qlik, Tableau of later Power BI geen semantiek bevatten. Integendeel. Een Qlik-datamodel bevat relaties en businesslogica, Tableau kent logical models en Power BI heeft inmiddels uitgebreide semantic models.

Maar in de praktijk raakte die betekenis vaak verspreid over verschillende lagen. Zeker in Qlik werd veel businesslogica niet alleen in het datamodel vastgelegd, maar ook in variables, set analysis, master measures, scriptlogica en zelfs individuele objectexpressies.

Dat werkte prima zolang ervaren developers wisten waar alles stond en waarom iets zo was gebouwd. Maar het maakte de businessbetekenis minder expliciet, minder centraal en lastiger herbruikbaar buiten de oorspronkelijke applicatie.

De semantic layer als zelfstandig architectuurprincipe kreeg daardoor veel minder aandacht.

We gingen steeds vaker businesslogica vastleggen waar we die op dat moment nodig hadden:

• In een Qlik-app
• In een Tableau-workbook,
• In een Power BI semantic model,
• In een SQL-view,
• In een DAX-measure,
• In een ETL-script.

En soms op meerdere plaatsen tegelijk.

Self-service maakte analytics toegankelijker, maar maakte het ook heel makkelijk om meerdere versies van dezelfde waarheid te creëren.

Uiteindelijk liepen we tegen hetzelfde probleem aan

Zolang een organisatie een beperkt aantal dashboards heeft, valt het nog wel mee. Maar naarmate self-service BI succesvol wordt, verschijnen er tientallen of honderden modellen, apps en rapportages. Dan ontstaan bekende discussies.

Het opvallende is dat dit ongeveer dezelfde problemen zijn waarvoor de klassieke semantic layer ooit werd bedacht.

En dus kwam het concept terug.

Power BI spreekt tegenwoordig expliciet over semantic models. Looker bouwde een groot deel van zijn platform rond LookML. dbt ontwikkelde zijn Semantic Layer en MetricFlow. Data-platformleveranciers praten steeds vaker over metrics, data products, ontologies en semantic layers.

Ik kijk zelf soms met enige nostalgie terug op BusinessObjects. Universes waren zo gek nog niet. Maar de herwaardering van de semantic layer komt vooral doordat we opnieuw ontdekken dat toegang tot data iets anders is dan overeenstemming over de betekenis ervan.

En dan komt AI om de hoek kijken.

AI maakt het probleem veel groter

Neem opnieuw die vraag:

“Wat was onze omzet vorige maand?”

Een menselijke data-analist die onvoldoende context heeft, kan doorvragen:

Een analyst kan ook herkennen dat een resultaat vreemd lijkt. Als de omzet normaal rond de vijf miljoen ligt en er ineens 28 miljoen uit de query komt, gaat er waarschijnlijk ergens een alarmbel af.

Een AI-agent heeft die intuïtie niet automatisch.

Die kan een tabel vinden met een kolom Revenue, daar een andere tabel aan koppelen, een plausibele query genereren en met groot zelfvertrouwen een verkeerd antwoord presenteren.

Misschien is de join verkeerd. Misschien gebruikt hij bookings in plaats van revenue. Misschien wordt iedere orderregel drie keer geteld. Misschien kent hij een uitzondering van Finance niet.

Het antwoord kan er nog steeds uitstekend uitzien en dat maakt dit gevaarlijker dan een gewone foutmelding.

De uitdaging is niet meer om data vindbaar te maken

De afgelopen twintig jaar hebben we enorm veel energie gestoken in het toegankelijk maken van data.

Cloud datawarehouses, lakehouses, APIs, ELT, notebooks en self-service BI hebben ervoor gezorgd dat het technisch steeds eenvoudiger wordt om ergens bij te komen.

Generatieve AI doet daar nog een schep bovenop. Een gebruiker hoeft straks misschien niet eens meer te weten waar data staat. Hij stelt gewoon een vraag. Daarmee verschuift het probleem. De vraag is niet langer alleen:

“Kan AI bij onze data?”

De belangrijkere vraag wordt:

“Weet AI hoe onze organisatie die data interpreteert?”

Daar komt de semantic layer weer om de hoek kijken.

Het semantic model als contract

Ik vind het nuttig om een goed semantic model te zien als een soort contract. Het legt vast:

Technisch kan zo’n model bestaan uit measures, dimensies, relaties, berekende velden, hiërarchieën, metadata en securityregels, maar functioneel doet het iets belangrijkers. Het legt een gedeelte van de bedrijfstaal vast in een vorm die software kan gebruiken. Tot voor kort waren dashboards de belangrijkste afnemers van dat contract, nu komt daar een heel nieuw type consument bij: de AI-agent.

Microsoft bouwt hier al expliciet naartoe

Microsoft Fabric laat goed zien waar deze ontwikkeling naartoe gaat. Fabric Data Agents kunnen vragen beantwoorden over verschillende soorten enterprise data, waaronder warehouses, lakehouses en Power BI semantic models.

Microsoft heeft inmiddels zelfs aparte richtlijnen gepubliceerd voor het AI-ready maken van Power BI semantic models. Daarin benadrukt Microsoft onder andere het belang van duidelijke namen, beschrijvingen, correcte relaties en het terugbrengen van ambiguïteit in het model. De kwaliteit van antwoorden van een Data Agent hangt volgens Microsoft sterk af van hoe goed de gebruikte databronnen en semantic models zijn voorbereid.

Dat is veelzeggend.

We hebben metadata jarenlang vaak gezien als documentatie. Iets wat je eigenlijk zou moeten bijhouden, maar waar in de praktijk zelden genoeg tijd voor is. Voor AI verandert metadata van documentatie in “runtime context”. Een omschrijving van een measure is dan niet alleen nuttig voor de volgende developer. Een agent gebruikt die beschrijving daadwerkelijk om te bepalen wat de measure betekent en wanneer deze toegepast moet worden.

En dan komt MCP erbij

Microsoft ondersteunt daarnaast het gebruik van een Fabric Data Agent als Model Context Protocol-server, op dit moment nog in preview. Via MCP kan zo’n agent zijn data en querymogelijkheden beschikbaar stellen aan externe AI-systemen.

MCP is een standaard waarmee AI-applicaties op een uniforme manier tools, context en databronnen kunnen ontdekken en gebruiken. Het interessante is niet eens zozeer MCP zelf. Misschien wordt MCP over een paar jaar vervangen door iets beters. Het interessante is het architectuurprincipe erachter.

De applicatie waarin iemand zijn vraag stelt, hoeft niet langer dezelfde applicatie te zijn waarin de businesslogica wordt beheerd. Een AI-assistent kan ergens anders draaien en toch een governed data- of analyticslaag raadplegen. Dat maakt de semantic layer ineens veel meer dan de achterkant van een dashboard.

Het wordt een service.

Qlik kiest dezelfde richting

Qlik doet inmiddels iets vergelijkbaars.

Qlik heeft zijn MCP Server algemeen beschikbaar gemaakt en gebruikt die om externe AI-assistenten toegang te geven tot Qlik’s analytische mogelijkheden en governed data products. De onderliggende Analytics Engine en bestaande businesslogica kunnen daarmee worden gebruikt zonder dat de eindgebruiker noodzakelijk in Qlik zelf werkt.

Dat is een interessante ontwikkeling. Een traditionele discussie zou zijn:

“Gebruiken we Qlik of Power BI?”

Maar met deze architectuur kun je een andere vraag stellen:

“Waar beheren we de betrouwbare analytische context die onze gebruikers en agents nodig hebben?”

Een organisatie zou bijvoorbeeld Power BI als primaire rapportagetool kunnen gebruiken terwijl bepaalde governed data of analytische logica elders wordt beheerd.

Of een AI-assistent kan Qlik raadplegen zonder dat de gebruiker ooit een Qlik-dashboard opent. Dat maakt platformgrenzen minder vanzelfsprekend.

TimeXtender maakt het idee misschien nog explicieter

TimeXtender heeft zijn MCP-architectuur expliciet gebouwd rond “governed semantic models voor AI-agents”.

Daarbij wordt het semantic model als contract aangeboden aan een AI-client. Het model beschrijft onder andere entiteiten, relaties, metrics, hiërarchieën en relevante context. De AI hoeft daardoor niet zelf uit een technisch databaseschema af te leiden wat de business bedoelt.

TimeXtender formuleert het probleem treffend: een AI-systeem kan zonder zo’n context een veld kiezen dat logisch klinkt, een uitzonderingsregel missen of een technisch geldige maar inhoudelijk verkeerde join leggen.

En dat brengt ons eigenlijk weer terug bij het BusinessObjects Universe. We plaatsen opnieuw een businessvriendelijke laag tussen fysieke data en de consument. Alleen is die consument nu niet uitsluitend een rapportagegebruiker. Het kan ook software zijn.

Eén semantic layer, meerdere consumenten

Dat vind ik de fundamentele verschuiving. We hebben een semantic model lang gezien als iets dat bij een BI-tool hoort. Een Power BI semantic model hoort bij Power BI reports. Een Qlik model of Master Items horen bij Qlik visualisaties. Een Universe hoort bij Web Intelligence (of Deski).

Maar stel je een architectuur voor waarin dezelfde governed businesslogica wordt gebruikt door:

• Dashboards;
• Excel;
• Operationele applicaties;
• API’s;
• Copilots;
• Chatinterfaces;
• AI-agents;
• Autonome processen.

Dan verandert de economische waarde van die semantic layer behoorlijk. Het dashboard wordt één van de mogelijke gebruikers. Niet langer noodzakelijk het eindproduct waar alles omheen wordt gebouwd.

AI maakt goede modellering belangrijker, niet overbodig

Er is ook een tegenovergestelde gedachtegang. Als AI zelf queries kan schrijven, waarom zouden we dan nog zoveel tijd besteden aan modellen, measures en businesslogica? Kan het model dat niet gewoon uitzoeken?

Technisch steeds vaker wel, maar inhoudelijk is dat precies wat je niet wilt.

Hoe makkelijker het wordt om willekeurige data te bevragen, hoe belangrijker een betrouwbare betekenislaag wordt.

Tien medewerkers die hetzelfde dashboard bekijken, zien tenminste dezelfde omzet. Geef diezelfde tien medewerkers ieder een AI-agent die zelfstandig SQL genereert over een complex datawarehouse en je kunt plotseling tien verschillende antwoorden krijgen.

AI democratiseert toegang tot data. Zonder governance democratiseert het ook de mogelijkheid om op grote schaal verschillende waarheden te produceren. Dat maakt goed gemodelleerde en beheerde semantiek belangrijker dan ooit.

Dit verandert ook het werk van BI-teams

Als deze ontwikkeling doorzet, verschuift een deel van het werk van analytics-teams. Vandaag krijgen BI-teams nog veel verzoeken als:

Wanneer gebruikers via AI zelf vervolgvragen kunnen stellen, zal een deel van dat werk waarschijnlijk verdwijnen. Maar dat betekent niet dat het werk verdwijnt. Iemand zal nog steeds moeten bepalen:

• Wat KPI’s precies betekenen;
• Waar de officiële definitie wordt beheerd;
• Welke relaties correct zijn;
• Welke data betrouwbaar is;
• Welke uitzonderingen gelden;
• Welke informatie iemand mag gebruiken;
• Welke modellen leidend zijn;
• Hoe veranderingen worden getest;
• Hoe lineage en ownership worden vastgelegd.

De waarde verschuift van iedere vraag visualiseren naar betrouwbare betekenis organiseren. Voor data- en analyticsprofessionals lijkt mij dat eigenlijk een gezonde ontwikkeling. Al moeten we wel eerlijk zijn: definities documenteren en metadata bijhouden is meestal iets minder leuk dan een mooie visual bouwen.

En onze semantic models zijn daar nog lang niet altijd klaar voor

Er is alleen één probleem. Veel bestaande semantic models zijn ontworpen voor menselijke developers.

Een Power BI-developer weet misschien precies wat een measure met de naam [NS Adj LY %] betekent. Een AI-agent niet.

Een Qlik-developer weet waarom een bepaalde set analysis expression een uitzonderlijke selectie toepast. Een agent die alleen het eindresultaat ziet, heeft geen idee waarom.

Voor AI-ready semantic models worden daardoor zaken belangrijk die we vroeger makkelijk als “nice to have” zagen.

Dit zijn geen exotische AI-technieken. Het zijn grotendeels dezelfde disciplines die we altijd al nodig hadden voor goede BI. AI verhoogt alleen de prijs van slordigheid.

Van semantic layer naar bedrijfsinfrastructuur

Daarom denk ik dat we semantic models opnieuw anders moeten gaan bekijken. Niet als een technisch onderdeel van Power BI. Niet als iets dat alleen in Qlik-apps leeft. Niet als een extra modelleringstool bovenop het datawarehouse.

Een goed opgebouwde semantic layer is in feite een machine-readable beschrijving van hoe een organisatie naar haar eigen data kijkt.

Dat is een waardevol bedrijfsmiddel. Misschien zelfs waardevoller dan veel van de dashboards die erop gebouwd worden. Dashboards komen en gaan, de definitie van omzet, klant, marge, voorraad, bezetting of churn zou veel stabieler moeten zijn. Als die betekenis netjes wordt beheerd, kunnen steeds meer toepassingen daarop aansluiten. Vandaag Power BI, morgen een Copilot, overmorgen een agent die automatisch afwijkingen onderzoekt of acties voorstelt.

We zijn terug bij het Universe, maar toch ook niet

Er zit iets ironisch in deze ontwikkeling. Na twintig jaar innovatie komen we gedeeltelijk terug bij een idee dat BusinessObjects al heel lang geleden had:

Zet een semantische laag tussen de technische data en degene die er iets mee wil doen.

Maar we zijn niet simpelweg terug bij af. De eerste generatie semantic layers was vooral bedoeld om mensen gemakkelijker rapportages te laten bouwen. De nieuwe generatie moet bruikbaar zijn voor mensen én machines.

En dat stelt andere eisen.

De semantic layer moet beter beschreven zijn, programmeerbaar zijn, via gestandaardiseerde interfaces beschikbaar zijn en voldoende governance bevatten om automatische systemen ermee te laten werken. Dat is wezenlijk iets anders.

Begin dus niet bij de chatbot

Veel organisaties die met AI en data willen experimenteren, beginnen logischerwijs bij de zichtbare technologie. Welke LLM gaan we gebruiken? Microsoft Copilot? ChatGPT? Claude? Een eigen agent? Welke vector database? Hebben we MCP nodig?

Als het doel is om betrouwbare antwoorden over de eigen bedrijfsvoering te krijgen, zou ik eerst een andere vraag stellen:

Waar hebben we eigenlijk vastgelegd wat onze data betekent?

Waar staat de officiële omzetdefinitie? Welke klantindeling is leidend? Waar ligt de logica voor brutomarge? Zijn die definities alleen bekend bij een paar ervaren developers? Staan ze verspreid over SQL, Power BI, Qlik en Excel? Of bestaan ze daadwerkelijk als herbruikbare, beheerde businesslogica?

Als het antwoord onduidelijk is, heb je nog niet in de eerste plaats een AI-probleem. Je hebt een semantic-layerprobleem. AI maakt dat probleem alleen ineens heel zichtbaar.

De semantic layer wordt bedrijfsinfrastructuur

Dashboards verdwijnen niet. Voor veel vormen van informatieoverdracht blijft een vooraf ontworpen visualisatie simpelweg beter dan een chatvenster. Maar het dashboard wordt steeds minder het enige eindstation van onze data-architectuur. Dezelfde businesscontext kan straks worden gebruikt door rapportages, applicaties en AI-agents.

Daarmee verandert de semantic layer van een onderdeel van de BI-stack naar een stuk bedrijfsinfrastructuur. Een plek waar we niet alleen vastleggen waar de data staat, maar vooral wat de data betekent. En zodra machines die betekenis rechtstreeks gaan gebruiken, krijgt het semantic model een heel nieuwe rol: het wordt de API waarmee AI jouw organisatie leert begrijpen.

Is jullie datafundament klaar voor AI?

AI-ready worden begint niet bij het kiezen van een taalmodel. Het begint bij betrouwbare data, duidelijke definities en goed beheerde businesslogica.

Wil je weten of jullie huidige data-architectuur, semantic models en governance daar klaar voor zijn? Met onze AI Readiness Assessment brengen we in kaart waar de belangrijkste hiaten zitten en welke stappen nodig zijn om AI betrouwbaar met bedrijfsdata te laten werken.

Barry Harmsen

Barry is oprichter van Bitmetric. Hij werkt al meer dan twintig jaar in data & analytics, in rollen die variëren van hands-on ontwikkeling tot architectuur en strategie. Hij houdt van oplossingen die passen bij de context van de organisatie en die mensen ook echt gebruiken. Lang geleden schreef hij QlikView for Developers.

Buiten zijn werk besteedt Barry zijn tijd aan zijn gezin, roeien, klussen en hobbyprojecten waar zijn gezin in wisselende mate enthousiast over is.

The post Je semantische laag wordt de API voor AI appeared first on Bitmetric.

Maar de vraag leeft veel breder. Wij horen hem steeds vaker:

We draaien op Qlik, maar eigenlijk zijn we een Microsoft-organisatie. Moeten we niet gewoon overstappen naar Power BI?

Het antwoord is niet simpel ja of nee. Qlik en Power BI zijn beide volwassen analyticsplatformen. Je stapt dus niet automatisch over naar iets nieuwers of beters. Je kiest een platform dat beter bij je organisatie, mensen en bredere architectuur past. Of je concludeert dat Qlik nog steeds de beste keuze is.

Eén ding is wel duidelijk: dit is geen export-importtraject. Organisaties die Qlik willen vervangen door Power BI staan daarom meestal voor meer dan alleen een BI-migratie. Er bestaat geen officiële oplossing van Microsoft of Qlik waarmee je een complete Qlik-app rechtstreeks omzet naar een productieklare Power BI-oplossing. Microsoft heeft wel een algemene aanpak voor Power BI-migraties gepubliceerd, maar die is niet specifiek gericht op Qlik.

Dit artikel behandelt wanneer overstappen zinvol is, wat er fundamenteel verandert en hoe je het aanpakt. Ook bespreken we wanneer je beter bij Qlik kunt blijven.

Overweeg je bij Qlik te blijven maar wil je naar de cloud? Lees dan onze Qlik Cloud migratiegids.

Wil je eerst bepalen hoe goed jullie zijn voorbereid op een overstap naar Power BI of Microsoft Fabric? Gebruik dan onze Qlik naar Power BI Migration Readiness Checklist met 85 concrete checkpunten.

Kort samengevat
Overstappen van Qlik naar Power BI of Microsoft Fabric kan een logische keuze zijn, vooral als je organisatie sterk op Microsoft is ingericht. Maar het is een herbouw, geen verhuizing. Qlik-apps, loadscripts en datamodellen worden niet automatisch omgezet. Bedrijfslogica en KPI-definities kun je hergebruiken, maar ze moeten opnieuw worden geïmplementeerd. Bepaal bovendien eerst of je alleen de rapportagelaag wilt vervangen of ook de onderliggende data-architectuur. Power BI en Microsoft Fabric zijn namelijk niet hetzelfde.

De meeste problemen bij dit soort trajecten ontstaan niet doordat een platform tekortschiet, maar doordat de omvang van de herbouw wordt onderschat: verborgen afhankelijkheden, logica die zich niet één-op-één laat vertalen, of een parallelrun die te kort wordt gehouden. Dit artikel loopt die risico’s systematisch langs, met een assessmentkader (Retain, Rebuild, Retire) en een gefaseerde aanpak, zodat je vooraf weet waar de complexiteit zit in plaats van dat achteraf te ontdekken.

Weinig tijd? Ga direct naar:
– Wanneer overstappen naar Power BI wel of niet logisch is
– De zes fasen van een Qlik naar Power BI migratie
– Veelvoorkomende fouten bij een Qlik naar Power BI migratie

Inhoudsopgave

• Overweeg je een overstap? Begin met deze drie vragen

• Wanneer is overstappen naar Power BI of Fabric de juiste keuze?

• Heb je alleen Power BI nodig, of ook Microsoft Fabric?

• Wat verandert er fundamenteel?

• Wat kun je meenemen, en wat niet?

• De migratieaanpak in de praktijk

• Veelgemaakte fouten bij een migratie van Qlik naar Power BI

• Veelgestelde vragen

Overweeg je een overstap? Begin met deze drie vragen

Of je nu QlikView of Qlik Sense naar Power BI wilt migreren, dezelfde hoofdvraag blijft gelden: wat neem je mee, wat bouw je opnieuw en wat kun je beter uitfaseren? Voordat je licenties vergelijkt of een projectplanning maakt, moet je drie vragen beantwoorden:

1. Welke Qlik-apps en QVD’s worden werkelijk gebruikt?
   
   
2. Wil je alleen Qlik als rapportagetool vervangen, of ook de onderliggende data-laag vernieuwen?
   
   
3. Welke functionaliteit en manier van analyseren mogen bij de overstap niet verloren gaan?
   
   

De antwoorden bepalen of je alleen Power BI nodig hebt, Microsoft Fabric moet onderzoeken of beter bij Qlik kunt blijven.

Is de platformkeuze onderdeel van een bredere verandering van je dataomgeving? Dan helpt een datastrategie om eerst de gewenste situatie en het transitiepad te bepalen.

Wanneer is overstappen naar Power BI of Fabric de juiste keuze?

Overstappen is vooral het onderzoeken waard als je organisatie sterk op Microsoft is ingericht en de huidige Qlik-omgeving steeds meer als een afzonderlijk platform wordt ervaren.

Signalen dat een overstap logisch kan zijn:

• Je IT-omgeving draait grotendeels op Azure, Microsoft 365 en Entra ID.
• Je informatiebehoefte bestaat vooral uit gestandaardiseerde rapportages, gestuurde analyses en selfservice boven beheerde datamodellen.
• Power BI is al beschikbaar binnen je Microsoft-licenties.
• Het gebruik van Qlik is afgenomen nadat interne Qlik-specialisten zijn vertrokken.
• Je wilt het aantal afzonderlijke platformen en leveranciers verminderen.
• De kosten en beheerinspanning van Qlik wegen niet meer op tegen het werkelijke gebruik.
• Je wilt analytics nauwer integreren met andere Microsoft-diensten.

Dat Power BI al binnen een bestaande licentie beschikbaar is, kan de businesscase aantrekkelijker maken. De licentie alleen mag nooit de doorslag geven. Het opnieuw bouwen, testen en invoeren van een analyticsomgeving kost meestal aanzienlijk meer dan het verschil in gebruikerslicenties.

De vraag “welk platform is technisch beter?” is zelden de belangrijkste. Beide platformen kunnen goede dashboards, rapportages en datamodellen opleveren.

De relevantere vraag is:

Welk platform past het beste bij de mensen, processen en architectuur van onze organisatie?

Twijfel je welk platform bij jouw organisatie past? Lees dan hoe wij helpen bij BI-toolselectie.

Wanneer is overstappen niet de juiste keuze?

Er zijn ook situaties waarin Qlik bewust de betere keuze kan blijven.

Het associatieve model is essentieel voor de gebruikers

Qlik is sterk in omgevingen waarin gebruikers vrij door grote, samengestelde datasets navigeren. Selecties en uitgesloten waarden zijn direct zichtbaar. Gebruikers kunnen verbanden volgen zonder dat ieder analysepad vooraf in een rapport is ingericht.

Power BI ondersteunt eveneens interactieve analyse en selfservice. Het werkt alleen vanuit een explicieter ontworpen semantisch model en rapportstructuur. Analytische vragen die in Qlik vanzelf ontstaan vanuit associaties, vragen in Power BI soms om extra modellering, measures of een andere interactiewijze.

Als deze vrije exploratie centraal staat in het dagelijkse gebruik, kun je bij een overstap iets wezenlijks verliezen.

Je wilt alleen moderniseren omdat Power BI nieuwer zou zijn

Qlik Sense en Power BI behoren tot dezelfde generatie analyticsplatformen. Een overstap tussen deze twee is op rapportageniveau vooral een horizontale beweging.

Kom je nog van QlikView, dan kan een overstap wel onderdeel zijn van een bredere modernisering. Maar ook dan heb je meerdere opties. Je kunt naar Qlik Cloud, naar Power BI of naar een bredere Microsoft Fabric-architectuur.

De modernisering zit niet automatisch in het logo op het dashboard. Die zit onder meer in:

• De data-architectuur;
• Automatisering en deployment;
• Governance;
• Beheerbaarheid;
• Integratie met andere platformen;
• Beschikbaarheid van kennis;
• Gebruik en adoptie.

Qlik past aantoonbaar beter bij je gebruikers

Als Qlik breed wordt gebruikt, intern goed wordt beheerd en aantoonbaar waarde oplevert, is “wij zijn nu eenmaal een Microsoft-organisatie” op zichzelf geen goede reden om te migreren.

Eén ecosysteem is overzichtelijk. Maar standaardisatie die functionaliteit, productiviteit of gebruikersacceptatie verslechtert, is geen vooruitgang.

Je wilt problemen met data of dashboards oplossen met een migratie

“Mijn data klopt niet” en “ik vind mijn dashboards niet mooi” zijn begrijpelijke klachten, maar op zichzelf geen goede redenen om Qlik te vervangen.

Onbetrouwbare cijfers ontstaan meestal door problemen met databronnen, definities, transformaties, het datamodel of de manier waarop resultaten worden gevalideerd. Een ander BI-platform lost die problemen niet automatisch op. Tijdens een migratie kunnen ze zelfs groter worden, omdat bestaande logica opnieuw moet worden geïnterpreteerd en gebouwd.

Hetzelfde geldt voor de vormgeving van dashboards. Goede rapportages vragen om duidelijke ontwerpprincipes, consistente standaarden en ontwikkelaars die begrijpen hoe gebruikers informatie verwerken. Zonder die kennis wordt een dashboard in Power BI niet vanzelf beter dan een dashboard in Qlik.

Onderzoek daarom eerst waar het probleem werkelijk zit. Stap pas over wanneer het platform zelf aantoonbaar in de weg zit. Twijfel je of het platform werkelijk het probleem is? Met een second opinion voor data & analytics kun je je bestaande omgeving of migratievoorstel onafhankelijk laten beoordelen.

Je organisatie kan de herbouw nu niet goed uitvoeren

Een overstap vraagt meer dan Power BI-licenties en een paar developers. Je hebt tijd nodig voor inventarisatie, architectuurkeuzes, herbouw, testen en adoptie.

Als de organisatie daar op dit moment onvoldoende capaciteit, eigenaarschap of budget voor heeft, kan uitstel verstandiger zijn dan een half uitgevoerde migratie.

Dat betekent niet dat je voor altijd bij Qlik moet blijven. Het betekent dat de randvoorwaarden eerst op orde moeten zijn.

Als je besluit bij Qlik te blijven, lees dan onze Qlik Support & Beheer gids over het proactief beheren van een Qlik-omgeving. Wil je het beheer structureel ondersteunen of deels uitbesteden, bekijk dan onze Qlik Support-dienst.

Heb je alleen Power BI nodig, of ook Microsoft Fabric?

Power BI en Microsoft Fabric worden vaak in één adem genoemd, maar ze zijn niet hetzelfde.

Power BI richt zich op semantische modellen, rapportage, visualisatie en analyse. Microsoft Fabric is een breder analyticsplatform waarin onder meer data-integratie, data-engineering, datawarehousing, real-time analytics, data science en Power BI samenkomen.

Power BI is binnen Fabric één van de workloads.

Dat onderscheid is belangrijk voor de scope van je migratie. 

Wanneer Power BI zonder een nieuwe Fabric-data-laag kan volstaan

Power BI kan een bewuste eindbestemming zijn als:

• Je al een goed functionerend datawarehouse of dataplatform hebt;
• Databronnen via bestaande, beheerde modellen beschikbaar zijn;
• Je vooral de Qlik-rapportagelaag wilt vervangen;
• Je geen nieuwe data-engineeringomgeving nodig hebt;
• Bestaande ETL-processen kunnen blijven functioneren;
• Je Power BI vooral inzet voor semantische modellen, dashboards en rapportages.

Je hoeft dus niet automatisch je hele data-architectuur naar Fabric te verplaatsen omdat je Power BI gaat gebruiken.

Wanneer Microsoft Fabric relevant wordt

Fabric is het onderzoeken waard als je behalve de rapportages ook andere onderdelen wilt vernieuwen:

• Opslag en ontsluiting van data;
• ETL- en ELT-processen;
• Pipelines en orkestratie;
• Datawarehousing of een Lakehouse;
• Data science;
• Real-time analytics;
• Centrale governance over meerdere analyticsworkloads.

Als Fabric onderdeel wordt van de doelarchitectuur, richt onze Microsoft Fabric consultancy zich meestal op het ontwerpen en realiseren van die bredere data-architectuur.

Een Fabric Lakehouse kan bijvoorbeeld een vergelijkbare rol vervullen als een gecureerde QVD-laag. Maar het is niet de enige mogelijke bestemming.

Je kunt ook:

• Een bestaand datawarehouse behouden;
• Azure SQL of een ander clouddatawarehouse gebruiken;
• Bestaande ETL-processen blijven inzetten;
• Een extern data-integratieplatform gebruiken;
• Alleen de rapportagelaag vervangen.

De juiste vraag is daarom niet alleen:

Hebben we Power BI of Fabric nodig?

De betere vraag is:

Welke onderdelen van onze huidige analyticsarchitectuur willen we vervangen?

Pas als dat duidelijk is, kun je een passende doelarchitectuur kiezen.

Houd bij Fabric rekening met gedeelde capaciteit

Fabric-capaciteit is geen maandelijkse bundel die op een bepaald moment ineens op is. Verschillende workloads gebruiken Capacity Units. Microsoft verdeelt piekgebruik over de tijd.

Bij aanhoudende overbelasting kan wel throttling optreden. Bewerkingen kunnen dan worden vertraagd, in een wachtrij terechtkomen of uiteindelijk worden afgewezen.

Breng daarom vooraf in kaart:

• Welke workloads dezelfde capaciteit delen;
• Wanneer piekbelasting optreedt;
• Hoe vaak modellen en pipelines draaien;
• Hoeveel gelijktijdige gebruikers je verwacht;
• Welke processen bedrijfskritisch zijn;
• Welke groei je de komende jaren verwacht.

Kijk niet alleen naar de capaciteit die je bij de start nodig hebt. Richt ook monitoring en periodieke optimalisatie in.

Wat verandert er fundamenteel?

De grootste verandering is conceptueel. Qlik en Power BI laten gebruikers op een andere manier met data werken.

Een andere manier van analyseren

Qliks associatieve engine maakt relaties tussen gegevens direct onderdeel van de gebruikerservaring. Na een selectie zie je welke waarden bij de selectie horen en welke waarden juist zijn uitgesloten.

Gebruikers kunnen daardoor verbanden volgen die niet per se als vast navigatiepad in een rapport zijn ontworpen.

Power BI ondersteunt eveneens interactieve rapportage, drillthrough, filtering en selfservice. Het vertrekpunt is alleen anders. De analyse wordt sterker gestuurd door:

• Het semantische model;
• Expliciet gedefinieerde relaties;
• Measures en berekeningslogica;
• De inrichting van rapportpagina’s;
• Aangeboden filters en interacties.

Een vraag die in Qlik direct vanuit associaties kan worden onderzocht, vraagt in Power BI mogelijk extra modellering of een specifieke measure.

Dat maakt Power BI niet minder krachtig. Het betekent wel dat je bestaande Qlik-apps niet klakkeloos moet natekenen. Je moet opnieuw beoordelen hoe gebruikers hun vragen in het nieuwe platform het beste kunnen beantwoorden.

Datamodel

Qlik-datamodellen kun je niet rechtstreeks exporteren naar Power BI. Tabellen, relaties, berekeningen en selectielogica moeten opnieuw worden beoordeeld.

Beide platformen kunnen goed werken met een sterschema. Het verschil zit vooral in de manier waarop relaties, filters en berekeningen door de engine worden verwerkt.

In Power BI zijn relaties en filterrichtingen expliciet onderdeel van het model. Berekeningen worden doorgaans ingericht met DAX. Daarbij spelen filtercontext en rijcontext een belangrijke rol.

Qlik-expressies en Set Analysis kun je inhoudelijk als uitgangspunt gebruiken, maar ze moeten opnieuw worden ontworpen en geïmplementeerd.

In deel 2 van onze vergelijkingsserie over Power BI en Qlik gaan we technisch dieper in op de verschillen in datamodellering.

Scripting en datatransformatie

Qlik loadscript wordt niet overgenomen door Power BI of Fabric.

Afhankelijk van de doelarchitectuur komt de transformatielogica terecht in bijvoorbeeld:

• Power Query;
• Dataflows;
• Fabric Data Factory;
• Notebooks;
• Een datawarehouse;
• Een extern data-integratieplatform.

Mensen met sterke Qlik-scriptkennis herkennen de logica van transformaties meestal snel. De syntaxis, uitvoering en ontwerpprincipes zijn echter anders.

Reken dus niet op een directe één-op-één-overdracht van kennis. Plan tijd in voor opleiding, begeleiding en review.

Beveiliging

Section Access en Row-Level Security hebben een vergelijkbaar doel: gebruikers alleen de gegevens laten zien waarvoor zij bevoegd zijn.

De implementatie verschilt echter.

In Power BI wordt RLS ingericht met rollen en filters in het semantische model. Daarnaast kunnen workspace-rollen, Object-Level Security en beveiliging in de databron een rol spelen.

De bestaande gebruikersgroepen en beveiligingsregels kunnen als input dienen. De technische structuur moet opnieuw worden ontworpen en getest.

Probeer Section Access niet letterlijk na te bouwen. Begin vanuit de beveiligingsmogelijkheden en beheerstructuur van het nieuwe platform.

Performance en gebruikerservaring

Het is te eenvoudig om te zeggen dat Qlik of Power BI altijd sneller is.

De ervaren performance hangt onder meer af van:

• Het datamodel;
• De hoeveelheid data;
• De opslagmodus;
• DAX- of Qlik-berekeningen;
• Caching;
• Capaciteit;
• Databronnen;
• Netwerk;
• Rapportontwerp;
• Het aantal gelijktijdige gebruikers.

Qlik kan bij exploratief gebruik directer aanvoelen, vooral als gebruikers veel selecties maken en voortdurend associaties onderzoeken.

Power BI kan zeer snel werken met een goed ontworpen semantisch model en passende capaciteit. Slecht ontworpen DAX, onnodig complexe visuals of verkeerde opslagkeuzes kunnen de ervaring echter sterk verslechteren.

Test daarom niet alleen technische refreshes. Laat echte gebruikers representatieve analyses uitvoeren in een proof of concept.

Voor meer over de praktische verschillen in eindgebruikerservaring kun je deel 4 van onze vergelijkingsserie over Qlik en Power BI lezen.

Wat kun je meenemen, en wat niet?

Een migratie begint niet volledig vanaf nul. De bestaande omgeving bevat veel waardevolle kennis. Alleen de technische implementatie is meestal niet overdraagbaar.

Wat je kunt hergebruiken

Databronnen

Dezelfde ERP-systemen, databases, API’s en bestanden kunnen vaak opnieuw worden aangesloten.

Controleer wel of bestaande connectoren, gateways en authenticatiemethoden opnieuw moeten worden ingericht.

Business rules en KPI-definities

Definities van omzet, marge, actieve klanten of voorraadwaarde blijven waardevol. Ze moeten alleen opnieuw worden geïmplementeerd en gevalideerd.

Kennis uit de QVD-laag

De QVD-bestanden zelf worden niet automatisch onderdeel van de nieuwe architectuur, maar ze laten wel zien:

• Welke gegevens worden gebruikt;
• Hoe tabellen worden gecombineerd;
• Welke transformaties nodig zijn;
• Waar historie wordt opgebouwd;
• Welke datasets door meerdere applicaties worden gedeeld.

Beveiligingsregels

Section Access kan dienen als functionele specificatie voor het nieuwe autorisatiemodel.

Dashboardontwerp en gebruikerswensen

De bestaande dashboards laten zien welke informatie gebruikers nodig hebben. Gebruik ze als bron, niet als verplicht visueel ontwerp.

Wat opnieuw moet worden gebouwd

Qlik-apps

Qlik-apps worden niet geïmporteerd als Power BI-rapport. Rapporten, modellen en berekeningen moeten opnieuw worden gebouwd.

Qlik-loadscripts

De logica kan worden hertaald, maar de syntaxis en technische uitvoering zijn niet compatibel.

Set Analysis en expressies

De bedoeling van de berekening kan worden behouden. De implementatie moet opnieuw worden ontworpen in DAX of in de data-laag.

Extensies

Qlik-extensies werken niet in Power BI. Onderzoek of een standaardvisual, een gecertificeerde custom visual of een ander rapportontwerp hetzelfde doel kan bereiken.

Section Access

De beveiligingsregels moeten opnieuw worden geïmplementeerd als RLS, OLS of een combinatie van platform- en databronbeveiliging.

NPrinting-rapportages

NPrinting-rapporten worden niet automatisch omgezet. Je moet opnieuw bepalen hoe geplande PDF-, Excel- en andere rapporten worden samengesteld en verspreid.

Daarvoor kun je bijvoorbeeld Power BI-abonnementen, paginated reports, Mail & Deploy of een andere rapportagedienst gebruiken. Gebruik je Mail & Deploy al naast Qlik, dan kun je onderzoeken of je deze distributielaag kunt behouden en voortaan op Power BI kunt aansluiten.

Voor een vergelijking van de front-end en ontwikkelervaring kun je deel 3 van onze vergelijkingsserie over Qlik en Power BI lezen.

De complexiteit zit vaak in de QVD-laag

Bij veel organisaties zit een groot deel van de bedrijfslogica niet in de dashboards, maar in de QVD-laag eronder. Denk aan historische opbouw, incrementele laadprocessen, transformaties en afhankelijkheden tussen applicaties.

Een omvangrijke QVD-architectuur is geen reden om bij Qlik te blijven. Het betekent wel dat je bij een overstap meer vervangt dan alleen de rapportagelaag.

Breng daarom vroeg in kaart:

• Welke QVD’s werkelijk worden gebruikt;
• Welke bedrijfslogica behouden moet blijven;
• Welke afhankelijkheden tussen applicaties bestaan;
• Welke onderdelen kunnen worden vereenvoudigd;
• Welke logica beter naar een centrale data-laag kan;
• Welke doelarchitectuur de organisatie daarna wil beheren.

De QVD-bestanden zelf worden niet automatisch onderdeel van de nieuwe omgeving. Ze zijn wel een belangrijke bron om te begrijpen hoe data wordt opgebouwd, gecombineerd en hergebruikt.

Een Lakehouse met Delta- of Parquet-bestanden kan binnen Fabric een vergelijkbare rol vervullen als een gecureerde QVD-laag. Maar een Lakehouse is niet automatisch de juiste bestemming.

Je kunt ook een bestaand datawarehouse behouden, Azure SQL gebruiken of voor een ander data-integratieplatform kiezen.

De migratie is daarmee ook een kans om jarenlange technische schuld, dubbele logica en ongebruikte tussenlagen op te ruimen.

Praktijkvoorbeeld: bij Nature’s Pride bouwden we met TimeXtender een centrale datalaag als fundament voor de overstap van Qlik naar Power BI. Zo konden databronnen en bedrijfslogica centraal worden ingericht, in plaats van deze per Power BI-model opnieuw op te bouwen. Lees de klantcase.

De migratieaanpak in de praktijk

Er is geen standaard migratiepad. Elke migratie van Qlik naar Power BI of Fabric is maatwerk en begint met een grondige assessment. Wie die stap overslaat, ontdekt vaak pas tijdens de uitvoering hoeveel complexiteit er werkelijk in de omgeving zit.

Fase 1: Assessment

Begin met een volledige inventarisatie van de huidige omgeving:

• Qlik-apps;
• QVD’s;
• Databronnen;
• Reloadtaken;
• Afhankelijkheden;
• Section Access;
• Extensies;
• Macro’s en document triggers;
• Externe scripts en applicatiekoppelingen;
• NPrinting-rapporten;
• Gebruikersgroepen;
• Werkelijke gebruikscijfers;
• Beheerprocessen.

De lijst met applicaties is niet genoeg. Je moet weten wie ze gebruikt, welke beslissingen ermee worden genomen en welke onderdelen daadwerkelijk waarde opleveren.

Wil je deze inventarisatie systematisch aanpakken? Gebruik dan onze Qlik naar Power BI Migration Readiness Checklist om zichtbaar te maken welke onderdelen al zijn onderzocht en waar nog open punten zitten.

Gebruik vervolgens het 3-R-kader.

Retain

De app blijft in Qlik. De herbouwinspanning weegt niet op tegen de waarde, of Qlik blijft voor deze toepassing bewust de betere oplossing.

Rebuild

De functionaliteit blijft nodig en wordt opnieuw gebouwd in Power BI. Daarbij hoef je de bestaande app niet letterlijk te kopiëren. De structuur, gebruikerservaring, berekeningen en scope kunnen worden aangepast aan het nieuwe platform.

Dit is ook het moment om overbodige tabbladen, dubbele logica, historische uitzonderingen en ongebruikte functies te verwijderen.

Retire

De app wordt gearchiveerd en niet vervangen, bijvoorbeeld omdat hij nauwelijks wordt gebruikt of omdat de informatie inmiddels elders beschikbaar is.

In onze ervaring wordt juist deze inventarisatie vaak onderschat. Pas bij een grondige analyse worden verborgen afhankelijkheden, uitzonderingen en complexe beveiligingsregels zichtbaar.

Fase 2: Doelarchitectuur

Bepaal vervolgens welke onderdelen je vervangt:

• Alleen de rapportages;
• Rapportages en semantische modellen;
• Ook de data-integratie;
• Ook opslag en orkestratie;
• De volledige analyticsarchitectuur.

Beantwoord daarna vragen zoals:

• Kan de bestaande data-laag blijven bestaan?
• Is een datawarehouse of Lakehouse nodig?
• Welke logica hoort in de data-laag en welke in Power BI?
• Kies je voor Power BI Pro, Premium Per User of Fabric-capaciteit?
• Welke workloads delen straks dezelfde Fabric-capaciteit?
• Hoe worden ontwikkeling, test, acceptatie en productie ingericht?
• Hoe worden deployment en versiebeheer geregeld?

Voer bij een grotere omgeving eerst een proof of concept uit. Kies daarvoor geen eenvoudig dashboard, maar een representatieve applicatie met relevante datavolumes, berekeningen en beveiliging.

Bij de uitwerking van de doelarchitectuur is zowel Power BI– als Microsoft Fabric-expertise nodig wanneer je ook de onderliggende datalaag vernieuwt.

Fase 3: Data-laag en databronnen

Sluit de databronnen opnieuw aan en bouw de gekozen data-architectuur.

Gebruik de bestaande QVD-logica als functionele bron, maar beoordeel iedere transformatie opnieuw. Niet alles wat historisch in het Qlik-loadscript is terechtgekomen, hoort automatisch in de nieuwe oplossing.

Bij een gefaseerde migratie hoeft de bestaande Qlik-data-laag niet direct te verdwijnen. Qlik Sense kan tabellen naast QVD ook als Parquet opslaan. Bestaande QVD-generatoren kunnen daardoor tijdelijk zowel QVD’s voor de Qlik-apps als Parquet-bestanden voor de nieuwe Microsoft-omgeving produceren.

Die Parquet-bestanden kunnen bijvoorbeeld in Azure Blob Storage of Azure Data Lake Storage worden geplaatst en van daaruit door Fabric worden ontsloten. Zo kun je de rapportagelaag stapsgewijs herbouwen, zonder de volledige transformatielogica aan het begin van het traject al te vervangen.

Test onder meer:

• Aantallen en totalen;
• Historische gegevens;
• Incrementele verwerking;
• Uitzonderingen;
• Sleutelvelden;
• Datakwaliteit;
• Refreshduur;
• Foutafhandeling;
• Lineage en documentatie.

Rond deze basis af voordat je grote aantallen rapporten gaat bouwen. Anders herstel je dezelfde dataproblemen straks in meerdere Power BI-modellen.

Fase 4: Semantische modellen en rapportages

Begin met de meest gebruikte en meest waardevolle Qlik-applicaties.

Bouw niet automatisch ieder sheet en ieder object na. Onderzoek per rapport:

• Welke vragen gebruikers werkelijk beantwoorden;
• Welke KPI’s essentieel zijn;
• Welke analyses nauwelijks worden gebruikt;
• Welke Qlik-interacties anders moeten worden opgelost;
• Welke informatie in één centraal semantisch model kan worden ondergebracht.

Dit is ook het moment waarop ervaren Power BI consultants kunnen helpen om semantische modellen, measures en rapportages opnieuw goed op te zetten, in plaats van bestaande Qlik-applicaties één-op-één na te bouwen.

Gebruik de migratie om de rapportage te vereenvoudigen. Een nieuw platform met dezelfde historische rommel is geen verbetering.

Fase 5: Governance en beveiliging

Richt workspaces, rollen en eigenaarschap in voordat de omgeving breed wordt uitgerold.

Leg vast:

• Wie modellen mag publiceren;
• Wie rapporten mag wijzigen;
• Hoe RLS en andere beveiliging worden beheerd;
• Wie verantwoordelijk is voor datakwaliteit;
• Hoe wijzigingen worden getest;
• Hoe capaciteit en refreshes worden gemonitord;
• Welke rapporten gecertificeerd of gepromoveerd zijn;
• Hoe gebruikers toegang aanvragen.

Governance is niet alleen een technische inrichting. Het is ook een set afspraken over eigenaarschap en besluitvorming.

Fase 6: Test en go-live

Laat Qlik en Power BI tijdelijk naast elkaar draaien.

Vergelijk niet alleen totalen, maar ook:

• Selecties en filters;
• Uitzonderingssituaties;
• Beveiliging;
• Exports;
• Detailniveaus;
• Refreshmomenten;
• Gebruik op verschillende apparaten;
• Performance tijdens piekuren.

Voer een gebruikersacceptatietest uit per afdeling of gebruikersgroep. Ga daarna gefaseerd live.

Twee tot vier weken parallel draaien kan een bruikbaar uitgangspunt zijn, maar de juiste periode hangt af van de frequentie en het belang van de rapportage.

Voor een dagelijks operationeel dashboard kan een kortere periode voldoende zijn. Voor maand- of kwartaalrapportages moet je minimaal een volledige rapportagecyclus kunnen vergelijken.

Veelgemaakte fouten bij een migratie van Qlik naar Power BI

De grootste fouten bij een migratie van Qlik naar Power BI ontstaan meestal niet door één verkeerde technische keuze. Ze ontstaan doordat de omvang van de herbouw, de verschillen tussen de platformen en de impact op gebruikers worden onderschat.

1. Onderschatten dat het een herbouw is

Organisaties plannen de doorlooptijd en het budget van een migratie, maar staan in werkelijkheid voor een herbouw. Qlik-apps, loadscripts, datamodellen, berekeningen en beveiligingsregels worden niet automatisch overgezet.

Daarbij worden verborgen afhankelijkheden gemakkelijk gemist. Denk aan QVD-ketens, macro’s, document triggers, extensies, externe scripts, API-koppelingen, NPrinting en Excel-bestanden die onderdeel zijn geworden van het proces.

Wie vooraf onvoldoende inventariseert, ontdekt de werkelijke complexiteit vaak pas tijdens de uitvoering.

2. Qlik-kennis verwarren met Power BI-kennis

Een goede Qlik-developer begrijpt data, modellering en bedrijfslogica. Die kennis blijft waardevol bij een overstap.

Maar DAX, Power Query, Power BI-modellering en Microsoft Fabric vragen ook om eigen expertise. Houd daarom rekening met opleiding, begeleiding en review door ervaren Microsoft-specialisten.

Het omgekeerde geldt eveneens. Een Power BI-specialist zonder Qlik-kennis kan de bedoeling van Set Analysis, associaties, QVD-laadpatronen en andere Qlik-specifieke constructies verkeerd interpreteren.

Je hebt in een migratieteam daarom kennis van beide kanten nodig. Juist de combinatie van Qlik- en Microsoft-ervaring voorkomt dat bestaande oplossingen verkeerd worden vertaald naar het nieuwe platform.

3. Microsoft Fabric inzetten zonder duidelijke scope en architectuur

Microsoft Fabric is een breder dataplatform dan Power BI. Niet iedere migratie naar Power BI vraagt daarom automatisch om Fabric.

Bepaal vooraf welke onderdelen je werkelijk nodig hebt. Denk aan data-integratie, opslag in OneLake, pipelines, lakehouses, notebooks en realtime verwerking. Maak ook een bewuste keuze tussen bijvoorbeeld pipelines, Dataflows Gen2, shortcuts en mirroring.

Neem daarbij het verwachte capaciteitsgebruik mee. Verschillende Fabric-workloads delen dezelfde capaciteit en kunnen elkaar beïnvloeden. Zonder duidelijke scope en capaciteitsinschatting voeg je kosten en complexiteit toe zonder dat daar voldoende waarde tegenover staat.

4. Section Access één-op-één willen vertalen

Row-Level Security in Power BI heeft ongeveer hetzelfde doel als Section Access in Qlik, maar werkt anders.

Exact dezelfde tabellen, velden en beveiligingsstructuur nabouwen leidt vaak tot een onnodig complexe oplossing. Gebruik de bestaande beveiligingsregels als functionele bron, maar ontwerp het beveiligingsmodel opnieuw vanuit de Power BI-architectuur.

5. Alle apps willen meenemen

Niet iedere Qlik-app hoeft opnieuw te worden gebouwd. Sommige apps worden nauwelijks gebruikt, bevatten grotendeels dezelfde informatie als andere apps of ondersteunen een proces dat inmiddels is veranderd.

Gebruik de assessment daarom ook als opruimmoment. Bepaal per app of deze behouden, herbouwd of uitgefaseerd moet worden. Iedere app die je verantwoord kunt beëindigen, bespaart direct ontwikkel-, test- en beheertijd.

6. De parallelrun te kort houden

Tijdens een parallelrun kunnen gebruikers resultaten vergelijken, afwijkingen melden en wennen aan de nieuwe werkwijze. Die periode moet lang genoeg zijn om ook minder frequente processen te testen, zoals maandafsluitingen en periodieke rapportages.

Hoe lang de parallelrun moet duren, verschilt per omgeving en businessproces. Ga niet uit van één vaste termijn voor de hele organisatie. Werk liever gefaseerd per afdeling of rapportagedomein.

7. Change management als nazorg behandelen

Power BI werkt anders dan Qlik. Gebruikers krijgen te maken met andere filtermogelijkheden, navigatiepatronen en manieren om data te onderzoeken. Een technisch correct rapport wordt niet vanzelf goed gebruikt.

Betrek key users daarom al bij het ontwerp en de acceptatietest. Communiceer tijdig wat er verandert en bied begeleiding bij de overstap. Change management hoort vanaf het begin bij het migratieproject, niet pas na de livegang.

8. Bestaande bedrijfslogica klakkeloos overnemen

Niet iedere historische berekening, uitzondering of KPI-definitie is nog correct of nodig. Sommige regels zijn ooit toegevoegd voor een tijdelijk probleem en daarna nooit meer verwijderd. Andere definities worden inmiddels door verschillende afdelingen anders geïnterpreteerd.

Gebruik de migratie daarom om bedrijfslogica opnieuw met de business te valideren. Leg definities en uitzonderingen vast en bepaal bewust wat moet worden overgenomen, aangepast of verwijderd. Anders bouw je oude fouten en onduidelijkheden opnieuw op het nieuwe platform.

9. Beheer en governance pas na de livegang inrichten

Een nieuwe Power BI- of Fabric-omgeving heeft vanaf het begin duidelijke beheerafspraken nodig. Denk aan werkruimtes, rechten, deployment, naamgeving, eigenaarschap, monitoring, support en het publiceren van datasets en rapporten.

Wanneer je dit pas na de livegang regelt, ontstaat al snel wildgroei. Rapporten worden gekopieerd, definities gaan uiteenlopen en het wordt onduidelijk wie verantwoordelijk is voor beheer en datakwaliteit.

Ontwerp daarom niet alleen de technische oplossing, maar ook de manier waarop deze na de migratie wordt beheerd en verder ontwikkeld.

Voor structurele ondersteuning na de livegang bieden we Power BI Support en Microsoft Fabric Support.

Veelgestelde vragen

Conclusie

Overstappen van Qlik naar Power BI of Microsoft Fabric kan voor veel organisaties een goede keuze zijn. Vooral wanneer het Microsoft-ecosysteem al de standaard is en Qlik steeds meer als een afzonderlijk platform wordt ervaren.

Maar de overstap is geen gewone verhuizing. Datamodellen, transformaties, beveiliging en rapportages moeten opnieuw worden beoordeeld en voor een belangrijk deel opnieuw worden gebouwd.

De sleutel is daarom niet zo snel mogelijk beginnen met bouwen. Begin met een eerlijke inventarisatie van wat je hebt, wat nog wordt gebruikt en wat je werkelijk wilt vervangen.

Soms is de uitkomst Power BI op de bestaande data-laag. Soms is een bredere Fabric-architectuur logisch. En soms blijkt Qlik voor een deel van de omgeving nog steeds de betere keuze.

Houd daarbij rekening met vertraging. Migraties duren in de praktijk vaak langer dan vooraf wordt gedacht. Plan voldoende ruimte in en behoud waar mogelijk contractuele flexibiliteit totdat de nieuwe omgeving daadwerkelijk is gevalideerd en in gebruik is.

Bitmetric heeft diepe Qlik-roots en werkt dagelijks met Power BI, Microsoft Fabric en bredere data-architecturen. Daardoor kunnen we niet alleen helpen bij de inrichting van het nieuwe platform, maar ook beoordelen wat er in de bestaande Qlik-omgeving behouden, herbouwd of uitgefaseerd moet worden.

Wil je eerst zelf in kaart brengen waar jullie staan? Gebruik dan onze Qlik naar Power BI Migration Readiness Checklist en beoordeel jullie migratie aan de hand van 85 concrete checkpunten.

Wil je weten welke route bij jouw omgeving past? Plan een gesprek in.

Wil je eerst meer weten over de verschillen tussen de platformen? Lees dan deel 1 van onze vergelijkingsserie over Qlik en Power BI. Blijf je bij Qlik, maar overweeg je een overstap naar de cloud? Lees dan onze Qlik Cloud-migratiegids.

Barry Harmsen

Barry is oprichter van Bitmetric. Hij werkt al meer dan twintig jaar in data & analytics, in rollen die variëren van hands-on ontwikkeling tot architectuur en strategie. Hij houdt van oplossingen die passen bij de context van de organisatie en die mensen ook echt gebruiken. Barry was jarenlang Qlik Luminary en Qlik Partner Ambassador. Lang geleden schreef hij QlikView for Developers.

Buiten zijn werk besteedt Barry zijn tijd aan zijn gezin, roeien, klussen en hobbyprojecten waar zijn gezin in wisselende mate enthousiast over is.

The post Qlik naar Power BI of Microsoft Fabric migreren: de complete gids (2026) appeared first on Bitmetric.

Maybe someone mentioned it during a Power BI discussion.
Maybe it came up in a meeting about modern data platforms.
Or maybe you saw it and thought, “Another Microsoft product I will need to learn at some point.”

Microsoft Fabric is not just another tool.

It is Microsoft’s attempt to bring data engineering, data integration, analytics, and business intelligence into one unified platform. And that shift matters more than it might seem at first.

Because many organizations are still dealing with a very fragmented data landscape:

• Different tools for ingestion.
• Different tools for transformation.
• Different tools for storage.
• Different tools for reporting.

Every extra layer creates more complexity, more governance challenges, and more time spent moving data instead of actually using it. Microsoft Fabric is designed to simplify that.

What Microsoft Fabric actually is

Microsoft Fabric is a unified analytics platform that runs entirely as a SaaS service. Instead of stitching together separate tools, Fabric provides one environment where different data workloads can run on the same foundation.

At the center of that foundation is OneLake, Microsoft’s single logical data lake for the entire organization. This means different teams can work on the same data without constantly copying, exporting, or rebuilding pipelines between tools.

Data engineers, analysts, and BI developers can all work within the same platform. That shared environment is what makes Fabric different from many traditional data architectures.

The main Fabric components you should know

Fabric covers a lot of capabilities, but beginners only need to understand a few core pieces.

Data Engineering

Data Engineering in Fabric focuses on preparing and transforming data.

You work with lakehouses, notebooks, Spark environments, and pipelines to ingest and transform data before it is used for analytics. The lakehouse architecture combines the flexibility of a data lake with the structure of a data warehouse.

Data Science

Fabric also includes environments for machine learning and experimentation.

Data scientists can explore data, train models, and deploy insights directly inside the same platform where the data already lives. This removes the need to constantly move datasets between different tools.

Business Intelligence

This is where many users first interact with Fabric.

Power BI is deeply integrated into the platform, allowing analysts to build dashboards and semantic models directly on top of Fabric data. For many Power BI teams, Fabric feels familiar, but with a stronger data foundation underneath.

Real Time Intelligence

Some organizations need to analyze data the moment it arrives.

Fabric includes tools for streaming data and event driven scenarios, allowing teams to work with high velocity data and respond to changes in near real time.

Why Microsoft Fabric matters

The biggest reason Fabric matters is not because it introduces completely new technology. It matters because it tries to simplify the modern data stack.

Over the past decade many companies adopted separate tools for every part of the data lifecycle:

• A tool for ingestion.
• A tool for storage.
• A tool for transformation.
• A tool for analytics.

This approach can work, but it often creates complicated architectures and a lot of duplicated data. Fabric’s goal is to reduce that fragmentation by bringing those capabilities closer together.

Instead of moving data across multiple platforms, teams can build pipelines, models, and dashboards on top of the same data foundation. That can significantly simplify governance, collaboration, and data management.

How to start learning Fabric

One mistake many beginners make is trying to understand every Fabric capability at once. That is not necessary. A better approach is to start with the part that connects to the work you already do.

If you mainly work with dashboards and analytics, begin with → Power BI and Business Intelligence experience.

If you build pipelines and transformation logic, explore → Data Engineering workloads first.

If you work with machine learning or experimentation, focus on → Data Science capabilities.

Once you understand one part of the platform, the rest becomes easier to explore.

The bigger picture

Microsoft Fabric reflects a broader shift in the data world. Organizations are moving away from disconnected analytics tools and toward platforms where data engineering, analytics, and AI can work together more naturally.

That does not mean every company will move everything into Fabric overnight. But it does mean understanding Fabric is becoming increasingly valuable for data professionals.

Because the companies building their next generation data platforms are looking for ways to simplify their architecture, reduce duplication, and make data easier to use across teams. And that is exactly the problem Fabric is trying to solve.

Credit where credit is due → Shubham Rai

Mireille Erasmus

Mireille is a Marketing Manager at Bitmetric. Creative, energetic, and people-loving, she’s all about turning ideas into content that connects. Outside work, you’ll find her with friends, walking her dog, or exploring local markets.

More from the Bitmetric team

Bitmetric Qlik Support

Keep your Qlik environment running smoothly with proactive support that prevents issues before they appear. Available on flexible monthly plans. Learn more.

Qlik vs Power BI Series

See how Qlik and Power BI perform when theory meets reality. Three apps rebuilt, every step examined. Learn more.

The post A Beginner’s Guide to Microsoft Fabric appeared first on Bitmetric.