QlikView naar Qlik Cloud migreren: een gids uit de praktijk

“We moeten naar Qlik Cloud.” Die ene zin start een project dat klinkt als een lift-and-shift, maar in werkelijkheid een volledige heroverweging is van hoe je data je dashboards bereikt.

Ik rondde onlangs een migratie af van een grote QlikView-omgeving naar Qlik Sense Cloud, voor een productiebedrijf. Wat begon als “migreer de apps” werd een herontwerp van de data-architectuur van de grond af. Want de patronen van QlikView overleven de overstap naar cloud niet ongewijzigd.

Dit is wat ik leerde, en wat ik je zou vertellen voor je aan die van jou begint.

Waarom je niet zomaar kan lift-and-shiften

QlikView-apps zijn op zichzelf staand. Elke app heeft doorgaans zijn eigen dataconnectie, zijn eigen laadscript, zijn eigen transformaties. On-premises werkt dat, want je verbindt rechtstreeks met databases via ODBC. Netwerklatency is verwaarloosbaar. Security loopt via Active Directory. De server doet alles.

Qlik Cloud verandert dat allemaal:

• Geen rechtstreekse ODBC naar je ERP. Je data moet door een pijplijn, een gateway, een API of een replicatietool, voor Qlik ze kan aanraken.
• Dataresidentie en egress tellen mee. Dagelijks gigabytes door API’s verplaatsen heeft gevolgen voor kost en performantie.
• Spaces vervangen servermappen en security rules. Het hele governance-model verandert.
• Section Access werkt met e-mailadressen, niet met Windows-gebruikersnamen.
• Geen Qlik Publisher. Distributie en automatisering werken anders.

Pak je dit aan als “QlikView-scripts omzetten naar Qlik Sense-scripts”, dan eindig je met tientallen apps die elk apart data ophalen, je pijplijn afbeulen en transformaties dupliceren. Dezelfde rommel als voorheen, nu trager en duurder.

Stap 1: breng je data in kaart voor je apps aanraakt

Voor ik één app omzette, bracht ik elke data-afhankelijkheid in kaart:

• Welke QlikView-app gebruikt welke tabellen?
• Welke velden uit elke tabel?
• Waar gebeuren de transformaties, in het laadscript of in de front-end?
• Welke apps delen data die je zou kunnen centraliseren?

Dat leverde een app-naar-QVD-matrix op: een opzoektabel die precies toont welke ERP-tabellen welke apps voeden. Zonder dat migreer je blind.

De matrix maakte meteen duidelijk dat een aantal tabellen in zowat elke app apart werd geladen en gejoined: artikelstamdata, leveranciersinfo, kostprijzen. In QlikView was dat te verdragen. In cloud betekent het tientallen apps die dezelfde API-calls doen en dezelfde joins draaien. Daar begint het herontwerp van de architectuur.

Stap 2: ontwerp de datalaag

De kernbeslissing in de architectuur: bouw een gedeelde datalaag die alle apps consumeren, in plaats van elke app zijn eigen data te laten ophalen.

Drie lagen:

Laag 1: ruwe QVD’s (landing zone)

Een pijplijn haalt data uit de cloud data lake van het ERP via CDC (Change Data Capture) en zet ze als QVD-bestanden neer in de managed storage van Qlik Cloud. Tientallen tabellen, dagelijks ververst. Dit zijn de grondstoffen: append-only CDC-records, nog niet ontdubbeld.

Laag 2: ontdubbelde QVD’s

Hier zit de uitdaging met CDC uit een cloud data lake: het is vaak append-only. Elke wijziging aan een record maakt een nieuwe rij met dezelfde business key maar een recentere timestamp. Je ruwe QVD’s groeien eindeloos, en elk record heeft duplicaten.

Ik bouwde een generieke ontdubbel-subroutine die:

1. Elke ruwe QVD inleest
2. Groepeert op de business primary key van het ERP (samengestelde sleutels via concatenatie)
3. Enkel de meest recente versie van elk record behoudt
4. Soft-deleted records eruit filtert
5. Een schone QVD wegschrijft

