Qlik naar Power BI of Microsoft Fabric migreren: de complete gids (2026)

Per 1 december 2025 schakelde AFAS Software de Qlik-integratie in zijn platform uit. Veel Nederlandse organisaties kwamen daardoor voor een platformkeuze te staan.

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. 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.

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

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.

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.

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.

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.

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 Engelstalige vergelijkingsserie 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 Engelstalige vergelijkingsserie 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 Engelstalige vergelijkingsserie 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.

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.

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.

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.

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 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 Engelstalige vergelijkingsserie over Qlik en Power BI. Blijf je bij Qlik, maar overweeg je een overstap naar de cloud? Lees dan onze Qlik Cloud-migratiegids.