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.

Dat is de reden waarom migreren naar Qlik Cloud op de agenda staat bij zoveel organisaties die ik spreek. Niet omdat de huidige omgeving kapot is (vaak draait die prima), maar omdat de productontwikkeling ergens anders plaatsvindt. Wie op QlikView of Qlik Sense Enterprise Client-Managed blijft zitten, mist Qlik Answers, Qlik Predict, Qlik Automate en de governance-verbeteringen van de afgelopen jaren.

Het probleem zit zelden in de techniek. Apps overzetten met de Qlik Analytics Migration Tool (QAMT) is relatief makkelijk. Waar het misgaat, zie ik telkens terug: organisaties onderschatten dat governance, licentiemodel en beheer na de migratie compleet anders werken. Dat kost achteraf meer tijd en budget dan vooraf was ingepland.

Deze gids laat zien wat een Qlik Cloud-migratie in de praktijk inhoudt: wat je meeneemt en wat niet, welke stappen je doorloopt, en wanneer het verstandig is om er iemand bij te halen. Of juist niet.

Kort samengevat: Qlik’s productinvesteringen gaan naar de cloud. On-premise omgevingen worden ondersteund, maar krijgen geen nieuwe features. Migreren is meer dan apps verplaatsen: governance, licentiemodel en beheer veranderen fundamenteel. De gratis Qlik Analytics Migration Tool (beschikbaar vanaf mei 2025, via Qlik) verlaagt de drempel, maar migreert niet alles. Goede voorbereiding begint met opruimen.

Inhoudsopgave

• Wanneer is migreren naar Qlik Cloud de juiste keuze?

• Wat breng je naar Qlik Cloud, en wat niet?

• De migratiestappen in de praktijk

• Wat verandert er in je omgeving

• De meest voorkomende fouten

• De eerste 90 dagen na go-live

• Doe je het zelf of schakel je een partner in?

• Veelgestelde vragen

Wanneer is migreren naar Qlik Cloud de juiste keuze?

Qlik Cloud is waar de product-investering naartoe gaat. Dat is de eerlijke reden om te migreren: niet omdat je huidige omgeving stuk is, maar omdat je anders achterblijft bij de feature-ontwikkeling.

De drie voornaamste drijfveren zijn:

Cloud-first roadmap

Nieuwe features verschijnen eerst, en soms uitsluitend, in Qlik Cloud. Denk aan Qlik Answers (generatieve AI), Qlik Predict, Qlik Automate, Data Lineage en geavanceerde samenwerkingsfuncties. On-premise omgevingen worden ondersteund, maar zijn niet de prioriteit van het productontwikkelingsteam.

Infrastructuurlasten

Voor groeiende omgevingen zijn de kosten van on-premise hardware, licenties en beheer soms hoger dan de overstap naar cloud. Dit is geen universele waarheid: kleinere, stabiele omgevingen hoeven niet per se goedkoper uit te zijn.

Schaalbaarheid

Qlik Cloud schaalt mee met gebruik. Piekbelasting vereist geen extra hardware meer.

Wanneer is het niet urgent?

Niet elke organisatie hoeft nú te migreren. Heb je een kleinere, stabiele omgeving met een sterk intern team en weinig behoefte aan nieuwe cloud-features? Dan is er geen brandende urgentie.

Ik zie te vaak dat partners en verkopers anders adviseren. Maar een migratie zonder concrete businesscase levert zelden het gewenste resultaat. “Het is nu eenmaal de richting” is geen businesscase.

Twijfel je of Qlik Cloud voor jouw organisatie werkelijk de juiste stap is, of wil je een bestaand migratievoorstel laten toetsen? Met een second opinion voor data & analytics krijg je een onafhankelijk oordeel over de gekozen koers, aannames en risico’s.

Als je nog op QlikView zit

Wie in 2026 nog op QlikView draait, heeft daar waarschijnlijk een reden voor. Misschien werkt de omgeving prima. Misschien is er nooit capaciteit geweest om te migreren. Beide zijn begrijpelijk.

Het is goed om te weten dat een QlikView-migratie anders is dan een Qlik Sense-migratie. Het is geen verhuizing: het is een herbouw. QlikView-apps zijn fundamenteel anders opgebouwd dan Qlik Sense-apps. Je kunt ze niet automatisch omzetten. Ze moeten opnieuw worden ontworpen, soms helemaal.

Wil je eerst weten hoe groot die opgave is? Qlik heeft de SaaS Readiness App: een QlikView-applicatie die tegen je omgeving aan wordt gedraaid en in enkele minuten profileert welke apps klaar zijn voor migratie, inclusief sessiegebruik en data lineage. Handig als startpunt voordat je aan de front-end-keuze toekomt.

Voor de data- en scriptlaag gebruik je QAMT: laadscript, variabelen en master items komen mee. Voor de front-end heb je een aparte tool nodig, de QlikView to Qlik Sense Converter, die sheets, visualisaties, layout en styling automatisch omzet. Beide tools werken vandaag nog los van elkaar: QAMT is pas in een toekomstige release gepland om de front-end-conversie te integreren, dus tot die tijd stem je de twee zelf op elkaar af. Doe je dat niet, dan bouw je de front-end handmatig opnieuw.

Handmatig herbouwen is overigens geen ramp. Na jaren QlikView is een herontwerp van de presentatielaag vaak geen slecht idee. Het nadeel is gebruikersacceptatie: mensen willen hun vertrouwde omgeving terugzien, en een compleet nieuwe interface voelt voor veel gebruikers als meer verandering dan ze hadden verwacht.

Wanneer Power BI de betere keuze is

Niet iedere organisatie is gebaat bij Qlik Cloud. Wij werken met beide platforms, dus onze voorkeur is die van jou: welk platform past het beste bij jouw situatie?

