Qlik Sense naar Power BI: zo stap je over

Van Qlik Sense of QlikView naar Power BI overstappen is een herbouw, geen conversie. Er bestaat geen tool die een Qlik-app omzet naar een werkend Power BI-rapport. Je neemt de databronnen, de kpi-definities en de gebruikerswensen mee, en bouwt het datamodel, de berekeningen en de beveiliging opnieuw op. De overstap loopt in zes stappen: inventariseren, doelarchitectuur kiezen, de datalaag bouwen, model en rapporten herbouwen, beveiliging en beheer inrichten, en een periode parallel draaien.

Dat klinkt als meer werk dan de meeste organisaties hadden ingeschat, en dat is het meestal ook. De gangbare verwachting is dat je de schermen uit Qlik naloopt en ze in Power BI opnieuw neerzet. In de praktijk zijn de schermen het makkelijkste deel. Het werk zit in wat eronder ligt: jaren aan loadscripts, tussenbestanden en uitzonderingen die ooit iemand heeft ingebouwd en nergens heeft opgeschreven.

Daar zit ook de kans. Een overstap dwingt je om elke definitie nog eens vast te pakken, en dat is precies het fundament dat in veel Qlik-omgevingen nooit expliciet is gelegd. Wie die stap overslaat en alleen de schermen kopieert, heeft straks een nieuwe tool met dezelfde onduidelijkheden. Niet het nieuwe dashboard maakt het verschil, maar het model dat eronder ligt.

Hieronder staat daarom eerst waarom organisaties overstappen en wat er echt verandert, dan wat je meeneemt en wat je opnieuw bouwt, en daarna het stappenplan, de kosten en de valkuilen.

Waarom stappen organisaties over van Qlik naar Power BI?

Drie redenen komen steeds terug, en ze hebben weinig met de kwaliteit van Qlik te maken.

• De rest van de organisatie draait al op Microsoft. Wie Microsoft 365 en Azure gebruikt, beheert Qlik als een los eiland met eigen servers, eigen accounts en eigen kennis. Power BI gebruikt dezelfde accounts en groepen als de rest van je omgeving.
• AFAS is gestopt met Qlik. Per 1 december 2025 levert AFAS Power BI als enige BI-oplossing. Wie de ingebouwde Qlik-dashboards gebruikte, moest dus hoe dan ook verder met iets anders. Hoe de koppeling met Profit nu loopt, staat in ons artikel over de AFAS Power BI-koppeling.
• Kennis is makkelijker te vinden. Er zijn op de arbeidsmarkt meer mensen met Power BI-ervaring dan met Qlik-ervaring. Vertrekt de enige collega die de Qlik-scripts begreep, dan staat er ineens een systeem dat niemand meer durft aan te raken.

Draai je nog op QlikView, dan ligt de vraag er al langer. QlikView is het oudere product van Qlik en draait op een eigen server, Qlik Sense is de opvolger. Wie een QlikView-dashboard wil moderniseren, heeft drie opties: overschakelen naar Qlik Sense, naar Qlik Cloud of naar Power BI. Alle drie vragen om een herbouw, dus de vraag is niet welke route het minste werk is, maar welke het beste past bij de rest van je omgeving.

Qlik vs Power BI: wat er echt verandert

Het grootste verschil zit niet in de grafieken, maar in hoe gebruikers met data werken.

Qlik werkt met een associatieve engine. Klik je op een klant, dan zie je direct welke producten, regio’s en periodes daarbij horen en welke juist niet. Gebruikers volgen zo verbanden die niemand vooraf als navigatiepad heeft ingericht.

Power BI werkt vanuit een semantisch datamodel: een ontworpen laag waarin tabellen, relaties en berekeningen vastliggen. Wat het semantisch model precies is, staat in de begrippenlijst. Analyseren kan in Power BI net zo goed, alleen langs de wegen die het model aanbiedt. Een vraag die in Qlik vanzelf ontstond, vraagt in Power BI soms een extra measure of een andere pagina.

Daarnaast veranderen er vier dingen die gebruikers direct merken:

• Het scherm ziet er rustiger uit. Qlik-apps zijn vaak volle schermen met veel tabellen en grafieken tegelijk. Een goed Power BI-rapport toont per pagina een paar visuals rond één vraag.
• Filters werken anders. Geen groene, witte en grijze waarden meer, maar slicers en filters die op de pagina of het hele rapport werken. Dat is wennen voor wie jarenlang op die kleuren stuurde.
• Gebruikers kunnen meer zelf. In Qlik kijken de meeste gebruikers alleen. In Power BI kunnen ze met de juiste rechten zelf rapporten bouwen op een gedeeld model, exporteren of doorklikken naar detail. Dat is winst, en het vraagt om duidelijke afspraken over wat mag.
• Het licentiemodel is anders. Power BI rekent per gebruiker, en voor wie al Microsoft 365 E5 heeft zit Power BI Pro er al in. Daarover meer bij de kosten.

Wat neem je mee en wat bouw je opnieuw?

Je begint niet vanaf nul. De bestaande omgeving bevat veel kennis, alleen niet in een vorm die Power BI kan lezen. Onderstaande tabel laat per onderdeel zien waar het in Power BI terechtkomt.

Onderdelen van een Qlik-omgeving en hun tegenhanger in Power BI

In Qlik	In Power BI	Meenemen of opnieuw bouwen
Qlik-app	Semantisch model plus een of meer rapporten	Opnieuw bouwen, de app dient als specificatie
Loadscript	Power Query, een dataflow of een datawarehouse	Logica meenemen, code opnieuw schrijven
QVD-bestanden	Tabellen in een datawarehouse of lakehouse	Gebruiken als bron om te begrijpen wat er gebeurt
Set Analysis en expressies	DAX-measures	Bedoeling meenemen, formule opnieuw schrijven
Master items	Measures en kolommen in het gedeelde model	Definities meenemen
Section Access	Rijniveaubeveiliging en werkruimterollen	Regels meenemen, inrichting opnieuw
NPrinting	Abonnementen en gepagineerde rapporten	Opnieuw inrichten
Extensies	Standaardvisuals of gecertificeerde custom visuals	Opnieuw kiezen

Het patroon is steeds hetzelfde: de bedoeling gaat mee, de techniek niet. Dat is het duidelijkst bij de berekeningen. Set Analysis-expressies worden DAX-formules, en dat is een vertaling, geen omzetting. Een omzet over 2025, ongeacht welk jaar de gebruiker heeft geselecteerd, ziet er in beide talen zo uit:

Qlik:      Sum({<Jaar={2025}>} Omzet)
Power BI:  CALCULATE ( SUM ( Verkoop[Omzet] ), Kalender[Jaar] = 2025 )

Twee regels, hetzelfde antwoord. Maar een Qlik-app heeft er al snel tientallen van, met geneste uitzonderingen die alleen de oorspronkelijke bouwer kon uitleggen. Elke vertaalde formule test je daarom tegen de bron, niet alleen tegen de oude Qlik-uitkomst. Waarom dat verschil ertoe doet, staat verderop.

Van Qlik naar Power BI in zes stappen

Er bestaat geen standaardpad, maar er is wel een volgorde die de meeste verrassingen naar voren haalt. Microsoft beschrijft een algemene aanpak voor Power BI-migraties, die niet specifiek over Qlik gaat. De zes stappen hieronder zijn die aanpak, toegespitst op wat er in een Qlik-omgeving zit.

1. Inventariseer wat er is, en wat er gebruikt wordt. Breng alle apps, QVD-bestanden, reloadtaken, Section Access-regels, NPrinting-rapporten en extensies in kaart. Zet er de gebruikscijfers naast. Deel daarna elke app in: behouden, herbouwen of uitfaseren. In bijna elke omgeving staan apps die al maanden niemand heeft geopend.
2. Kies de doelarchitectuur. Vervang je alleen de rapportagelaag op een bestaande database, of ook de laag eronder? Zit de logica nu in Qlik-scripts en QVD’s, dan heb je een plek nodig waar die logica straks woont. Dat kan Power Query zijn voor een kleine omgeving, of een datawarehouse of Fabric-lakehouse als meerdere rapporten dezelfde tabellen delen.
3. Bouw eerst de datalaag en leg definities vast. Leg in een kort datamigratieplan per tabel vast welke bron, welke historie en welke afwijking acceptabel is. Rond deze laag af voordat je rapporten gaat bouwen, anders repareer je hetzelfde dataprobleem straks in vijf modellen. Qlik Sense kan tabellen ook als Parquet wegschrijven, volgens de documentatie van het Store-statement. Daarmee kan een bestaand script tijdelijk zowel Qlik als de nieuwe omgeving voeden, zodat je niet alles in één keer hoeft om te zetten.
4. Herbouw model en rapporten per domein. Begin met één representatieve app als proef: niet de simpelste, maar een met echte datavolumes, lastige berekeningen en beveiliging. Daarna domein voor domein: finance, sales, operatie. Bouw per domein één gedeeld model in plaats van een model per rapport.
5. Richt beveiliging en beheer in voor de uitrol. Leg vast wie modellen mag publiceren, wie rapporten mag wijzigen, wie eigenaar is van welke werkruimte en hoe gebruikers toegang aanvragen. Section Access wordt rijniveaubeveiliging en werkruimterollen. Gebruik de bestaande regels als specificatie, niet als bouwtekening.
6. Draai parallel en zet Qlik daarna pas uit. Laat beide systemen naast elkaar draaien tot minimaal één volledige maandafsluiting is vergeleken, inclusief de rapporten die maar eens per maand of per kwartaal gedraaid worden. Ga per afdeling live, niet voor de hele organisatie tegelijk. En kondig geen uitzetdatum aan voordat de vergelijking klopt, zeker niet als het Qlik-contract dan nog verlengd moet worden.

