7-Phasen-Migrationsplan von QlikView zu Microsoft Fabric

Eine erfolgreiche Migration folgt keiner Lift-and-Shift-Logik. Sie ist ein strukturiertes Redesign-Projekt. Wer das nicht akzeptiert und QlikView-Applikationen direkt übersetzen will, wird scheitern oder Jahre später dieselben Fehler beheben müssen.

Phase 1: Assessment und Inventarisierung

Bevor Sie eine einzige Zeile Code anfassen, brauchen Sie einen vollständigen Überblick über Ihr QlikView-Portfolio.

Catalogisieren Sie systematisch:

- Alle QVW-Dateien nach Anzahl, Größe, Nutzungsfrequenz und Komplexität

- QVD-Dateien nach Speicherort, Refresh-Zeitplan und Abhängigkeitsketten

- NPrinting-Reports nach Empfängern, Zeitplänen und Ausgabeformaten

- Section-Access-Konfigurationen

Klassifizieren Sie jede Applikation in drei Komplexitätsstufen:

- Tier 1 (Einfach): 1 bis 3 Datenquellen, wenige Transformationen, kein komplexes Set Analysis

- Tier 2 (Mittel): Mehrere QVDs, moderates Set Analysis, anspruchsvolles Scripting

- Tier 3 (Komplex): Mehrstufige QVD-Pipelines, umfangreiches Set Analysis, NPrinting, Section Access, große Datenvolumen

Mindestens genauso wichtig: Prüfen Sie für jeden Report, ob er überhaupt noch gebraucht wird. In der Praxis zeigt sich regelmäßig, dass ein erheblicher Teil des QlikView-Portfolios aus Report-Leichen besteht. Dokumente, die seit Monaten niemand geöffnet hat, Berichte, die ursprünglich für ein Projekt gebaut wurden und danach einfach liegengeblieben sind, oder drei Reports, die inhaltlich dasselbe zeigen, weil verschiedene Teams irgendwann angefangen haben, parallel zu bauen. All das wandert nicht in die neue Plattform. Eine Migration ist die beste Gelegenheit, den Bestand zu bereinigen und nur das mitzunehmen, was tatsächlich Mehrwert liefert.

Phase 2: Zielarchitektur entwerfen

Entwerfen Sie die OneLake-Struktur nach der Medallion-Architektur. Drei Ebenen, klar getrennt:

OneLake

├── Bronze Lakehouse  → Rohdaten (1:1 aus den Quellsystemen)

├── Silver Lakehouse   → Bereinigte, harmonisierte Daten

└── Gold Lakehouse    → Business-ready Tabellen und Semantic Models

Warum dieser Aufbau? In QlikView-Umgebungen landen Rohdaten, Transformationslogik und Reportingschicht oft in einem einzigen Reload-Skript. Das funktioniert, bis jemand etwas ändern muss und nicht mehr weiß, welche Teile voneinander abhängen. Die Medallion-Architektur trennt diese Verantwortlichkeiten sauber. Bronze enthält die Rohdaten genau so, wie sie aus den Quellsystemen kommen, unverändert. Silver bereinigt und harmonisiert, ohne die Rohdaten anzufassen. Gold liefert das, was die Reports brauchen. Wenn ein Quellsystem sein Schema ändert, wissen Sie sofort, was zu tun ist, und alles andere bleibt stabil. Das zahlt sich spätestens beim zweiten oder dritten Änderungswunsch aus.

Für jede QlikView-Applikation gilt: Redesign als Sternschema mit klar definierten Fakt- und Dimensionstabellen. Dokumentieren Sie alle QlikView-Ausdrücke, die zu DAX-Measures werden müssen. Das ist die Grundlage für alles, was danach kommt.

Phase 3: Umgebung aufbauen