Leeft jouw organisatie primair in het Microsoft-ecosysteem? Al een Microsoft 365-licentie en geen complexe self-service data-exploratie nodig? Dan is Power BI waarschijnlijk goedkoper en logischer.

Signalen dat Power BI beter past: IT is volledig Microsoft-gedreven, dashboards zijn relatief statisch, en er is weinig behoefte aan ad-hoc analyses op grote of complexe datasets.

Herken je dit beeld, maar staat de keuze nog open? Met een onafhankelijke BI-toolselectie toetsen we Qlik Cloud, Power BI en eventueel Microsoft Fabric aan jullie eisen, gebruikers en bestaande architectuur.

Wat breng je mee naar Qlik Cloud, en wat niet?

De gratis Qlik Analytics Migration Tool (QAMT, beschikbaar vanaf mei 2025) verlaagt de technische drempel aanzienlijk. De tool migreert apps, gebruikers, streams, data connections en user content. Ze herstelt ook Lib-Connect-verwijzingen in laadscripts automatisch.

Maar QAMT migreert niet alles.

Wat QAMT niet doet

Drie categorieën vragen altijd handmatig werk:

Security Rules

On-premise security rules worden niet gemapt naar Qlik Cloud. Je moet ze handmatig opnieuw inrichten via spaces en rollen.

Task chains

Reload-ketens worden niet door QAMT gemigreerd. Je bouwt ze opnieuw in Qlik Cloud, waar je ze native kunt inrichten via de ingebouwde task chain-functionaliteit voor reloads.

Section Access

Section Access werkt in de cloud anders, en de migratie is handmatig. Er is ook een technisch detail dat vaak wordt gemist.

In Qlik Sense Enterprise Client-Managed gebruik je in Section Access de kolom USERID met een waarde zoals DOMEIN\gebruiker. In Qlik Cloud mapt USERID op het IdP-subject, en dat is vaak een hash of GUID, geen leesbare naam. Gebruik in cloud bij voorkeur de kolom USER.EMAIL. Dat is stabieler en begrijpelijker.

Wat er niet meekomt

Deze functies bestaan niet, of maar gedeeltelijk, in Qlik Cloud:

NPrinting

Qlik Cloud Reporting biedt gedeeltelijke vervanging: QAMT migreert Excel- en PixelPerfect-templates, maar de functionaliteit is niet volledig. Bovendien is het aantal rapporten standaard beperkt: je hebt waarschijnlijk een extra licentie nodig. In onze ervaring biedt Mail & Deploy verreweg de meest vergelijkbare ervaring met NPrinting in de cloud, als één-op-één vervanging.

ODBC/OLE-connectors

Geen custom Windows-connectors in cloud. Je hebt een Data Gateway nodig, of je verplaatst data naar cloud-opslag.

Offline toegang

Niet beschikbaar in Qlik Cloud.

Backup en rollback

Volledige versiegeschiedenis van apps is er nog niet. Een per ongeluk verwijderde app kun je wel terughalen: Qlik Cloud kent een soft-delete functie die verwijderde apps tot 14 dagen na verwijdering laat herstellen. Dat vangt “per ongeluk verwijderd” op, maar niet “ik wil terug naar de versie van vorige week.”

Twee veelgehoorde misverstanden

Extensies en dev/test/prod-scheiding staan vaak op het lijstje van “dat kan niet in de cloud.” Beide kloppen niet helemaal.

Extensies

Visualisatie-extensies draaien, net als on-premise, in de browser en blijven grotendeels werken, mits verwijzingen naar externe domeinen zijn toegestaan via de Content Security Policy. Extensies die de Qlik-engine via Server-Side Extensions (SSE) koppelen aan externe Python- of R-scripts, of aan andere custom services, werken niet: daarvoor bestaat in Qlik Cloud nog geen integratiepunt.

Dev/Test/Prod-scheiding

Bij het capacity-model zijn standaard 5 tenants inbegrepen, dus een aparte dev-, test- en productieomgeving is wel degelijk mogelijk zonder dat je hoeft te onderhandelen met Qlik Sales. Let op: alle tenants putten uit dezelfde capaciteit, dus een zware testomgeving gaat ten koste van je productieruimte. Een lichter alternatief is scheiding via Spaces binnen één tenant, zonder aparte tenants op te zetten.

In mijn ervaring is deze aanname zelf de meest onderschatte bron van vertraging: mensen gaan uit van de ergste versie (“dat kan toch niet in de cloud”) in plaats van het na te vragen. Extensies en dev/test/prod-scheiding zijn daar het duidelijkste voorbeeld van, maar inventariseer per onderdeel wat je hebt in plaats van aannames over te nemen.

De migratiestappen in de praktijk

Een Qlik Cloud-migratie doorloopt altijd dezelfde fases, ongeacht de omvang van de omgeving. De complexiteit verschilt, de structuur niet.

Stap 1: Assessment

Inventariseer alles voordat je begint. Apps, QVDs, data connections, extensies, gebruikers, licenties en beveiligingsregels. Gebruik daarvoor het 4-R-kader:

• Retain: de app gaat ongewijzigd mee
• Redesign: de app wordt grondig herbouwd voor cloud
• Refactor: de app wordt aangepast maar niet helemaal herschreven
• Retire: de app wordt gearchiveerd, niemand gebruikt hem meer

Dat laatste punt is belangrijker dan het lijkt. Ruim op voordat je migreert. Verouderde, dubbele en ongebruikte apps nemen migratietijd in beslag, vergroten de testlast en geven een vertekend beeld van de omvang. Schone omgevingen migreren sneller.

Stap 2: Plan en voorbereiding