Bij stap 4 ligt de grootste verleiding: de oude schermen precies natekenen. Gebruikers vragen erom, want dat kennen ze. Maar Power BI filtert anders, toont anders en heeft andere sterke punten.

De vraag per scherm is niet hoe het eruitzag, maar welke beslissing ermee genomen werd. Wie een vol Qlik Sense-dashboard pixel voor pixel naar Power BI kopieert, heeft na drie maanden werk precies wat hij al had, alleen in een ander lettertype.

Waarom de cijfers in Power BI anders uitkomen dan in Qlik

Vroeg of laat gebeurt het in de parallelle periode. Qlik zegt bijvoorbeeld dat de omzet van september € 1.284.000 was, Power BI zegt € 1.279.500. Binnen een dag gaat het overleg niet meer over wat die omzet betekent, maar over welk systeem gelijk heeft. Precies de discussie die een nieuw rapport had moeten beëindigen.

Het eerste wat je dan moet weten: Qlik is niet de waarheid. Het oude getal is ook een uitkomst van definities, en die zijn soms jaren geleden gekozen.

De vraag is dus niet welk systeem gelijk heeft, maar welk getal klopt met de bron. Vergelijk daarom allebei met de administratie zelf, het grootboek of het ERP, en niet alleen met elkaar. De gebruikelijke oorzaken van een verschil:

• Logica in het loadscript die niemand kende. Creditnota’s die werden weggefilterd, intercompany-boekingen die eruit gingen, een vaste correctie op één klant. Dat soort regels staat in een script, niet in een definitie, en verdwijnt dus stilletjes bij de herbouw.
• Weeknummers. DAX telt standaard de week met 1 januari als week 1. De Europese ISO-telling, waarin de week met de eerste donderdag week 1 is, krijg je pas als je de functie het type 21 meegeeft. Dat staat in de documentatie van WEEKNUM, en in sommige jaren verschuift daardoor een hele week omzet.
• Regels zonder bijpassende sleutel. Een verkoopregel met een klantnummer dat niet in de klantentabel staat, toont Power BI als een aparte regel met een lege klant. Dat oogt als een fout in het nieuwe rapport, maar het is een fout in de bron die in Qlik niet opviel.
• Standaardselecties en verborgen filters. Een Qlik-app die opende met het lopende jaar geselecteerd, of een filter op rapportniveau in Power BI dat niemand ziet.

Elk verschil dat je zo uitzoekt, leg je vast als definitie. Dan heb je na de overstap niet alleen een nieuwe tool, maar ook één afgesproken getal. Hoe je zulke afwijkingen structureel in de bron oplost in plaats van in het rapport, staat in ons artikel over datakwaliteit.

Wat kost een overstap van Qlik naar Power BI?

De licentie is het kleinste deel van de rekening. Power BI Pro kost € 12,10 per gebruiker per maand, exclusief btw en bij een jaarcontract, en zit al in Microsoft 365 E5. Voor een organisatie met vijfentwintig gebruikers is dat € 3.630 per jaar. Wat er verder bij komt en wanneer een capaciteit goedkoper wordt, staat in ons artikel over Power BI licenties en kosten.

Het grootste deel zit in het werk. Vier posten bepalen de omvang:

• Het aantal apps dat echt mee moet. Niet het aantal apps op de server, maar het aantal dat na de inventarisatie op herbouwen staat.
• De logica in de loadscripts en QVD’s. Een app die rechtstreeks op een nette database draait, is snel herbouwd. Een app die op vier lagen QVD’s leunt, niet.
• Het afstemmen van de cijfers. Elk verschil uit de vorige sectie kost uitzoekwerk, en dat werk is zelden vooraf goed in te schatten.
• Training en begeleiding. Voor gebruikers, en voor de ontwikkelaars die van Qlik-script naar Power Query en DAX gaan.

Een prijs per dashboard is daarom een slecht vertrekpunt. Wat het bouwen van één Power BI-dashboard kost als de data al op orde is, staat in ons artikel over een Power BI dashboard laten maken. Bij een overstap komen daar de inventarisatie en de datalaag bij, en die bepalen of het een kwestie van weken of van maanden is.

Reken in de businesscase ook met wat je bespaart: de Qlik-licenties en de server, en elke app die je uitfaseert in plaats van herbouwt. Houd wel rekening met overlap. Tijdens de parallelle periode betaal je voor allebei.

Mensen, kennis en weerstand

Een technisch correct rapport wordt niet vanzelf gebruikt. Wie jarenlang in Qlik heeft gewerkt, weet precies waar hij moet klikken, en mist in Power BI eerst vooral wat er niet meer is. Dat is geen onwil, dat is gewoonte.

Drie dingen helpen. Betrek per afdeling een paar vaste gebruikers vanaf de inventarisatie, niet pas bij de acceptatietest. Zij weten welke schermen echt gebruikt worden en kunnen hun collega’s later uitleggen waarom iets anders werkt.

Laat ze ook zien wat er beter wordt, zoals zelf een overzicht samenstellen op het gedeelde model. En leg uit wat er bewust niet terugkomt, met de reden erbij.

Voor het ontwikkelteam geldt iets vergelijkbaars. Een goede Qlik-ontwikkelaar begrijpt data, modellen en bedrijfslogica, en die kennis blijft waardevol. Maar DAX en Power Query werken anders, en wie Qlik-script letterlijk naar Power Query vertaalt, krijgt een model dat traag en lastig te beheren is.

Het omgekeerde geldt ook: een Power BI-specialist die Set Analysis verkeerd leest, bouwt een measure die net iets anders rekent. Het beste werkt een team waarin beide kanten aan tafel zitten: de ontwikkelaars of QlikView-consultants die de apps destijds bouwden, naast iemand die Power BI goed kent. Betrek je huidige Qlik-partner dus bij de inventarisatie, ook als die de herbouw niet gaat doen.

Wanneer je beter (nog) niet overstapt

Er zijn situaties waarin wij een overstap afraden, of in elk geval niet nu.

• Je gebruikers leunen op de associatieve manier van zoeken. Analisten die vrij door grote datasets bladeren zonder vooraf ingericht pad, verliezen in Power BI iets wezenlijks. Blijf dan bij Qlik, of overweeg Qlik Cloud als je van de eigen server af wilt.
• Je wilt eigenlijk een dataprobleem oplossen. Kloppen de cijfers niet of zijn de dashboards onoverzichtelijk, dan ligt dat zelden aan de tool. Een overstap lost dat niet op en maakt het tijdens de herbouw vaak eerst erger. Los het probleem op waar het zit, en kies daarna pas een tool.
• Er is nu geen capaciteit. Een overstap vraagt tijd van de business voor inventarisatie, testen en afstemmen. Is die er niet, dan levert een half uitgevoerde migratie twee systemen op die allebei niet helemaal kloppen.
• Qlik wordt goed beheerd en volop gebruikt. Dat jullie verder een Microsoft-organisatie zijn, is op zichzelf geen reden. Eén leverancier is overzichtelijk, maar niet als het je gebruikers productiviteit kost.

In al die gevallen is het antwoord niet nooit, maar eerst iets anders. Onze aanpak begint daarom met de inventarisatie, en die kan ook uitkomen op blijven.

Is jullie Qlik-omgeving een set schermen die je opnieuw wilt tekenen, of een kans om eindelijk één set definities vast te leggen? Wil je weten welke apps bij jullie mee moeten en welke niet? Neem contact op, dan maken we samen de inventarisatie.

Veelgestelde vragen