• Microsoft Fabric Capacity (F-SKU) bereitstellen. Die Kapazitätsgröße bestimmt, wie viel Rechenleistung allen Workloads gemeinsam zur Verfügung steht. Starten Sie mit einer konservativen Größe und skalieren Sie hoch, sobald Sie reale Lastdaten aus den ersten Migrationen haben.
• Fabric Workspaces entsprechend der Zielarchitektur anlegen. Workspaces sind die Organisationseinheit in Fabric, vergleichbar mit Ordnern, aber mit eigenen Berechtigungen und Kapazitätszuweisungen. Planen Sie die Workspace-Struktur entlang Ihrer Domänen oder Datenzonen, bevor Sie die ersten Artefakte anlegen.
• On-Premises Data Gateway für lokale Datenquellen konfigurieren. Wenn Ihre Quellsysteme noch auf eigenen Servern laufen, brauchen Sie das Gateway als Brücke zwischen dem lokalen Netzwerk und der Fabric-Cloud. Das ist kein optionales Add-on, sondern oft die Voraussetzung dafür, dass die ersten Datenpipelines überhaupt funktionieren.
• Azure DevOps oder GitHub für Versionskontrolle aller Fabric-Artefakte einrichten. Fabric unterstützt Git-Integration nativ. Nutzen Sie das von Anfang an, nicht erst wenn etwas schiefgelaufen ist. So haben Sie jederzeit einen Rollback-Punkt und können Änderungen nachvollziehen.

Phase 4: Datenmigration

QVDs müssen zunächst in ein lesbares Zwischenformat exportiert werden, typischerweise CSV oder Parquet. Der Grund: QVD ist ein proprietäres Binärformat, das Qlik für seine eigene In-Memory-Engine optimiert hat. Microsoft Fabric, Python, SQL und alle anderen Werkzeuge können es schlicht nicht lesen. Es gibt keinen direkten Import-Weg. Der einzige Ausweg ist, QlikView selbst die Daten in ein offenes Format ausgeben zu lassen, über ein Reload-Skript das in CSV oder Parquet schreibt, oder über einen Export aus Qlik Cloud.

Der zweite Teil der Frage trifft den Kern der ganzen Migration: Ja, der Code muss vollständig überarbeitet werden. QlikView-Ladeskripte lassen sich nicht einfach kopieren und in Fabric einfügen. Die Skriptsprache ist proprietär und in keinem anderen Tool verfügbar. Jedes Ladeskript wird neu geschrieben, entweder als Fabric-Pipeline mit Dataflows Gen2 für einfachere Transformationen, oder als Spark-Notebook in PySpark oder SQL für komplexere Logik. Das ist aufwendig, aber auch die Gelegenheit, Logik zu bereinigen, die über Jahre gewachsen und schwer wartbar geworden ist.

Danach beginnt der eigentliche Aufbau:

• QlikView-Ladeskripte als Fabric-Pipelines, Dataflows Gen2 oder Spark-Notebooks reimplementieren
• Bronze, Silver und Gold Transformationen aufbauen und testen
• Incremental-Refresh-Muster als Delta-MERGE implementieren

Führen Sie parallel eine Kreuzvalidierung durch: Zeilenzahlen, aggregierte Summen und Schlüssel-KPIs müssen zwischen QlikView und Fabric übereinstimmen, bevor Sie weitergehen.

Phase 5: Reports und Dashboards migrieren