Kies je identiteitsprovider (IdP). Qlik Cloud ondersteunt één interactieve IdP per tenant: OIDC of SAML. Dat is een fundamentele architectuurkeuze. Ga je via Azure AD, Okta, of een andere aanbieder? Die keuze raakt je Section Access-inrichting, je gebruikersprovisioning en je SSO-setup. Richt waar mogelijk SCIM in voor automatische provisioning: gebruikers die je toevoegt of verwijdert in je directory, zoals Azure Entra ID, verschijnen dan vanzelf in Qlik Cloud, zonder dat iemand eerst hoeft in te loggen.

Definieer ook je Spaces-structuur voordat je migreert. Streams in Qlik Sense worden Spaces in Qlik Cloud. Maar Spaces zijn meer dan een naamsverandering: ze bevatten ook data, connections en experimenten. De indeling die logisch was in Streams, is niet altijd de beste indeling in Spaces.

Plan je data connectivity vroeg. Er zijn drie opties:

1. Directe cloud-to-cloud verbinding (meest eenvoudig)
2. Data verplaatsen naar cloud-opslag zoals Azure Blob of Amazon S3
3. Qlik Data Gateway (voor on-premise databronnen die je niet wilt verplaatsen)

Is de Qlik Cloud-migratie onderdeel van een bredere vernieuwing van je dataomgeving? Dan kan een datastrategie helpen om de gewenste architectuur, prioriteiten en het transitiepad in samenhang uit te werken.

Stap 3: Migreren en testen

Gebruik QAMT voor apps, gebruikers en connections. Richt Security Rules, task chains en Section Access handmatig in. Test na elke batch, niet pas aan het einde.

Kies je aanpak bewust: big bang of gefaseerd per business unit. In mijn ervaring werkt gefaseerd beter. Je leert bij elke batch, je kunt bijsturen, en de organisatie heeft tijd om te wennen. Big bang geeft meer druk, hogere risico’s en minder ruimte voor correctie als er iets misgaat.

Hybrid mode: overgangsperiode, geen eindbestemming

Niet alle apps hoeven tegelijk te migreren. Qlik biedt normaliter een overgangstermijn waarin je on-premise en cloud naast elkaar laat draaien, zodat je gefaseerd kunt migreren zonder de hele organisatie in één keer om te zetten.

Zie dit niet als een permanente architectuurkeuze. Hybrid draaien raakt in toenemende mate uit de mode: Qlik’s productinvesteringen gaan naar de cloud, en on-premise blijft ondersteund maar niet doorontwikkeld. Een deel van je omgeving blijvend on-premise laten draaien omdat migreren op dat moment lastig is, stelt het onvermijdelijke alleen uit.

Wat wel verstandig is: apps met complexe architecturen die nog niet cloud-ready zijn, tijdelijk on-premise laten draaien terwijl de rest van de organisatie al migreert. App Distribution Service ondersteunt het synchroniseren van apps tussen omgevingen tijdens die overgangsperiode.

Wat verandert er in je omgeving?

De omgeving verandert na een migratie op drie assen: governance, licentiemodel en beheer. Wie dat onderschat, loopt er al snel tegenaan.

Governance: Spaces en rollen

Streams en security rules verdwijnen. In hun plaats komen Spaces en role-based access control. Dat is niet complexer, maar het is fundamenteel anders.

In Qlik Sense Enterprise Client-Managed regel je toegang via security rules, met condities op gebruikersattributen. In Qlik Cloud regel je toegang via Space-lidmaatschappen en rollen. De logica verschuift van “wie mag wat zien” op scriptniveau naar “wie is lid van welke Space met welke rol”.

Wie gewend is aan de flexibiliteit van security rules, moet opnieuw leren denken. De rechtenstructuur die jaren heeft gewerkt, werkt niet zomaar over in Qlik Cloud.

Licentiemodel: van named users naar capacity

Qlik Cloud werkt anders dan on-premise licenties. De overstap van named users naar capacity-based licenties heeft budgetimplicaties die organisaties bijna altijd verrassen.

Het model is niet per se duurder, maar de kosten liggen op andere plekken. Ze schalen ook anders mee. Laat de financiële impact doorrekenen vóór de contractonderhandeling, niet erna.

Beheer: infrastructuur weg, releases erbij

De infrastructuur verdwijnt. Geen servers, geen patches, geen back-ups op hardware-niveau. Dat is een opluchting voor veel IT-afdelingen.

Maar Qlik Cloud brengt iets nieuws: wekelijkse feature releases, elke dinsdag (Qlik, release cadence documentatie). In een on-premise omgeving bepaal je zelf wanneer je upgradet. In cloud gaat dat automatisch. Dat vraagt een structurele release-impact analyse: wat verandert er, wat raakt mijn extensies, API-integraties of workflows?

Beheer verdwijnt niet na de migratie. Het verschuift.

Data Gateway: twee smaken

Voor on-premise databronnen heb je een Qlik Data Gateway nodig. Er zijn twee soorten:

• Direct Access Gateway: real-time queries op on-premise data, draait op Windows
• Data Movement Gateway: verplaatst data naar cloud-opslag voor verwerking, draait op Linux

Welke je nodig hebt, hangt af van je architectuur en of je data wilt verplaatsen of ter plaatse wilt opvragen. Beide vragen planning, installatie en beheer. Ze worden structureel over het hoofd gezien in de voorfase.

De meest voorkomende fouten

De kostbaarste fouten bij een Qlik Cloud-migratie zijn niet technisch. Ze zijn organisatorisch.

NPrinting te laat betrekken

Qlik Cloud Reporting is geen volledige vervanging voor NPrinting: de functionaliteit is beperkt en het standaard aantal rapporten ook. Wie dat pas ontdekt ná de go-live, heeft een probleem dat niet snel is op te lossen. Inventariseer je NPrinting-gebruik in de assessment-fase. Opties: overstap naar Mail & Deploy (vergelijkbare ervaring in cloud), vereenvoudiging van rapporten, of NPrinting tijdelijk on-premise laten draaien.

Data Gateway niet vroegtijdig plannen

