Migreren naar Qlik Cloud: de complete gids (2026)

Elke dinsdag levert Qlik een nieuwe release uit. On-premise omgevingen krijgen ook updates, maar veel minder vaak en veel later.

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.

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.

Download de QlikView to Qlik Sense Converter Tool

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.

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

Alternatief: Bitmetric Backup for Qlik Cloud

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.

Download de Qlik Analytics Migration Tool (QAMT)

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)

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.

Bekijk onze Qlik Support & Beheer diensten

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

Bekijk onze Qlik Consultancy diensten

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.