Dit draait als een backend-app in Qlik Cloud en verwerkt alle tabellen in één reload. De definities van de ontdubbelsleutels staan in een CSV: een nieuwe tabel toevoegen is één rij bijzetten, geen nieuwe code schrijven.

Laag 3: custom QVD’s (gedeelde dimensies)

Sommige data bestaat niet in één brontabel. De artikelstam bijvoorbeeld vraagt een join van een tiental ERP-tabellen: algemene attributen, inkoopdata, productieparameters, magazijninstellingen, aankoopprijzen, costing, planning, verkoopconfiguratie.

In QlikView deed elke app die join apart. In de nieuwe architectuur produceert één backend-app één uniforme artikelstam-QVD die alle frontend-apps consumeren.

Zelfde patroon voor de kalenderdimensie. De oude QlikView-apps hadden meerdere inline kalenderdefinities, elk net iets anders. De ene liet weken op zondag beginnen. De andere berekende “rolling 12 months” anders. Ik verving ze allemaal door één gedeelde kalender-QVD: één definitie, overal consistent.

Stap 3: CDC of full load, de architectuurbeslissing

Dit was de grootste ontwerpbeslissing van het project. Twee opties:

Full load (Replicate-stijl): haal elke nacht de volledige tabel op. Simpel. Gegarandeerd vers. Maar: sommige tabellen zijn groter dan 1 GB. Tientallen tabellen dagelijks volledig ophalen betekent elke nacht meerdere gigabytes door de API verplaatsen. Egresskosten lopen op. De pijplijn-runtime groeit met het datavolume, niet met het wijzigingsvolume.

CDC met ontdubbeling: haal enkel wijzigingen op. Kleinere payloads, snellere pijplijnen. Maar: vraagt een ontdubbelstap, bewaart twee kopieën van elke QVD (ruw plus ontdubbeld), en vergt zorgvuldig sleutelbeheer.

Ik koos voor CDC. De redenering:

• Schaalbaarheid. Full loads worden trager naarmate het bedrijf groeit. CDC blijft proportioneel met het dagelijkse wijzigingsvolume.
• Toekomstbestendig. De ruwe CDC-laag bewaart de wijzigingshistoriek: nuttig voor slowly changing dimensions, audit trails en temporele analyse later.
• Kost. API-egress wordt gemeten. Enkel wijzigingen verplaatsen is goedkoper op schaal.

De trade-off is complexiteit. Je hebt betrouwbare ontdubbellogica nodig, en je moet randgevallen afhandelen: tabellen waar CDC-sleutels verschillen van de business primary key, records die in de verkeerde volgorde binnenkomen, tabellen waar de data lake niet alle velden blootstelt.

Dit is een beslissing die je bewust moet nemen, niet by default. Voor kleinere omgevingen (minder dan 20 tabellen, minder dan 1 GB totaal) is full load simpeler en is het kostenverschil verwaarloosbaar. Voor grotere omgevingen verdient CDC zijn complexiteit terug.

Stap 4: space governance

Qlik Cloud gebruikt spaces in plaats van de servermappen en security rules van QlikView. Dit vroeg goed zetten bespaart je pijnlijke herstructurering later.

Het model dat ik implementeerde:

De workflow: ontwikkel in DEV, test, en publiceer dan naar PRD. Publiceren maakt een read-only kopie. Business users raken de ontwikkelversie nooit aan.

Dit weerspiegelt een DTAP-patroon (Development, Test, Acceptance, Production) aangepast aan het space-model van Qlik Cloud. QlikView had geen native equivalent: de meeste QlikView-omgevingen leunden op mappermissies en handmatige file-kopieën.

Stap 5: zet de apps om

Met de datalaag op zijn plaats is het omzetten van de apps zelf het rechttoe rechtaan deel:

1. Herschrijf laadscripts zodat ze QVD’s uit de gedeelde datalaag consumeren in plaats van rechtstreekse ODBC-connecties te maken.
2. Verwijder overbodige transformaties. Als de datalaag ontdubbeling, kalender en stamdata-joins al afhandelt, krimpt het app-script drastisch.
3. Werk Section Access bij van Windows-gebruikersnamen naar e-mailadressen.
4. Herbouw de visualisaties in de sheet-gebaseerde UI van Qlik Sense.

Voor tientallen apps blijft dit stevig werk. Maar door de datalaag is het laadscript van elke app nu 50 tot 200 regels QVD-reads en veldselecties, in plaats van 500+ regels ODBC-queries en inline transformaties.

Deployment-automatisering

Bij tientallen apps schaalt handmatige deployment niet. Ik bouwde een CLI-gebaseerde deployment-pijplijn:

• Aanmaken van apps in DEV met de juiste space-toewijzing
• Instellen van laadscripts vanuit versiebeheerde .qvs-bestanden
• Uploaden van gebrande thumbnails (programmatisch gegenereerd: consistente 640x400 PNG’s)
• Reloaden en valideren
• Publiceren naar de PRD-space

Alle scripts en QVS-bestanden staan in git. Een wijziging naar productie brengen is: bewerk het .qvs-bestand, push, draai het deploy-script.

Stap 6: de reload-keten

In QlikView werden reloads meestal getriggerd door Qlik Publisher of Windows Task Scheduler. In Qlik Cloud gebruik je Automations (of de API).

De dagelijkse reload-keten:

01:00  Pijplijn landt CDC-data uit ERP data lake
03:00  Ruwe QVD's automatisch opgeslagen
03:30  Backend: alle tabellen ontdubbelen -> schone QVD's
04:00  Backend: MasterCalendar + gedeelde dimensie-QVD's genereren
05:00  Frontend: alle apps reloaden (parallel)

Volgorde is belangrijk. Frontend-apps hangen af van backend-QVD’s. Backend-QVD’s hangen af van de pijplijn-landing. Deze keten fout krijgen betekent dashboards die de data van gisteren tonen, of erger, half bijgewerkte data uit een mix van vandaag en gisteren.

Wat ik anders zou doen

Vroeger met de datalaag beginnen. Ik onderschatte aanvankelijk hoeveel werk de CDC-ontdubbelpijplijn zou vragen. De generieke subroutine dekt de meeste tabellen, maar de randgevallen (samengestelde sleutels, ontbrekende velden, tabellen die niet in de data lake zitten) kostten meer tijd dan verwacht.

Bouw eerst de app-naar-QVD-matrix, niet parallel. De afhankelijkheidsmapping legde de kansen voor gedeelde data bloot die de hele architectuur vormgaven. Dit voor elke conversie doen had herwerk bespaard.

Reken tijd in voor de eigenaardigheden van Qlik Cloud. Thumbnail-propagatie werkt niet via de REST API: daarvoor heb je de Engine WebSocket nodig. Nieuwe apps aangemaakt via CLI hebben een spook-“Section”-tab. Op zich kleine dingen, maar ze tellen op als je tientallen apps deployt.

De dataflow-bril

Deze migratie is een schoolvoorbeeld van waarom full-chain denken telt. De apps, het zichtbare deel, zijn de laatste stap. Het echte werk zit stroomopwaarts:

1. Bedrijfsprocessen genereren ERP-data
2. Bronsysteem stelt ze bloot via data lake API (CDC, append-only)
3. Pijplijn landt ze in cloudopslag (dagelijks)
4. Datalaag ontdubbelt, joint en standaardiseert (QVD’s)
5. Apps consumeren schone data en tonen ze als dashboards

Raak één laag aan zonder te begrijpen wat stroomopwaarts en stroomafwaarts zit, en er breekt iets. Dat geldt voor QlikView-naar-Cloud-migraties. Het geldt voor elk dataproject.

Een QlikView naar Qlik Cloud migratie op de planning? Boek een call en laten we in kaart brengen wat jouw migratie echt inhoudt, voor je begint met apps om te zetten.