Een Gateway installeren lijkt eenvoudig. In de praktijk spelen firewall-regels, netwerksegmentatie en Windows-versies een rol. Plan dit vroeg en test het uitgebreid voordat de rest van de migratie ervan afhankelijk is.

Licentiemodel-impact niet doorrekenen

De overstap naar capacity-based licenties heeft financiële gevolgen. Wie dat pas merkt bij de eerste factuur, staat voor een onaangename verrassing die niet snel terug te draaien is.

Wijzigingen in de bestaande omgeving tijdens de migratiefase

Zodra je migreert, ‘freeze’ je de on-premise omgeving. Productie-aanpassingen die daarna nog plaatsvinden, moeten ook in cloud worden doorgevoerd. Dat kost meer werk dan het lijkt en leidt tot versieconflicten.

Geen gebruikersacceptatietest vóór go-live

Technisch werkt alles, maar gebruikers vinden hun apps niet terug, navigeren anders dan verwacht of missen permissies. Een UAT-ronde voorkomt support-calls in de eerste week na go-live.

De fout die ik het vaakst zie? Organisaties gaan live terwijl de gebruikers nog niet weten wat er veranderd is. Communicatie en training zijn geen nice-to-have. Ze zijn randvoorwaarde voor een succesvolle go-live.

De eerste 90 dagen na go-live

De meeste problemen bij een Qlik Cloud-migratie doen zich voor in de eerste 90 dagen. Niet omdat de migratie mislukt is, maar omdat de omgeving nog wordt ingeregeld en gebruikers nog wennen.

Monitoring

Worden apps gebruikt? Zijn er fouten in reload-taken? Wie doet een beroep op de Gateway? Bouw monitoring in voordat je live gaat, niet als je al live bent.

Governance bijstellen

Space-lidmaatschappen kloppen niet altijd in de eerste versie. Gebruikers melden te weinig of te veel toegang. Pas aan op basis van wat je ziet, niet op basis van wat je dacht dat goed was.

Release-impact analyse als structurele activiteit

Elke dinsdag is er een nieuwe Qlik Cloud-release. Maak er een vaste activiteit van: wat is er veranderd, raakt het onze extensies of API-integraties, is er actie nodig? Wie dit niet inregelt, ontdekt problemen pas als gebruikers erop melden.

Gebruikers onboarden

Niet iedereen past zich automatisch aan. Maak korte handleidingen, organiseer een Q&A-sessie, of wijs een intern aanspreekpunt aan. De navigatie in Qlik Cloud verschilt van Qlik Sense Enterprise Client-Managed. Voor sommige gebruikers voelt dat als een onverwachte drempel.

De eerste 90 dagen bepalen of een migratie als geslaagd wordt ervaren, ook als alles technisch correct is gegaan.

Doe je het zelf of schakel je een partner in?

Of je de migratie zelf kunt uitvoeren, hangt af van drie factoren: omvang, interne kennis en beschikbare capaciteit.

Wanneer zelf doen realistisch is

• Kleine omgeving (minder dan 20 apps)
• Ervaren intern Qlik-team met cloudervaring
• Eenvoudige architectuur: weinig extensies, geen NPrinting, geen complexe beveiligingsregels

Wanneer een partner noodzakelijk is:

• Grote app-portfolio of complexe architectuur
• NPrinting in gebruik
• Strakke deadline met weinig ruimte voor herstel
• Geen intern team of onvoldoende cloud-kennis
• Section Access met complexe logica
• Meerdere databronnen en Gateway-configuraties

Wat een goede Qlik-migratiepartner doet: niet alleen de technische migratie uitvoeren, maar ook kennis overdragen. Na de go-live moet jouw team de omgeving kunnen beheren. Een partner die dat niet meeneemt, bouwt afhankelijkheid, geen zelfstandigheid.

Veelgestelde vragen

Conclusie

Een Qlik Cloud-migratie is technisch haalbaar. De organisatorische kant is de eigenlijke uitdaging.

Qlik’s productinvesteringen gaan naar de cloud. Wie on-premise blijft, blijft ook achter bij nieuwe features. Maar dat betekent niet dat je morgen moet migreren. Bouw een businesscase, inventariseer eerlijk wat je hebt, en maak een plan dat past bij je organisatie. Niet bij het ideaalplaatje van een vendor.

De meest succesvolle migraties die ik heb begeleid, hadden drie dingen gemeen. Een grondig assessment vooraf. Een gefaseerde aanpak per business unit. En aandacht voor de gebruikers na go-live.

Wil je weten wat een migratie voor jouw specifieke omgeving betekent? Ik kijk 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. 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 Migreren naar Qlik Cloud: de complete gids (2026) appeared first on Bitmetric.

We gingen kijken. Wat we aantroffen was een omgeving zonder ook maar één regel documentatie. Tientallen apps, waarvan sommige vrijwel identieke kopieën waren met net kleine verschillen. Niemand wist meer waarom die er waren of welke de juiste was. Geen architectuurbeschrijving, geen versiebeheer. Jaar op jaar waren zaken rechtstreeks in productie aangepast, pleisters op pleisters, totdat de structuur die er misschien ooit was volledig verdwenen was. De omgeving draaide, maar het hing aan een zijden draadje.

Dit is het scenario dat veel organisaties vrezen maar zelden actief voorkomen: de afhankelijkheid van één persoon, en de kwetsbaarheid die pas zichtbaar wordt als die persoon weg is.

Ik zie dit patroon al bijna twintig jaar terugkomen in Qlik-omgevingen. In deze gids leg ik uit hoe goed Qlik-beheer eruitziet, wat er mis gaat zonder structureel onderhoud, hoe proactief werken verschilt van reactief fixen, en wanneer je beter een partner inschakelt dan het zelf probeert.