• Power BI Semantic Models mit Sternschema-Datenmodellen erstellen. Das Semantic Model ist die zentrale Business-Logik-Schicht in Power BI, vergleichbar mit dem Datenmodell in QlikView. Hier werden Beziehungen, Hierarchien und alle berechneten Kennzahlen definiert – alles, was danach in Reports genutzt wird, baut auf dieser Schicht auf.
• Alle Business-Measures in DAX implementieren. Jeder QlikView-Ausdruck und jedes Set-Analysis-Konstrukt wird hier als DAX-Measure neu gebaut. Das ist der arbeitsintensivste Teil der Report-Phase, zahlt sich aber aus: DAX-Measures sind wiederverwendbar und zentral gepflegt, statt in jedem Skript neu definiert zu werden.
• RLS-Rollen konfigurieren und testen. Row-Level Security ersetzt das QlikView Section Access. Die Logik ist ähnlich, nur dass RLS in DAX-Filterausdrücken definiert wird. Testen Sie frühzeitig mit echten Benutzerkonten, denn Fehler in der Sicherheitslogik fallen im Produktivbetrieb unangenehm auf.
• Berichte in Power BI Desktop neu erstellen. Die Reports werden nicht konvertiert, sondern neu gebaut – auf Basis des fertiggestellten Semantic Models. Nutzen Sie die Gelegenheit, Layouts zu vereinheitlichen und Reports, die in QlikView unübersichtlich geworden sind, sauber neu zu strukturieren.
• Pixel-genaue NPrinting-Reports als Power BI Paginated Reports nachbauen. Paginated Reports sind das direkte Gegenstück zu NPrinting-Ausgaben: tabellarisch, druckoptimiert, exportierbar als PDF oder Excel. Wer komplexe Layouts oder viele Seiten hatte, sollte hier realistische Aufwände einplanen.
• Power Automate-Flows für automatisierte Report-Verteilung aufsetzen. NPrinting-Zeitpläne werden durch Power Automate-Flows ersetzt, die Reports automatisch per E-Mail versenden oder in SharePoint ablegen. Das ist flexibler als NPrinting und lässt sich mit anderen Microsoft-365-Prozessen verknüpfen.

Phase 6: User Acceptance Testing

Die Fachbereiche validieren die migrierten Reports gegen die QlikView-Originale. Alle Berechnungen, Filter und Drill-Down-Szenarien werden geprüft. RLS wird mit verschiedenen Benutzerprofilen getestet. Performance unter paralleler Nutzerlast wird gemessen.

Verplanen Sie hier ausreichend Zeit. UAT-Phasen, die unter Zeitdruck stehen, produzieren Fehler, die später teuer behoben werden müssen.

Phase 7: Go-Live und Dekommissionierung

Fahren Sie QlikView und Fabric zunächst parallel. Schulen Sie Ihre Nutzer auf die Power BI Interaktion. Dann: QlikView-Server dekommissionieren, QVD-Speicher auflösen, Lizenzen kündigen.

Ein konkretes Beispiel aus der Praxis

Ein Energieunternehmen betrieb QlikView für operative Berichterstellung über Reservoirs und Kreditrisiko-Reporting im Finanzbereich. Der End-of-Support stand fest, und das Unternehmen wollte die QlikView-Server vollständig abschalten.

Die Herausforderungen waren exemplarisch: Komplexe ETL-Prozesse mit mehrstufigen QVD-Transformationsketten, umfangreiche NPrinting-Nutzung für PDF-Verteilung an Stakeholder, und ein breites Spektrum von operativen bis hin zu regulatorischen Reporting-Anforderungen.

Was umgesetzt wurde:

• ETL-Prozesse komplett in Azure-native Pipelines überführt
• NPrinting durch Power BI Paginated Reports ersetzt
• Power Automate für automatisierte Report-Verteilung und interaktive Workflow-Schaltflächen implementiert

Das Ergebnis: QlikView-Server abgeschaltet, spürbare Reduktion der Lizenzkosten, eine wartungsfreundlichere und anpassungsfähigere Reporting-Infrastruktur auf Azure.

Was Microsoft Fabric wirklich kostet

Das ist die Frage, die in jedem Projekt frühzeitig beantwortet werden muss.

Laufende Kosten QlikView/Qlik Sense (Beispiel 50 Nutzer):

Lizenzen: ca. 60.000 bis 100.000 Euro pro Jahr

Server-Infrastruktur: variabel, dazu Betrieb und Wartung

NPrinting-Lizenzen: zusätzlich

QlikView-Spezialisten: Marktknappheit treibt Gehälter nach oben

Microsoft Fabric Capacity Preise (2026):

Ab F64 ist Power BI vollständig inklusive. Keine zusätzlichen Pro-Lizenzen für Report-Konsumenten nötig. Mit einer 1-Jahres-Bindung sparen Sie rund 40 Prozent gegenüber dem Pay-as-you-go-Preis.

Organisationen, die migriert haben, berichten typischerweise von einem Break-Even nach 12 bis 24 Monaten. Die Treiber sind Lizenzeinsparungen, wegfallende Infrastrukturkosten und Produktivitätsgewinne durch moderne Werkzeuge.