Kort samengevat: Qlik-omgevingen groeien vanzelf. Beheersbaarheid niet. Zonder structureel onderhoud groeit technische schuld stiller dan je denkt, totdat een vertrek, een migratie of een release het blootlegt. Proactief beheer houdt je omgeving bruikbaar en zorgt dat elke wijziging hanteerbaar blijft in plaats van steeds zwaarder wordt.

Inhoudsopgave

• Wat is Qlik support en beheer?

• Wat gaat er mis zonder beheer?

• Proactief vs reactief: het verschil in de praktijk

• Qlik Cloud vs on-premise: wat verandert er?

• Governance: hoe houd je grip als de omgeving groeit?

• Performance: waar zit de pijn echt?

• Wanneer schakel je een support partner in?

• Wat mag Qlik support kosten en wat levert het op?

• Veelgestelde vragen

Wat is Qlik support en beheer?

Qlik-beheer is meer dan een helpdesknummer bellen als er iets kapotgaat. Het omvat alles wat nodig is om een Qlik-omgeving gezond, beheersbaar en betrouwbaar te houden: monitoring van omgevingsgezondheid, app-onderhoud, governance, release-analyse, performance-reviews en gebruikersbeheer.

Dat is wezenlijk anders dan generieke IT-support. Een IT-generalist die een ticket afwerkt heeft niet de kennis om een stille fout in een incrementele laadroutine te diagnosticeren. Of om te beoordelen of een nieuwe Qlik Cloud feature release gevolgen heeft voor de custom extensies die je gebruikt, de visualisaties die zijn uitgefaseerd, of de API-integraties die op jouw omgeving leunen.

Het onderscheid dat ik altijd maak:

Reactief beheer: je lost problemen op nadat ze zichtbaar zijn geworden. Gebruikers melden dat een dashboard niet klopt. Je duikt erin, repareert het, en wacht op de volgende melding.

Proactief beheer: je monitort, analyseert en onderhoudt de omgeving structureel, zodat problemen zich niet voordoen, of in elk geval niet als complete verrassing.

Dat klinkt logisch. In de praktijk kiezen veel organisaties toch voor het eerste, simpelweg omdat het concreter voelt: je betaalt voor wat er kapot is, niet voor wat er niet kapotgaat. De ironie is dat reactief beheer structureel duurder uitpakt. Niet in de maandelijkse factuur, maar in de cumulatieve kosten van incidenten, hersteltijd en de technische schuld die zich stap voor stap opbouwt.

Wat gaat er mis als je Qlik-beheer verwaarloost?

Op basis van de omgevingen die we de afgelopen jaren binnenkwamen, zien we steeds dezelfde problemen terugkomen. Niet altijd alle zeven tegelijk, maar zelden minder dan drie.

1. (Incrementele) load die stilletjes faalt

Een QVD-laadroutine die elke nacht draait maar al weken geen verse data inleest. De foutmelding verdwijnt in een logbestand dat niemand leest. Gebruikers zien data van drie weken geleden als “actueel”. Dit is een van de gevaarlijkste problemen, omdat het onzichtbaar is totdat iemand de cijfers naast een andere bron legt.

Dit soort fouten is volledig te voorkomen met een eenvoudige monitoring-alert. Maar die alert moet dan wel iemand hebben ingesteld.

2. Kennis die weggaat met de mensen

De architect die de datamodellen heeft gebouwd is weg. Wat hij heeft neergezet werkt, maar waarom het zo is ingericht weet niemand meer. Geen documentatie, geen commentaar in de scripts, geen architectuurbeschrijving. Elke wijziging is nu een gok, want je weet niet wat je kunt aanraken zonder iets anders te breken.

Het voorbeeld uit de inleiding is hier het extreme geval. Maar een mildere versie herken ik in vrijwel elke nieuwe klantomgeving.

3. Hardcoded referentiedata

Productcategorieën, kostenplaatsen, regiocodes: hardcoded in het script, of ingeladen uit een Excel die door één collega werd bijgehouden. Die collega is weg. De Excel staat ergens op een gedeelde schijf. Of niet meer.

Dit klinkt triviaal totdat de organisatie een herstructurering doorvoert en de kostenplaatscodes veranderen. Dan kom je erachter dat dertien apps allemaal een eigen versie van die tabel bevatten.

4. Wildgroei van apps én sheets

Ik noem dit Qlik-sprawl, naar het bekende spreadsheet-sprawl: dezelfde ongecontroleerde wildgroei, nu in apps en sheets in plaats van Excel-bestanden. Het begint met apps: elke afdeling laat op enig moment een eigen rapport bouwen. Maar met de komst van self-service analytics gaat het verder: iedereen kan sheets aanmaken, visualisaties dupliceren, eigen versies opslaan. Dat is een voordeel van het platform. Alleen ruimt niemand ooit op.

Het gevolg is een omgeving vol overlappende apps en sheets, met net andere definities van dezelfde begrippen. “Omzet” in het financieel dashboard telt anders dan “omzet” in het salesdashboard. En niemand weet meer welke versie klopt, of welke sheets nog actief worden gebruikt.

5. Stille wijzigingen in de brondata

De databron verandert. Een veld krijgt een nieuwe waarde. Een tabel wordt hernoemd. Een nieuwe optie wordt toegevoegd aan een keuzelijst. Qlik geeft geen foutmelding: de data laadt gewoon, maar de uitkomst klopt niet meer.

Dit is verraderlijker dan een harde fout. Een harde fout valt op. Een stille afwijking kan weken of maanden onopgemerkt blijven, totdat iemand de cijfers naast een externe bron legt.

6. Ontbrekende documentatie

De omgeving draait. Maar waarom een specifiek datamodel er zo uitziet, welke keuzes zijn gemaakt bij de inrichting van spaces, wie waarom toegang heeft tot welke databron: dat staat nergens. Bij elke wijziging moet je het opnieuw uitzoeken, en je maakt fouten omdat je de context mist.

7. Governance-gaten: toegang en gebruikersbeheer

Wie heeft toegang tot welke data? Is dat nog correct na de laatste reorganisatie? Zijn er gebruikers met te ruime rechten? En, misschien nog urgenter: zijn er voormalige medewerkers die nog steeds actief zijn in de omgeving?

Gebruikersbeheer is een onderdeel van governance dat regelmatig vergeten wordt. Mensen die van rol wisselen, naar een andere afdeling gaan of het bedrijf verlaten worden niet altijd uit Qlik verwijderd. Dat is niet alleen inefficiënt, het is ook een compliance-risico.

Proactief vs. reactief: het verschil in de praktijk

Proactief Qlik-beheer bestaat uit een set concrete activiteiten die je structureel uitvoert, los van of er op dit moment iets kapot is. Het heeft een duidelijk ritme.

Ter illustratie: dit is hoe wij het bij Bitmetric aanpakken, gestructureerd per frequentie.

Continu en bij incidenten

Supportvragen behandelen, foutmeldingen in apps en reloads onderzoeken, databronnen en automatiseringen ondersteunen, platformproblemen escaleren naar Qlik Support indien nodig, en objecten herstellen vanuit back-up.

Wekelijks

Nieuwe apps, spaces, data connections, automatiseringen en taken signaleren. Wijzigingen in toegangsrechten en licenties beoordelen. Terugkerende reload- en automationfouten analyseren. Openstaande supportmeldingen reviewen.

Maandelijks

Gebruik en inrichting analyseren met de Qlik Analyzers: App Analyzer, Reload Analyzer, Data Connection Analyzer, Entitlement Analyzer. Controleren of apps voldoen aan tenantstandaarden. Inventariseren van ongebruikte apps, spaces, alerts, subscriptions, automatiseringen, data connections en taken. Rapportage van incidenten, bevindingen en verbeterpunten.

Per kwartaal

Extensions en themes beoordelen op gebruik en noodzaak. App- en sheetadoptie analyseren. Ongebruikte sheets signaleren. Reloadplanning en batch windows optimaliseren. QVD-performance beoordelen. Structurele bevindingen uit support bespreken en verbetervoorstellen prioriteren.

Jaarlijks

Tenantarchitectuur beoordelen. Schaalbaarheid evalueren in relatie tot gebruikers, apps en datavolume. Governance, rollen en verantwoordelijkheden reviewen. Licentie- en capaciteitsbehoefte opnieuw beoordelen. Disaster-recoveryplan actualiseren en herstelprocedure oefenen, inclusief een restoretest vanuit de Qlik Cloud-back-up.

Dit is wat proactief beheer concreet betekent. Geen vage beloftes over “proactief meedenken”, maar een gestructureerde aanpak met een ritme dat past bij de aard van het platform.

Qlik Cloud vs on-premise: wat verandert er bij beheer?

Een veelgehoorde aanname: Qlik Cloud is SaaS, dus de leverancier zorgt voor het beheer. Dat klopt deels. De infrastructuur is inderdaad Qlik’s verantwoordelijkheid: servers, beschikbaarheid, updates van de core software.

Maar het beheer van de omgeving is nog steeds jouw verantwoordelijkheid.

Bovendien is Qlik Cloud Analytics een aanzienlijk rijker platform dan Qlik Sense on-premise ooit was. Elke feature die je inzet vraagt ook om beheer. Qlik Automate brengt automatiseringen die kunnen falen en die je moet monitoren. Reporting brengt subscriptions en distributieschema’s die bijgehouden moeten worden. Qlik Predict brengt AutoML-deployments die een eigen levenscyclus hebben. En API-integraties en third-party connectoren komen er nog bij.

In mijn ervaring verschuift Qlik Cloud de beheerlast, maar verlaagt het hem niet. De infrastructuurverantwoordelijkheid verdwijnt. Daarvoor in de plaats komt een bredere functionele scope die actief beheerd moet worden.

Andere belangrijke verschillen:

Release-cadans

Qlik Cloud brengt wekelijks feature releases uit, doorgaans op dinsdag, naast doorlopende technische updates. Dat is significant vaker dan de halfjaarse releases van on-premise Qlik Sense. Elke release kan gevolgen hebben voor bestaande apps, visualisaties die zijn uitgefaseerd, of extensies die niet meer worden ondersteund. Proactieve release-impact analyse is daardoor geen luxe maar een structurele beheeractiviteit.

Data Gateway

On-premise stond de data dicht bij de Qlik-server. In Qlik Cloud heb je een Data Gateway nodig voor toegang tot on-premise databronnen. Die gateway heeft zijn eigen levenscyclus en vereist monitoring en onderhoud.

Backup en herstel

On-premise werd de Qlik-omgeving vaak gewoon meegenomen in de bestaande serverback-ups: bestandssysteem, QVD’s, de repository database. Qlik Cloud heeft sinds kort soft-delete voor apps: een verwijderde app is tot veertien dagen terug te halen. Voor configuratie en andere artefacten geldt dat niet, die zijn na verwijdering direct weg. Dat verschuift de verantwoordelijkheid voor een volwaardige back-up- en herstelstrategie grotendeels naar jou, of naar de partij die de omgeving voor je beheert.

Wil je dit proces niet zelf opzetten en onderhouden? Met onze Backup voor Qlik Cloud verzorgen we de dagelijkse back-ups, bewaartermijnen, controles en ondersteuning bij herstel.

Een goede backup bestaat bovendien uit meer dan alleen appbestanden. Denk ook aan configuratie, verbindingen, automations, rechten en andere metadata die nodig zijn om de omgeving te reconstrueren. Lees meer over wat er in een goede Qlik Cloud backup hoort.

Voor organisaties die de overstap naar Qlik Cloud overwegen: reken op een beheer-transitie, niet alleen op een technische migratie.

Overweeg je de overstap naar Qlik Cloud? Lees ook onze gids over Qlik Cloud migratie of bekijk onze Qlik Consultancy-dienst voor begeleiding tijdens het traject.

Governance: hoe houd je grip als de omgeving groeit?

Governance in Qlik gaat over wie wat mag zien, aanpassen en publiceren, wie verantwoordelijk is voor de kwaliteit van de data, en of dat allemaal geborgd is in de inrichting. In een omgeving met vijf gebruikers en tien apps kun je dit informeel houden. Bij vijftig gebruikers en honderd apps is dat niet meer verantwoord.

Maar governance is geen standaard recept dat je overal hetzelfde toepast.

De juiste governance-inrichting hangt af van een aantal factoren: wie er ontwikkelt en voor wie, wie de omgeving gebruikt en op welk niveau, wie eigenaar is van de data en wie van de analytics, hoe volwassen de datacultuur is, en hoe gevoelig de data is. Bedrijfsbrede financiële data vereist striktere governance dan een lokale marketinganalyse.

Vier patronen, oplopend in complexiteit

In de praktijk onderscheid ik vier veelvoorkomende patronen:

Personal BI
De maker beantwoordt zijn of haar eigen vragen. Weinig of geen delen, geen formele publicatie. Flexibel en informeel. Werkt prima voor individuen, maar schaalt niet.

Team BI
Een groep collega’s deelt analyses in een gedeelde omgeving. Ontwikkelaars zijn vaak vakinhoudelijk experts die hun eigen data ontsluiten. Processen zijn informeel, maar het werkt voor de groep.

Departmental BI
Een klein team binnen de afdeling bouwt analytics voor alle gebruikers van die afdeling. Hogere kwaliteitseisen, meer formele publicatie. De behoefte aan lifecycle management begint hier te spelen: gebruikers kennen de apps niet intiem, dus de apps moeten voor zichzelf spreken.

Enterprise BI
Een centraal team, vaak een CoE (Center of Excellence) of BICC (Business Intelligence Competency Center), is verantwoordelijk voor alle analytics. Hoge technische expertise, formele processen voor requirements en delivery, verplicht lifecycle management. Vaak ook verantwoordelijk voor het faciliteren van self-service datasets voor departmental en team BI.

Het patroon dat dominant is in jouw organisatie bepaalt de governance-inrichting die je nodig hebt. Maar een organisatie hoeft niet overal op hetzelfde niveau te zitten. Sommige afdelingen werken prima met Team BI, terwijl de financiële afdeling Enterprise BI-governance vereist.

Wie beheert wat: data en analytics

Een tweede dimensie is de verdeling van verantwoordelijkheid tussen business en IT.

In een volledig gedecentraliseerd model beheert de business zowel de data als de analytics. Flexibel, maar moeilijk te schalen en te borgen.

In een “middle-out” model beheert IT de data-laag en de business de analytics. Dit geeft een goede balans tussen governance en self-service, en is in de praktijk een veelgekozen aanpak.

In een volledig centraal model beheert IT of een CoE alles. Strakkere governance en meer controle, maar ook minder flexibiliteit voor de business en een hogere afhankelijkheid van het centrale team.

Welk model het beste past, hangt af van de omvang, de datacultuur, de gevoeligheid van de data en de capaciteit van zowel IT als de business.

Eén waarschuwing

Te strakke governance werkt averechts. Als je self-service doodreguleert, gaan mensen om het systeem heen werken. Excel, eigen tooling, shadow IT. De omgeving die je zorgvuldig beheerst, wordt omzeild door een schaduwomgeving die je niet kunt zien. Kies een basisniveau dat past bij de dominante patronen in jouw organisatie, en maak ruimte voor afwijkingen waar dat zinvol is.

Praktische governance-elementen

Ongeacht het gekozen patroon zijn een aantal elementen altijd relevant:

• Space-structuur: heldere indeling met duidelijk eigenaarschap per space

• Toegangsmodel (RBAC, Role-Based Access Control): gedocumenteerd, periodiek gecontroleerd, bijgewerkt napersoneelswisselingen

• Data-eigenaarschap: elke dataset heeft een eigenaar in de business, niet in IT

• Section Access: voor rij-niveau beveiliging, maar alleen robuust als de logica actueel blijft na organisatiewijzigingen

• Change management: wie mag wat aanpassen in productie, en via welk proces

Governance is geen eenmalig project. Het is een continu proces dat je structureel bijhoudt.

Governance begint bij een duidelijke data- en analyticsstrategie. Lees meer over onze Datastrategie-dienst.

Performance: waar zit de pijn echt?

Performance-problemen in Qlik Cloud zitten bijna nooit in de infrastructuur. Qlik beheert de servers, de capaciteit is in de meeste gevallen toereikend, en “Large Apps support” is zelden wat je werkelijk nodig hebt.

De performance-pijn die ik tegenkom zit vrijwel altijd in een van de volgende vier lagen. En ze versterken elkaar.

Het datamodel

Een slecht opgezet datamodel is de meest voorkomende oorzaak. Te brede tabellen met velden die nergens voor worden gebruikt, overbodige joins, onnodige tussentabellen. Het gevolg: langere laadtijden en een zwaarder geheugengebruik.

Maar het echte probleem is het cascade-effect: een slecht datamodel dwingt ontwikkelaars tot kunstgrepen in de front-end expressies om de gewenste berekeningen toch te krijgen. Die kunstgrepen maken de app traag, wat de aanleiding is voor de aanname dat er meer infrastructuur nodig is. Terwijl de oplossing in het datamodel zit.

Het laadscript 

Scripts die door de jaren heen zijn uitgebreid zonder refactoring. Dode code, dubbele transformaties, variabelen die nergens meer naar verwijzen. Taken die sequentieel draaien terwijl ze prima parallel kunnen lopen. En het meest voorkomende: geen incrementele load voor tabellen die dat wel zouden kunnen, waardoor elke reload een volledige herlaad is van data die grotendeels al aanwezig was.

Laadprocessen en planning

Reload-taken die niet optimaal zijn gepland. Afhankelijkheden die niet goed zijn ingericht, waardoor een vertraagde taak een keten van problemen veroorzaakt. Batch windows die niet zijn afgestemd op de beschikbare capaciteit. Dit is beheerswerk, geen ontwikkelwerk.

Front-end expressies

Inefficiënte Set Analysis-expressies. Berekeningen die voor elke gebruikersinteractie opnieuw worden uitgevoerd omdat de onderliggende datastructuur ze niet ondersteunt. Aggregaties in visualisaties die eigenlijk in het datamodel thuishoren.

De oplossing is in alle gevallen hetzelfde: periodiek onderhoud en review. Geen hardware, geen licentie-upgrade, maar iemand die er regelmatig naar kijkt met voldoende technische kennis om de oorzaak te herkennen.

Blijkt uit zo’n review dat het datamodel, laadscript of de architectuur structureel moet worden herbouwd, dan is Qlik Consulting de logische vervolgstap.

Wanneer schakel je een Qlik support partner in?

Niet elke organisatie heeft een externe Qlik support partner nodig. Als je een goed ingericht intern team hebt met voldoende Qlik-expertise en capaciteit voor proactief onderhoud, kun je het prima zelf doen.

Maar er zijn situaties waarin uitbesteden zinniger is dan zelf doen.

Signalen dat partner-support de moeite waard is

• Intern heeft niemand de diepgaande Qlik-kennis om release notes te analyseren of datamodel-issues te diagnosticeren
• De omgeving is groter dan één persoon bij kan houden naast de dagelijkse werkzaamheden
• Een Qlik Cloud feature release heeft al eens onverwachte problemen veroorzaakt in productie
• Een sleutelpersoon is weggegaan en de kennis is niet overgedragen
• Je staat voor een migratie, een ERP-wisseling of een grote architectuurwijziging
• Analytics-downtime heeft directe gevolgen voor operationele beslissingen

Waar je op let bij het kiezen van een partner

Een goede Qlik support partner doet meer dan tickets afwerken. Let op of ze release impact analyses uitvoeren voor elke update, of ze jouw omgeving kennen en niet elke keer opnieuw hoeven in te werken, en of ze bereid zijn kritisch te zijn. Als een partner altijd ja zegt en nooit terugduwt, is dat geen goed teken.

Pas ook op voor partners die na de initiële implementatie de aandacht laten verslappen. De support is het werk dat na de implementatie begint, niet ervoor. Vraag altijd naar wat er in de eerste zes maanden na go-live concreet gedaan wordt, en door wie.

Twijfel je niet alleen over de supportpartner, maar ook over de huidige inrichting, beheerafspraken of voorgestelde aanpak? Met een second opinion voor data & analytics laat je die keuzes onafhankelijk toetsen.

Wat mag Qlik support kosten en wat levert het op?

De waarde van professioneel Qlik-beheer zit voor een groot deel in wat er niet gebeurt. Incidenten die worden voorkomen. Releases die geen verrassingen opleveren. Een omgeving die bruikbaar blijft zonder dat elke wijziging meer inspanning vereist dan de vorige.

Dat laatste punt is misschien de beste indicator voor de kwaliteit van beheer: de moeite die het kost om een wijziging door te voeren. In een goed beheerde omgeving is dat stabiel. In een verwaarloosde omgeving groeit die inspanning met elke toevoeging, omdat de technische schuld en de onduidelijkheid over de bestaande structuur elke stap zwaarder maken. Op een gegeven moment durft niemand meer iets aan te raken.

Wat bepaalt de kosten?

De prijs van een support contract hangt af van een aantal factoren: de omvang van de omgeving (apps, gebruikers, datavolume), de complexiteit van de architectuur (on-premise databronnen, legacy-integraties, maatwerkextensies), het gewenste SLA (responstijd bij incidenten, beschikbaarheid buiten kantooruren), en of proactief onderhoud is inbegrepen of alleen break-fix service.

Bij Bitmetric begint proactief Qlik Cloud beheer vanaf €950 per maand.

Wil je het beheer liever zelf doen, maar wel dagelijks geïnformeerd worden over risico’s en afwijkingen? Met CloudScan for Qlik kan dat vanaf €125 per maand per tenant.

Een goede partner maakt vooraf inzichtelijk wat de scope is en wat het kost. Vage uurtarievenafspraken zonder duidelijke scope zijn een signaal dat je niet weet wat je koopt, en de rekening daarna ook niet. Bij Bitmetric vormt de Bitmetric Blueprint de basis van onze hele dienstverlening, niet alleen van Qlik Cloud Analytics.

Veelgestelde vragen

Conclusie

Een Qlik-omgeving die goed werkt, is best wat werk. Dat werk is (helaas) meestal onzichtbaar: zolang het goed gaat, merk je er niets van. Precies dat maakt het kwetsbaar, je ziet pas dat er iets ontbrak op het moment dat het wegvalt.

Structureel Qlik-beheer is geen garantie dat er nooit iets misgaat. Het is wel de garantie dat je het eerder ziet aankomen, sneller reageert, en minder last hebt van de verrassingen die anders ongezien opbouwen en in productie opduiken.

De keuze tussen intern beheer en uitbesteden hangt af van je kennis, capaciteit en de complexiteit van je omgeving. Beide kunnen werken. Wat niet werkt: geen keuze maken en hopen dat het vanzelf goed blijft gaan.

Wil je weten hoe jouw Qlik-omgeving er nu voor staat? Ik bespreek dat graag vrijblijvend met je. Gebruik de knop hieronder om een gesprek met mij via Teams in te plannen op een moment dat jou schikt.

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 Support & Beheer: de complete gids (2026) appeared first on Bitmetric.